More code does not mean more delivery: where AI moves the engineering bottleneck

Over the past couple of years, most engineering teams started using AI to generate code: autocompleting functions, drafting first versions of tests, refactoring modules, summarizing unfamiliar code, reviewing pull requests. The most visible effect is volume — more lines, more commits, more pull requests opened per week. The less visible effect, and the one that matters most for engineering leaders, is that this volume does not always reach production any faster. This piece is about that mismatch: what actually got faster, why producing code is not the same as delivering it, and where the bottleneck tends to migrate once code stops being the limiting factor.

This is not an anti-AI piece, nor a generic best-practices list. It is reasoning through a specific problem: teams that increased code generation and, when measuring what actually matters — time from idea to production — did not see a matching improvement. Understanding why helps decide where to invest next, instead of assuming the answer is always "more AI" or always "more people."

What actually got faster with AI

It is worth naming what genuinely changed, without hype and without automatic distrust. Writing repetitive code got faster — boilerplate, standard integrations, CRUDs, translating between languages and frameworks. Producing a first draft of tests, documentation, and auxiliary scripts got faster. Understanding an unfamiliar piece of code got faster, which helps with legacy system maintenance. For an individual contributor, that is a real productivity gain on mechanical tasks.

What AI does not accelerate on its own is the rest of the work of shipping software: understanding the business problem, negotiating priorities and trade-offs, getting a pull request reviewed and approved, coordinating a change across teams, deploying safely, verifying that production behavior matches expectations. None of those steps automatically speeds up just because the code was generated faster.

Why producing code is not the same as delivering it

Delivery is the time between a validated idea and it running in production, creating value. Producing code is only one step in that path — and, in mature teams, usually not the longest one. If the rest of the delivery system (review, testing, approval, deploy, validation) keeps the same capacity as before, generating more code faster does not increase delivery. It increases work waiting somewhere else in the queue.

None of this is new reasoning — it is how any queueing system behaves when input speeds up and output does not. What is new is that AI made input cheaper and faster to accelerate than any other step in the flow, which exposes bottlenecks that used to hide behind slower code production.

Where the bottleneck can migrate to

When code production stops being the limiting factor, the bottleneck does not disappear — it migrates somewhere else in the system. Usually to one (or more) of five areas: unclear direction and prioritization, decisions and ownership concentrated in too few people, architecture and dependencies that require coordination for small changes, delivery flow with queues and large batches, and quality — the difficulty of confidently verifying a larger volume of change.

Decisions and review as queues

Code review is a queue, with wait time and processing time like any other. When the volume of changes grows and the number of qualified reviewers does not grow with it, wait time goes up — even if each individual review does not get slower. It gets worse when pull requests also grow larger: bigger changes are more expensive to review, easier to rubber-stamp without full attention, and riskier to revert.

The same applies to technical decisions. Teams that concentrate architecture or domain decisions in two or three people can function fine when the volume of proposed changes is low. When that volume grows — because a change proposal is cheaper to produce — those same people become the new bottleneck, even if they remain technically competent. The problem is not decision quality; it is the number of decisions waiting on the same limited attention.

That suggests two useful questions to investigate, rather than a ready-made answer: how long does a typical technical decision wait before it gets made, and how many different people can make each type of decision without escalating to the same level.

A counterpoint is worth making: spreading every decision out to shrink the queue also has a cost. Decisions made without enough context create inconsistency, rework, and eventually the same decision gets reopened months later. The goal is not eliminating concentration — it is making it deliberate: which decisions genuinely need to pass through few people, and which can have an owner closer to the work, with context recorded so it does not depend on memory.

Architecture and dependencies as a constraint

AI is especially good at making a change work inside existing code — including code that is poorly encapsulated. That is a short-term advantage and a medium-term risk: an agent (or a person assisted by one) can change a behavior by touching several coupled services or modules without anyone needing to deeply understand why that coupling exists. The change works, but the system gets a little harder to change next time.

A practical signal of an architectural constraint is when changes that are small from a business perspective require coordination across several teams or repositories. The fix is not asking AI to "refactor" the system all at once — broad rewrites without understanding the real constraint tend to trade one set of known risks for an unknown one. The more defensible path is usually picking one specific, high-impact boundary and decoupling it incrementally, with evidence that it is in fact the constraint causing the most friction.

Verification, quality, and observability

If generating code got cheaper, verifying it did not get cheaper by the same proportion. Review, testing, observability, and fixing regressions still require human judgment, business context, and often runtime (running tests, watching production metrics, investigating an incident). When change volume grows faster than verification capacity, the observable result tends to be one of three things: shallower reviews, more rework after code reaches production, or a recurring sense that "the team does not fully trust" recent changes.

That is not an argument against using AI for code generation — it is an argument for treating verification as a capability that needs to grow alongside it. Clear guardrails on which types of change require stricter human review, automated tests as a prerequisite (not an afterthought), and observability that lets the team quickly detect unexpected behavior all reduce the cost of supervision without requiring every line to be reviewed by hand. There is a trade-off: too many guardrails slow everything back down, including low-risk changes. The practical criterion is usually proportionality — more scrutiny where the cost of being wrong is high (data, payments, security), less where the cost of reverting is low.

What to measure besides code volume

Lines of code, commits, or pull requests per week measure activity, not delivery. More useful metrics for understanding whether the whole system is keeping up with code generation include:

• Lead time: the time between real work starting and it reaching production.
• Wait time for review, separated from actual review time.
• Average size of pull requests and work items.
• Work in progress at once, compared to work finished end to end.
• Rework, revert, and regression rate after delivery.
• Time to detect and time to fix an incident.

The value is less in any absolute number — every system has its own baseline — and more in the trend: are these metrics improving, worsening, or holding steady since AI usage increased on the team?

A starting investigation roadmap

Before hiring more people, rewriting a system, or expanding AI usage, a simple investigation roadmap helps: pick one critical business flow and measure its real end-to-end lead time; within that flow, separate active time from wait time; talk to a few people on the team about where they feel work gets stuck most often; and check whether rework, reverts, or incidents increased since AI adoption grew. Those four observations alone usually point to whether the likely bottleneck sits in direction, decisions, architecture, flow, or quality.

When the initial investigation is not enough — because the decision involves legacy architecture, production risk, or a significant investment choice — the next step is usually a deeper investigation, with access to the code, the infrastructure, and a prioritized action plan. That is the role of the Production X-Ray.