Not Yet: When AI in Coding Is the Wrong Investment

In short: AI in coding raises the cheapest capacity in software delivery: build. When work already waits at release, in review or behind other teams, more agents add cost and escapes without adding validated value. In a modelled case of twelve teams, agents for every team left the signature metric flat; fixing coupling first gained 27% even with every value effect removed.

Should every team get coding agents?

Many engineering organisations reached the same point during 2026. Agents are in most teams, licence and token costs are climbing every quarter, and the next budget line asks for more of both. Delivery has not sped up in proportion, and the question leadership keeps being asked, how to get adoption higher, no longer feels like the problem worth solving.

The default answer deserves a fair hearing. Atlassian's AI SDLC Transformation Playbook is its clearest version: agents in planning, design, development, review and maintenance, fed by a shared context layer. The playbook is candid that planning, design, review and maintenance become the new bottlenecks once code is cheap, and it reports that its own teams cut issue cycle time from 11.5 to 6.7 days, an internal vendor figure. Atlassian is also candid about the limits: in a longitudinal study it ran with DX, AI usage rose by 65% while overall developer velocity did not move.

What the playbook maps is where an agent can help at each stage. It does not say where work waits, and that is the question that decides whether the next euro of AI turns into value or into queue.

Build capacity is the easiest to raise, and the easiest to waste

The AI Engineering Production System describes delivery as six stages, from Direction to Observe & Improve. Each stage has a capacity, a queue in front of it, an owner and a measure. Focus capacity, at Direction, is how many bets an organisation can fund and steer with a declared value. Intent capacity is the volume of change it can specify to a testable standard. Build capacity is how much change people and agents can produce. Read in detail, Verify & Release splits into two steps with one capacity each: verification capacity, how much change can be proven fit to release, and integration capacity, how much can be merged and released independently. Operating capacity is how much change production can absorb while still detecting and recovering within its objectives, and outcome capacity is how many outcomes get read after release and fed back to Direction. Context capacity and control capacity sit underneath every step.

Figure 1. The capacity map. Build capacity is the supply side; every other capacity decides how much of that supply becomes validated value.

Build capacity stands apart from the others. It is the only one that can be raised with a purchase order: a licence and a token budget. It is not infinite, since AI cost and energy use both grow with it, but it is far cheaper to raise than any other capacity on the map. That is precisely why it tends to run ahead.

When it does, the result is the Absorption Gap: supply produced faster than the organisation can absorb it. The test for any investment is the signature metric, validated business value per unit of human intervention. Raising a capacity that is not the constraint raises supply and leaves that ratio where it was.

What the evidence says about more supply

The public evidence points the same way, with the usual caution that studies measure averages and associations.

METR's 2025 randomised trial, a small study of 16 experienced developers working in large open source repositories they knew well, found them 19% slower with early 2025 AI tools, while they believed afterwards that they had been about 20% faster. Faros AI's 2025 telemetry study, covering more than 10,000 developers across 1,255 teams, reported that teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, while review time rose 91% and the link between adoption and key performance metrics disappeared at company level. LinearB's 2026 benchmarks, built on 8.1 million pull requests from 4,800 teams, report that AI pull requests wait 4.6 times longer before anyone picks them up for review. DORA's 2024 report associated each 25% increase in AI adoption with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability.

Read together, these studies describe supply rising while absorption stays put: Constraint Migration in measured form. They also leave the more useful question open. Some teams clearly do gain a great deal from agents. Which ones, and why?

A modelled case: same agents, different results

To answer it with the assessment's own method, we modelled a reference organisation, Calder Marketplace: twelve product teams, about a hundred engineers and six months of delivery data, from Jira status history and pull requests to deployments, incidents and initiatives. Calder's data is calibrated to verified industry ranges. Its change failure rate sits close to DORA's 2024 medium cluster, its review pickup falls within LinearB's 2026 benchmarks, and the output gain of its decoupled teams is close to the 98% rise in merged pull requests that Faros AI measured on high adoption teams. Where the case departs from published figures, it departs in the direction that understates the argument: its flow efficiency of 46% is well above the figures usually reported for product teams, and its agent changes wait 1.9 times longer than human ones for review, not 4.6. Calder is a reference model; it describes no single client.

Agents work in eight of Calder's twelve teams and write 35% of merged changes. Build supply runs at about 142 changes a week, and 108 are absorbed. Roughly a quarter of what Calder produces waits or comes back.

Figure 2. Where work waits in the Calder reference case. Release, where integration capacity sits, is the constraint now; verification is next.

Almost half of all waiting, 49%, happens just before release: 3.1 days per item. Changes shipped in coordinated weekly releases make up 38% of the total, and those releases fail 26% of the time, against 7% for changes released independently. Verification holds the next largest share of waiting, at 20%.

Figure 3. Same tools, different outcomes. Low coupling teams against coupled teams after adopting agents.

The team view is where the case becomes persuasive. The three teams with low coupling and good context nearly doubled their merged changes per week after adopting agents, an average gain of 93%. The five coupled teams gained 38% on average. Their agent changes were reverted twice as often (6.8% against 3.4%) and waited 57 hours for review, against 12 hours in the decoupled teams. The tools were identical; the conditions around them were not.

Figure 4. What each option does to validated value, escapes and spend.

Extending agents to all twelve teams would leave the signature metric 1% lower. Escapes per hundred changes would rise by 24%, lead time by 39% and AI spend by 45%, because the extra supply joins the queue before release and the coupled teams' agent changes load verification. Keeping agents only in the three low coupling teams holds the signature metric where it is, with 17% fewer escapes, 12% shorter lead time and 56% less AI spend. Not every team needs agents yet.

Where the larger gains sit

The waiting in the case traces back to coupling, and it shows up at different stages. Organisational coupling sits at Direction: initiatives span 2.1 teams on average and take 24 days from proposal to decision. Functional coupling sits at Intent and Build: 32% of work items depend on another team, and two thirds of all waiting in Build is time spent waiting on one. Temporal coupling sits at integration, in the coordinated releases. Semantic coupling sits at both ends and caps outcome capacity: only 15% of released initiatives ever had their outcome read, largely because no shared definition of the outcome existed.

Each kind of coupling has a matching investment. Team boundaries drawn along value streams address the organisational and functional kinds. Integration standards (contracts between services, backward compatible changes and independent deployment) address the temporal kind. Business definitions owned upstream, close to where intent is written, address the semantic kind.

The robust result is the one to hold onto. With every value effect switched off in the model, so that decoupling and shared definitions are credited only with flow and quality gains, the full sequence of investments still raises the signature metric by 27%, while agents for every team lower it by 1%. The larger figure depends on two assumptions: that more work declares its expected value once teams own outcomes, and that more outcomes get read once definitions are shared. Granting those, the same sequence nearly triples the metric. They are the most assumption sensitive levers in the model, and the case is built to show their weight separately.

The pattern has precedent well before coding agents. At La Redoute, a cloud native delivery platform and the move to independently deployable services took production deployments from 40 to 80 a day within a few months, and cut the time to create a new service from days to minutes, as the CNCF case study records. That doubling came from removing waits and coupling around the code.

Order matters

The same five investments can be made in two orders. Foundations first means decoupling, integration standards, shared definitions and a stronger verification system, with agents extended to every team last. AI first starts with the agents.

Figure 5. The same investments in two orders: foundations first raises validated value by 49% after two steps, agents first by 1%.

After two steps, foundations first has raised the signature metric by 49%; AI first has moved it by 1%. Both paths end in the same place, but AI first peaks at 14.3 escapes per hundred changes along the way, and its value arrives two steps later. Two further details from the model matter for planning. Decoupling on its own pushed integration past its capacity, which is why it belongs in one package with integration standards. Strengthening verification added nothing until verification became the constraint. The practical rule is to invest one stop ahead of the constraint, where the next queue will form, and nowhere else yet.

When AI in coding is the right call

The model reverses where it should. A second reference organisation, four teams already decoupled, releasing independently and working from shared definitions, gains 27% on the signature metric from agents alone, and its constraint moves to Intent. For a company in that position, buying agents first is the right decision, and the next question becomes intent capacity.

Four questions tell the two situations apart before money is committed:

Is build where this team's work actually waits?
Can the team release without coordinating with other teams?
Do its agent changes survive review and production at the same rate as its human changes?
Does someone read the outcome of its work after release?

Four answers of yes make a strong case for agents. Each no names the investment that should come first.

What to measure before the next licence

A board can follow five numbers each quarter: the signature metric, the Absorption Gap, the constraint now and where it moves next, lead time, and escapes per hundred changes. Behind them, a CTO tracks three probes per stage (how long work waits, how much escapes or comes back, and how many human minutes each change consumes), with agent reach and effectiveness as diagnostics. Adoption figures belong among those diagnostics. Building that instrumentation from delivery data is the subject of a forthcoming piece.

The executive mandate

Treat every expansion of AI in coding as an investment that has to clear the same bar as any other: evidence that the stage it feeds has headroom. Fund the coupling work as delivery investment, not as architecture housekeeping, and gate each wave of agents on the probe that shows the constraint has moved.

Which capacity is your next euro of AI actually raising?

Read further

FAQ

Is this just the Theory of Constraints?

Largely, yes, applied to a supply shock. Goldratt's point that improving a stage that is not the constraint does not improve the system holds; what AI changes is the speed and cost at which one capacity, build, can be raised. The capacity map adds the stages, the coupling behind each queue and a metric that counts validated value rather than output.

Should we stop using AI coding tools?

No. The case argues for targeting them. Teams with low coupling, independent releases and good context gained strongly; coupled teams gained little and added review load and escapes. Keeping agents where they pay, while fixing the conditions elsewhere, held value at less than half the spend.

How do I tell which teams are ready for agents?

Compare each team before and after adoption on three things: change throughput, the revert rate of agent changes against human ones, and how long agent changes wait for review. Then check how much of the team's work depends on other teams and how it releases. The four questions above summarise the test.

What if build really is our constraint?

Then agents are likely the right investment, as the counter case shows. Measure where work waits first; if build holds the largest queue and releases are independent, buy capacity there and watch for the constraint moving to intent or verification next.

How long before decoupling pays?

It depends on the coupling. Integration standards can show results within a quarter; redrawing team boundaries usually takes several. The model suggests packaging the two, because decoupling without integration standards floods the release queue.