The bottleneck moved to review

Every team we talk to has the same first question about AI: how much faster will it make us? It is the wrong question, and answering it honestly is usually the most useful thing we do in a first call.

Here is the honest version. AI-assisted teams ship meaningfully faster. They do not ship ten times faster. Anyone promising 10x is selling you something, and the number they are quoting is almost always measured on the part of the job that was never the expensive part.

Writing was never the constraint

Think about where the time actually goes on a piece of work that reaches production. Someone decides what to build. Someone designs how it fits the system you already have. Someone writes it. Then someone reviews it, tests it, works out what it broke, documents it, and takes responsibility for it when it misbehaves at 2am.

AI collapsed exactly one of those steps. The generation step — the one that a good engineer was already fast at — is now close to free.

What that does is not speed up delivery uniformly. It moves the queue. Code arrives at the review step faster than the review step can absorb it, and the review step is staffed by the same number of people it was staffed by last year. You have not removed a bottleneck. You have relocated it to the most expensive, least parallelisable part of the process.

The cost shows up as something you cannot explain

The visible symptom is a backlog of pull requests. The expensive symptom is quieter.

When generation outruns review, teams start approving code they have skimmed rather than read. It usually works. It passes the tests. It ships. And six months later somebody asks how a particular behaviour came about, and nobody on the team can answer — not because the code is bad, but because no human ever held the reasoning behind it.

We call that the gap between what your software does and what your team understands. Messy code is fixable; anyone can refactor. A team that cannot explain its own system is a much harder problem, because the knowledge was never created in the first place. You cannot refactor your way back to an understanding nobody had.

This is the failure mode that matters most for small and growing companies, because you do not have the bench depth to absorb it. One person leaves and a whole subsystem becomes archaeology.

What to do about it

None of this is an argument against building with AI. We build with it on every engagement. It is an argument for putting your effort where the constraint actually is.

• Budget for verification, not generation. If AI doubles the code your team produces, the review and test capacity has to move too. In practice this means investing in automated checks that are trustworthy enough to carry real weight, so human attention goes to the decisions rather than the syntax.
• Make intent explicit before the agent starts. The cheapest review is the one where the reviewer already knows what the change was supposed to do. Writing the plan first is not ceremony; it is what makes the output checkable.
• Keep a human on the hook for every change. Not as a rubber stamp — as the person who can explain it later. If nobody can, the change is not finished.
• Put guardrails on anything that runs by itself. An agent can look perfectly healthy while quietly burning your budget. Spending limits, alerts, scoped permissions and an off switch should be part of shipping it, not something you add after the first surprise invoice.

The uncomfortable version

The reason this is worth writing down is that the standard AI pitch has it backwards. It sells velocity, which is the part that got cheap, and stays quiet about verification, which is the part that got more expensive and now determines what you can safely ship.

If you are deciding what to do with AI this quarter, the useful question is not "how much faster can we go". It is "what would we have to be able to check, in order to go that fast safely" — and then whether you are willing to fund that.

That answer is usually less exciting than a 10x claim. It is also the one that survives contact with production.