AI Made Coding Faster. The Constraint Moved Twice.

Nearly every engineering organisation we talk to has now run the same experiment. Buy the coding agents, roll them out, give it a quarter, then look at delivery. Coding got faster. Delivery moved a fraction of what coding did.

That gap is the most common thing we are asked to explain, and it is usually treated as evidence that the tools underdelivered. It is not. It is a queue.

Speeding up the fast part does not make the line faster

Shipping software runs through three stations. Product decides what gets built. Coding builds it. Review lets it out. The throughput of the whole thing is set by whichever station is slowest, and speeding up any other station does not produce more output. It produces more inventory sitting in front of the next one.

For about twenty years coding was the slow station, which is why it got all the tooling and all the attention. AI took it out. That is a real win, and it is also the moment the constraint moved to a station most organisations have never measured, because they never had to.

So the loop is the unit, not the stage. Fix one part and the constraint moves to the next. If your instrumentation only covers the part that used to be the bottleneck, you will keep optimising a station that is already fast and wondering why the number at the end does not move.

Part one: coding, measured on evidence

The first thing that goes wrong here is measuring adoption with the wrong instrument. Seat counts tell you who has a licence. Surveys tell you what people are willing to say about themselves in a form. Neither tells you how the work is actually being done, and both flatten the thing that matters into an org-wide average.

Because adoption is not one skill. One developer is comfortable generating code and then reviews every line by hand, so the agent saves them very little. Another lets the agent run freely but cannot write a specification precise enough to get back what they wanted, so they spend the saved time on rework. Those two people need opposite advice, and an average tells you to give them the same advice.

What is worth having per developer is a read on where they already work well with AI, and the single next step that unlocks more, scored from the work itself rather than from a self-report. That is a coaching instrument, not a scoreboard. It is also the only version of adoption measurement that survives contact with an engineer who does not want to be ranked.

Part two: reviewing, where the gain survives or disappears

Faster coding floods the review queue. This is the most predictable consequence of AI adoption and the least instrumented. Writing code stopped being the constraint. Reading it became the constraint.

Here is the part that makes review genuinely dangerous to measure carelessly. A queue can clear two ways. It can be cleared, or it can be skipped. On a normal dashboard those look identical, and the skipped one looks better: approval time falls, throughput rises, the backlog drains. Every chart is green while the thing the review stage exists to do stopped happening.

The difference shows up in the shape of the approvals, not the count. Large diffs approved in a couple of minutes. One reviewer on everything. Approvals with no comments on changes that plainly warranted one. The same approver clearing a team's whole queue on a Friday. None of those is proof on its own, and together they are the signature of a queue being drained rather than read.

The other half is capacity. When a change is too big for a human to read cold, an agent taking the first pass is not a replacement for the reviewer, it is what stops the change getting an approval nobody actually performed. The goal is not to remove humans from review. It is to make sure that when a human approves something, the approval means what it used to mean.

Part three: product, which decides whether any of it counted

The third station is the one that decides whether the first two mattered at all. Fast coding against a vague objective is expensive guesswork, executed at a higher rate than before.

We have written at length about why the ticket hierarchy became the most valuable context in an engineering organisation once agents started doing the writing. The measurable version of that argument is context health: for a given objective, epic or ticket, how much of the context needed to build it correctly can a reader actually find. Not whether the fields are filled in. Whether the why, the use cases and the constraints are recoverable by someone, or something, that was not in the room.

Score that per objective and roll it up, and you get an uncomfortable but useful view: which priorities on your roadmap are being built on a record nobody can read. That number tends to explain a lot of the rework the other two stations get blamed for.

Why one loop rather than three dashboards

The reason to measure all three at once is not completeness. It is that the answer changes.

Fix review capacity and the constraint moves to specification quality. Fix specifications and it moves back to review, or into coding practice, or into something you have not looked at yet. A team that instruments only the stage that was the constraint last quarter will keep making confident improvements to a station that is no longer the problem, and the delivery number will keep refusing to move.

Measure the loop and the constraint identifies itself. That is the whole argument for looking at coding, reviewing and product together rather than buying three separate tools that each report their own stage is fine.

A dashboard requires somebody to look at it

This is the practical failure mode of every measurement product, ours included if we had stopped at charts. Process drift does not announce itself on the week it starts. Review depth degrades slowly. Ticket quality slides when a quarter gets busy. Nobody opens the dashboard on the day it would have mattered.

Which is why the useful shape here is closer to error monitoring than to business intelligence. Checks run every night against coding, reviewing and product, and file a finding when something drifts, so the thing that changed comes to you rather than waiting to be noticed. You already accept this model for production systems. It is odd that the way you build software is the part still monitored by someone remembering to check.

Then the bill arrives

All of this eventually has to answer to finance, and the AI bill is where the loop's health stops being an engineering topic.

Two cuts do most of the work. Cut spend by the type of work it produced, and watch the split between features, maintenance, tests, docs and fixes. Healthy adoption keeps that split roughly steady. When fixes and maintenance start ballooning, you are paying the tools to clean up after the tools, and the loop is leaking somewhere upstream.

Then cut the same spend by alignment: how much of it went to work with a named outcome behind it, and how much did not. In practice the unaligned share is rarely small, and it is the clearest possible restatement of the part three problem. Unhealthy specifications do not stay an engineering hygiene complaint. They show up on the invoice, in dollars, as work nobody can attach to anything the business asked for.

The two fixes are unglamorous and they compound. Fix the specifications and the unaligned block shrinks. Route each task to the cheapest model that can actually do it and the whole bar shrinks.

What this changes on Monday

The short version is that you get to stop guessing which stage to work on. You can name the station that is actually your constraint instead of speeding up the one you can already see. You can give each developer one next step with AI that came from their work rather than from a survey. You can catch a review queue that is being drained by skipping rather than clearing. And you can stop funding work that has no stated outcome behind it.

None of that requires a new process. It requires the loop to be visible, which for most teams is the one thing that has never been true.

Product engineering health is the version of this we built: coding, reviewing and product measured on evidence, a nightly agent keeping them honest, and the AI bill priced against what all of it produced.