The procurement fallacy
The procurement model is seductive because it is legible to the parts of an enterprise that control budgets. You identify a capability gap, you evaluate vendors, you sign a contract, you deploy, you declare victory. It works beautifully for laptops and expense software. It fails for AI adoption because the value of AI does not live in the tool. It lives in the change to how work flows through the organization—and you cannot buy that change; you have to build it.
Consider what a coding agent actually is. The Cursor documentation describes agents that read a codebase, plan a change, and produce a diff; Claude Code describes a similar capability from the terminal. Handing that to an engineer inside a mature enterprise does not automatically make them faster. It makes them faster only if the repository is legible to the agent, the instructions encode the team's real standards, the tests are trustworthy, and there is a review process that can absorb the increased output. Absent those, the agent produces plausible code into a system that cannot safely accept it, and the net effect on delivery is roughly zero—or worse, negative, once you count the review backlog.
The tool was never the bottleneck. The bottleneck is the system the tool plugs into. And systems are engineered, not purchased.
What This Looks Like in Practice
When we help an enterprise adopt AI in earnest, almost none of the early work is about the AI. It is about the conditions that let AI produce value. Here is the shape of it.
Start with the operating model, not the tool. We map how work actually moves today—from idea to spec to build to review to release—and we find where AI can compress a step without breaking the ones around it. Often the highest-value early change has nothing to do with models: it is fixing a review process, standardizing a test harness, or making a repository legible. The AI simply exposes the weaknesses that were always there.
Make repositories agent-ready, deliberately. In a large organization this is a real program of work, not a weekend. Clear structure, encoded standards, fast reliable tests, typed boundaries, documented context. This is the same preparation that makes a codebase pleasant for a new senior hire—agents just make the payoff immediate and measurable. Skipping it is the single most common reason enterprise pilots underwhelm.
Institutionalize plan / build / verify. Our operating model separates the pass that plans a change from the one that builds it from the independent one that verifies it. In an enterprise, this maps naturally onto governance requirements: you need an audit trail, you need someone accountable for every merge, and you need verification that does not depend on the builder's self-report. Vendors reinforce that verification is systematic work; OpenAI's evaluation best practices frame it as repeatable, evidence-based checking rather than spot inspection. Enterprises that already have change-management rigor find this fits their world better than they expect.
Govern model access as engineering, not policy theater. Which model tier is allowed for which class of work is an engineering decision with cost, latency, and risk trade-offs—and it should be made with the same evidence discipline as any other. The major providers—OpenAI, Anthropic, and Google's Gemini API—offer multiple tiers precisely so you can match capability to task. Routing everything to the most capable model is expensive; routing everything to the cheapest is unsafe. The right allocation is an engineering choice measured against outcomes, not a blanket procurement rule handed down from a committee that will never read the diffs.
Measure the system, not the seats. The metric that matters is not "how many engineers have licenses" or "how many prompts were run." It is cycle time, defect rate, and the cost of change—the same measures that told you whether any engineering investment paid off. If those do not move, the adoption has not happened yet, regardless of how many seats are active.
Common Mistakes
Buying tools and expecting behavior to change. Deploying an agent to ten thousand engineers changes what is possible, not what happens. Behavior change requires new workflows, new review capacity, and new expectations—all of which are engineering and management work, not line items.
Running adoption out of procurement or a central "AI office" disconnected from engineering. When the people driving adoption cannot read the code, they optimize for the things they can see: license counts, vendor relationships, splashy pilots. The actual determinants of success—repo readiness, test quality, review throughput—are invisible to them, so they go unaddressed.
Piloting in a pristine sandbox. Enterprises love to prove AI works on a clean, greenfield project, then act surprised when it flounders against the twelve-year-old system that actually runs the business. The sandbox proves the tool functions; it proves nothing about your ability to adopt it where it counts. Pilot against real conditions or do not bother.
Assuming governance and speed are opposed. Many enterprises fear that AI velocity and their compliance obligations are in tension. Handled as an engineering problem, they are not. The same plan/build/verify structure that makes AI safe is an audit trail. Governance done as engineering accelerates adoption; governance done as paperwork strangles it.
Planning adoption around headcount reduction. Some enterprise programs are quietly justified by an expectation that AI will reduce the need for engineering judgment. In every case we have seen, the value shows up as more capable engineering—architecture, judgment, and accountability remain firmly human, and adoption plans built on the opposite premise produce brittle, poorly owned systems.
The uncomfortable implication
If adoption is an engineering problem, then the organizations best positioned to adopt AI are the ones with strong engineering cultures already—good tests, clean systems, clear ownership. The ones that most want AI to rescue them, because their engineering is a mess, are the ones least able to absorb it. AI amplifies the engineering system it lands in. A disciplined enterprise gets faster and stays safe. A disorganized one gets faster at producing the wrong things.
That is not a counsel of despair; it is a sequencing instruction. The first move in an enterprise AI program is often not "deploy AI." It is "get the engineering system into a state where AI can help"—legible repos, trustworthy verification, real ownership. Even the infrastructure decisions carry this logic: consolidating onto simpler, well-understood runtimes like Cloudflare Workers removes accidental complexity that no amount of model capability will paper over. Do that work, and the tools you already bought start to earn their keep.
Enterprises do not have an AI tool shortage. They have an engineering-adoption gap. Close it as engineering, and the rest gets a lot less mysterious.
