AI Operating Models

A forty-person engineering org holds its quarterly tooling review, and the same category shows up on three separate expense reports. The platform team runs a self-hosted proxy in front of Claude Code, metered and centrally billed. The mobile team pays for Cursor out of its own budget, because the proxy did not support their IDE when they needed it. A dozen engineers on the newest team are still quietly expensing a twenty-dollar personal plan nobody centrally approved, because the official rollout has not reached them yet. Nobody set out to build three parallel AI tooling stacks. Each decision, made locally and reasonably, added up to one.

This is the operating-model question, and it is different from the question this volume’s earlier chapters have already asked. Those chapters cover how a team practices AI-assisted engineering — its review culture, its skill formation, its day-to-day norms. This one asks a structural question one level up: who, in the organization, decides which tools get deployed, who pays for them, and which parts of engineering get them first. It rarely gets asked directly. It gets answered by default, procurement cycle by procurement cycle, until a security review or a budget cut forces someone to reconstruct the decision after the fact.

What the data says about who should decide

The clearest empirical anchor for this question comes from DORA’s 2025 research, and it points at infrastructure rather than mandate. Ninety percent of the organizations DORA surveyed had adopted at least one internal platform, and the report found a direct correlation between the quality of that platform and an organization’s ability to unlock value from AI at all — the platform functioning less as a convenience and more as the layer that turns individual productivity gains into anything organizational. Read plainly, this says the operating-model question is not really “who should own AI tooling” in the abstract. It is “does whoever already owns the internal developer platform have the quality to carry AI on top of it” — because if they do not, centralizing AI ownership there will not fix the underlying gap, and if they do, decentralizing away from them probably throws away the one asset built for exactly this job.

DORA’s own AI Capabilities Model gives the centralization question a more concrete shape through a capability it calls a clear and communicated AI stance. The recommended structure is a three-bucket policy — prohibited uses that are never allowed, uses permitted only with specific guardrails, and uses actively encouraged as low-risk and high-value — published as an official, centrally maintained list rather than left to individual teams to work out on their own. The research is explicit that the content of the stance matters less than its clarity: an organization can land on a permissive or a restrictive policy and still see AI’s positive effect on performance amplified, so long as engineers can find the answer without asking.

Centralized, federated, and the tightening-only middle

The previous chapter in this volume, AI Governance & Policy, names the mechanism many organizations reach for once federated purchasing produces exactly the duplication in this chapter’s opening scene: a tightening-only hierarchy, in which an organizational baseline sets a floor — protected paths, forbidden operations, budget ceilings — and a project or team may only tighten that floor further, never loosen it. Applied to the operating-model question, the same shape answers a narrower version of “who decides”: not which single team holds the pen, but which layer wins a tie, and in which direction exceptions are allowed to run.

GitHub’s own Copilot administration documentation is a shipped, concrete version of that exact hierarchy, worth citing because it is a product surface rather than a policy essay. An enterprise owner can explicitly enable a Copilot feature everywhere, disable it everywhere, or delegate the choice to individual organizations beneath the enterprise — and once the enterprise layer has set a policy explicitly, no organization underneath it can override it. The tool does not resolve whether a central platform team or a product-engineering group should own the decision. It resolves the direction of authority once someone does: down, and only down.

Cloudflare’s own engineering blog is a useful counterpoint precisely because it describes the fully centralized answer to the same question, in an engineering post rather than a governance memo. A cross-functional tiger team — internally nicknamed iMARS — spent roughly a year building the company’s internal AI coding stack, and the sustained ownership landed with the Dev Productivity team, the same group that already owned CI/CD, build systems, and internal automation before AI tooling existed as a category. The governance mechanism is architectural rather than procedural: every engineer’s coding environment routes through a single proxy that functions as a literal control plane, model selection for reviewer agents is centralized so a model swap never touches a CI template, and a configuration change reaches every engineer’s environment through the same deploy pipeline the team already used for everything else. By the company’s own account, that structure took AI coding tooling from a standing start to ninety-three percent adoption across the R&D organization in under a year.

Budget ownership, and the ROI nobody can defend yet

Budget ownership tells a less settled story than tool governance does. Heading into 2026, close to half of the engineering leaders DX surveyed had set aside somewhere between one and three percent of the total engineering budget specifically for AI tools, with a meaningful share already treating a thousand dollars per developer per year as a working 2026 target. What almost none of them could do, by their own account, was defend that figure against an outcome: eighty-six percent said they remained uncertain which of their tools actually delivered the most benefit, and forty percent said they simply lacked enough usage-and-impact data to build the ROI case at all. That is the same gap this Library keeps finding one layer at a time — the AI Cost Iceberg names it at the level of a whole engineering org, and this volume’s own Measuring AI chapter names it again at the level of a single accepted suggestion. A budget line and an outcome are two different systems, and almost nobody has built the join between them yet.

The way that same survey’s respondents split their money is a more honest signal of how deliberately organizations are thinking about the allocation than any stated ownership model. Leaders were setting aside fifteen to twenty percent of the AI tooling budget for uses beyond code authoring — review, debugging, security, documentation — and reserving a further ten percent explicitly for challenger tools in the code-authoring category itself. A line item like that only makes sense if someone, centrally, is deliberately keeping a second vendor alive rather than consolidating for its own sake — which suggests the budget owner, whoever it turns out to be on an org chart, is already behaving like a platform team even in organizations that have not formally decided to make it one.

The geography and culture of who pays

The nine hundred–plus engineers Pragmatic Engineer surveyed in April 2026 point at a split that tracks regional risk culture more than company size. Employers overwhelmingly pay for the tool rather than the individual — the norm reported was a company-funded top-tier plan running one hundred to two hundred dollars a month per engineer, well above the roughly twenty dollars a month engineers reported spending out of pocket when the company did not cover it. But the survey also found a real divide in when that spend gets approved. American respondents skewed toward investing first and measuring impact later, extending relatively generous per-seat budgets on the expectation that usage data would justify itself afterward. UK and European respondents more often described a review gate requiring demonstrated value before the company would commit thirty to fifty dollars a month per engineer at all.

Invest first and measure later, or demonstrate value and then invest — an organization that has not picked one will relitigate the same budget argument every quarter.

On the US/UK-EU split in Pragmatic Engineer’s April 2026 survey

Which function gets AI first — and where the evidence runs out

It would be tidy to close this chapter with a ranked list of which engineering sub-function gets AI tooling first, and why — platform ahead of product engineering, QA and infrastructure trailing on some predictable curve. That list exists in abundance in vendor content. It is considerably harder to find backed by anything close to a primary, comparable source. The credible, engineering-grounded evidence this chapter could verify — DORA’s survey, Cloudflare’s own account, the budget data above — speaks mostly to core software engineering practice: the coding, review, and platform-tooling workflow this Library treats throughout. It goes quiet exactly where a tidier account would need it to hold, on real adoption-rate data broken out by platform versus product engineering versus QA versus infrastructure, collected the same way, at the same time, across a sample large enough to trust.

Rather than presenting a cross-functional rollout sequence dressed up as settled practice, this chapter scopes its operating-model claims to core engineering, where the evidence above actually reaches, and says plainly that the sequencing question across the wider engineering organization — QA, infrastructure, SRE, data — is one of the genuinely open ones this Library has to leave open as of 2026. It is a young enough area of organizational practice that the honest answer is closer to “nobody has published the comparable study yet” than to any settled taxonomy.

Two shapes the decision takes

The evidence above resolves into two recognizable patterns rather than a single best answer. Neither is universally correct; each is a reasonable response to a different starting condition, and most organizations end up somewhere between them by accident before choosing deliberately.

What to do this quarter

1. Write down which team currently holds the pen on tool approval — even if the honest answer is "nobody," naming the gap is the first fix.
2. Adopt DORA’s three-bucket shape — prohibited, permitted with guardrails, actively encouraged — and publish it somewhere every engineer can find without asking.
3. Put one number on one dashboard: total AI tooling spend across every card and every team, not just the centrally billed line. The DX finding that most leaders cannot answer this today is itself diagnostic.
4. Decide, out loud, whether the organization’s posture is invest-first-measure-later or demonstrate-value-first — the default is deciding it by accident, differently, every quarter.
5. Let a project or team set tighter rules than the org baseline — a stricter budget ceiling, a narrower tool list — and never the reverse. It is the same tightening-only shape this volume’s governance chapter develops in full.

None of this is a finished operating model, and this chapter has deliberately not tried to hand over one. The organizations with the clearest public accounts — Cloudflare’s centralized platform, GitHub’s tightening-only policy console — got there by building on infrastructure and governance mechanisms that already existed for other reasons, not by adopting an AI-specific playbook from outside engineering. The safest generalization the evidence supports is a narrow one: whoever already owns developer tooling quality, in DORA’s sense, is the more defensible default owner of AI tooling too, and the budget and function-rollout questions this chapter could not fully answer are worth revisiting as the data catches up.