AI Adoption and the Employer's Dilemma

Every quarter an enterprise delays AI adoption, the math will get worse; 84% of developers now use AI tools that write 41% of all code.^[1] The engineers denied access do not wait for the committee to decide. They leave for organizations where AI code generation and agentic workflows are standard issue, or they leave to found their own companies. When they do, they come back as competitors: leaner, faster, and operating at a fraction of the cost. Anthropic's Claude Code alone crossed $1B in annualized revenue by November 2025 and approached $2B by January 2026.^[2] That is 300,000+ businesses voting with their budgets that AI-assisted development is the new baseline. The math is already running against the enterprise that treats this as optional, and it compounds.

Christensen's thesis was that good management itself causes failure in the face of disruption. Andy Grove saw the same pattern at Intel: "A strategic inflection point is a time in the life of business when its fundamentals are about to change. That change can mean an opportunity to rise to new heights. But it may just as likely signal the beginning of the end."^[7] Grove observed that the star of the previous era is often the last to adapt, the last to yield to the logic of such a moment, and tends to fall harder than most. The dilemma runs deeper than any individual manager's choices. The processes that made an enterprise successful, rigorous procurement, change-control boards, multi-quarter planning, are the same processes that now prevent it from letting engineers use Claude Code.

The employment contract has always been a simple exchange of skills for compensation, productive output for salary. That exchange now has a new variable: AI proficiency. When someone says "AI doesn't work for me," the question is whether they mean it does not work within their company's constraints (legacy systems, compliance walls, risk-averse leadership) or that they personally tried it on a greenfield project and it fell short. The distinction matters enormously, because the first is a solvable organizational problem while the second is increasingly uncommon among engineers who invest real effort in learning the tools.

Many of those company constraints deserve more respect than they typically receive in this conversation. AI coding tools route proprietary source code through third-party inference APIs. The MCP server ecosystem remains largely unvetted. Open-source reverse proxies like OpenClaw exist specifically to strip safety guardrails from model outputs. Agentic workflows can execute arbitrary code on developer machines with broad filesystem access. For a company mid-SOX audit, approaching an IPO, or navigating an acquisition with PwC consultants combing through every system and network, the CISO who says "not yet" may be the most responsible person in the building. Many of these enterprises were not technology companies for most of their existence; their IT governance was designed for ERP systems and email, and adapting those frameworks to tools that stream source code to external inference endpoints is genuinely hard work that takes time. The critique in this brief is aimed at companies that stop at "no" permanently, that let caution calcify into identity. Companies working toward "yes, with guardrails" are doing exactly what they should.

We have seen this exact pattern before. In the early 2010s, engineers left companies that resisted cloud adoption to keep their skills competitive. A Gartner study found two out of three cloud migration delays were caused by talent shortages, but the causality ran both ways: companies that delayed lost the people who could have led the migration. The same dynamic is accelerating with AI. Shopify CEO Tobi Lutke now requires employees to prove a task cannot be done by AI before requesting headcount.^[3] AI usage is baked into Shopify's performance reviews. Duolingo CEO Luis von Ahn announced in April 2025 that the company would stop using contractors for work AI can handle.^[4] These mandates signal something to the talent market beyond operational efficiency: this is a place where your AI skills will compound, not atrophy.

Unreliable Components, Reliable Systems

Every technology we now take for granted was once considered too unreliable for production. Routers fail, disks fail, and TCP packets corrupt. Amazon CTO Werner Vogels has spent two decades repeating that "everything fails, all the time." The engineering response was always the same: build resilient systems from unreliable ones. Cloud computing, aviation safety, and self-driving cars all followed this pattern. LLMs are following it now.

The only question that ever mattered is whether we can build systems reliable enough for a given use case, at an acceptable dollar and social cost. Agentic workflows with verification loops, redundant model calls, and deterministic checks layered on top of probabilistic outputs can now be made genuinely production-ready for autonomous operation across many use cases. LLMs still hallucinate, and that will continue. What has changed is that the systems engineering around them, verification loops, structured output validation, human-in-the-loop escalation, now works well enough to ship.

There is, however, a separate concern that deserves its own discipline: supply chain trust. Hallucination is an engineering problem with known mitigations, but the question of whether your AI toolchain's third-party dependencies are trustworthy is a procurement and security problem. Unvetted MCP servers, opaque model routing, and agentic tools with broad system access all present real attack surface that compliance teams are right to scrutinize. Companies that conflate these two concerns, treating supply chain risk as evidence that "AI doesn't work," end up solving the wrong problem and delaying adoption for the wrong reasons.

The unit economics reinforce this. Token prices have fallen 50x since late 2022.^[5] DeepSeek entered the market at $0.55 per million input tokens, undercutting incumbents by 90%. Agentic workflows consume 10x to 100x more tokens per task than simple prompts, but the net cost per unit of useful work keeps declining. The enterprise that waits for "reliable AI" is waiting for a problem that is already being solved, at lower cost, every quarter.

Employer Suicide, Employee Survival

Experience as a software engineer today does not guarantee relevance tomorrow. Employees trade skills for employability, and failing to upskill in AI jeopardizes their future. An engineer working at a company that bans or restricts Claude Code, Cursor, and agentic workflows is falling behind the 84% of their peers building AI fluency every day. The smart ones recognize this and leave—not out of dissatisfaction, but because staying risks their career.

The smarter ones do something more dangerous: they found companies. Armed with domain knowledge from their former employer, access to the same AI tooling their old company refused to adopt, and a cost structure that would have been impossible three years ago, they attack their former employer's vertical. A team of 20 with Claude Code, an agent SDK, and agentic CI/CD can now ship what used to require 60. Time-to-market compresses from years to months. As models improve, this compression accelerates. The former employer now faces a competitor who knows their business intimately, operates at a fraction of the cost, and ships at 3x the velocity.

If a company struggles with AI adoption, that is a company problem the employee has no obligation to absorb. Some of those struggles reflect genuinely responsible caution: a 90-day security review before deploying AI tools across production systems is good governance, and companies mid-audit, pre-IPO, or deep in regulatory review have legitimate reasons to move carefully. The employee can respect the timeline without surrendering their own career trajectory. Where Grove's warning applies is to the companies that have let temporary caution become permanent identity: "The ability to recognise that the winds have shifted and to take appropriate action before you wreck your boat is crucial to the future of an enterprise."^[7] A 90-day security review is responsible. A 900-day one is organizational paralysis wearing the mask of diligence. The enterprise that treats "AI doesn't work here" as a permanent conclusion rather than a diagnosis to work through has decided to let its constraints define its future. Meanwhile, the employees who need those skills for their next job, and the one after that, are already updating their resumes.

Social Acceptance: The Barrier Nobody Talks About

Social acceptance is the least discussed barrier to enterprise AI adoption. Even when AI error rates fall below human levels, people struggle to trust systems whose failures feel weird and unpredictable. We lack a mental model for how LLMs fail. We forgive a human engineer who ships a bug, but an AI agent that confidently generates plausible yet wrong code is unsettling in a way that resists statistical reassurance.

But this tends to improve as familiarity grows. Self-driving taxis are the clearest precedent: early public resistance gave way to broad acceptance as riders accumulated experience and worst-case metrics improved. The same pattern is emerging with AI coding tools. Successful deployments have shifted evaluation from average success rates to worst-case scenarios across large sample sizes. The Klarna reversal is instructive: they deployed AI customer service agents that replaced 700 workers, claimed success, then admitted they "went too far" and began rehiring.^[6] The lesson from Klarna is that deploying AI without building social trust, both internally and with customers, extracts a reputational cost that offsets the operational savings.

Open-ended tasks without verifiable ground truth remain hard, and nobody should force LLMs into every application. Neuro-symbolic systems, traditional ML, and deterministic algorithms better serve some critical use cases. The right framing is "AI where the systems engineering, unit economics, and social acceptance conditions are met." For a growing set of genuinely important applications, all three conditions are now satisfied.