Back to journal
12 min read

AI coding is a local optimization

Why AI-first engineering only creates business value when it improves the whole delivery system, not just the speed of producing code.

Illustration of AI agents accelerating code while the delivery pipeline reveals a bottleneck at review and validation

Every engineering organization I speak with is feeling some version of the same pressure to become AI-first. Sometimes that pressure comes from executives who have read enough McKinsey-ish reports to know that AI should be on the board agenda. Sometimes it comes from the market, where every competitor seems to be announcing some kind of agentic development workflow. And sometimes it comes from engineers themselves, because once you have used a good coding agent for the right task, it is hard to pretend nothing changed.

In a few recent conversations with companies in Copenhagen, the same question kept coming up in different words: if developers are suddenly producing more code, how do we know that the business is actually getting more value?

The shift is real, but I think we are still using the wrong language for what is happening.

Most conversations about AI in software engineering start with the developer:

Those are useful questions, but they are not the business question. The business question is simpler and much harder:

Are we getting valuable changes into production faster, with acceptable risk, and learning from them sooner?

If the answer is no, then the fact that developers are producing code faster is mostly a local optimization, and local optimizations are where organizations often fool themselves.

The code was never the whole system

There is plenty of evidence that AI helps with code production. GitHub’s early Copilot research found that developers completed a controlled coding task 55% faster with Copilot. A later GitHub analysis of nearly one million Copilot users found that developers accepted roughly 30% of suggestions on average. Stack Overflow’s 2025 survey says 84% of respondents are using or planning to use AI tools in their development process, and 51% of professional developers use them daily. DX’s Q4 2025 impact report, based on data from over 135,000 developers across 435 companies, estimates industry-wide AI coding assistant adoption at 91%, with developers reporting 3.6 hours saved per week on average.

So whether AI can help people write code is no longer the interesting debate. The interesting question is whether faster code production improves the whole software delivery system, which is a different thing entirely.

Software delivery is not:

idea -> code

It is more like:

idea -> context -> specification -> implementation -> review -> CI -> QA -> deployment -> customer behavior -> learning -> next idea

In many organizations, code production was not the slowest part of that chain, just the most visible one. AI makes this uncomfortable because it accelerates the visible part first. Suddenly the organization can produce more diffs, more branches, more tests, more generated documentation, more “almost done” work. If the next step in the chain cannot absorb that work, throughput does not improve; the extra output just piles up as inventory in front of the next constraint.

A quick detour through the Theory of Constraints

The Theory of Constraints, introduced by Eliyahu Goldratt in The Goal, starts from a very simple observation: every system has a constraint. Something determines the maximum throughput of the whole system. In a factory, it might be a machine. In a logistics network, it might be a loading dock. In a software organization, it might be a senior engineer who has to approve everything, a fragile test environment, a manual QA process, a release committee, or the fact that nobody can describe what “done” means before work starts.

The important part is that improving any step that is not the constraint does not improve the system’s throughput. The improved step may look better in isolation, the team operating it may feel more productive, and the dashboards may move in nice directions, but the system as a whole still moves at the pace of the constraint.

This is the line from The Phoenix Project that keeps coming back to me:

Any improvement not made at the constraint is just an illusion.

That sounds dramatic until you have seen it happen in real engineering teams. A team adopts AI coding tools, developers produce more code, PR volume goes up, and everyone feels faster. Then cycle time does not improve. Review queues grow. QA gets overloaded. CI becomes flaky. Releases get bigger because there is more work waiting to be bundled together. The business sees more activity, but not more outcomes. AI did not break the system; it made the existing constraint more visible.

Illustration of a software delivery pipeline where the slowest station determines overall throughput

Brent is your review queue now

One of the most memorable ideas in The Phoenix Project is Brent. Brent is the engineer everyone needs. He knows the ancient systems, gets pulled into every outage, and is needed for Phoenix, for production incidents, for deployments, for changes, for everything nobody else fully understands. Brent looks like a hero until you realize he is the constraint. The organization keeps starting work that depends on him, but he has only so many hours, so the more work people throw at him, the longer the queue becomes. The system gets slower because everyone is competing for the same constrained resource.

This part maps almost too cleanly to AI coding. When AI increases code production, the new Brent may not be a person. It might be:

AI does not remove these constraints automatically; in many cases it feeds them. If a team used to open 20 PRs per week and now opens 40, the review system has to change. If agents can create features from vague tickets, the specification system has to change. If generated code can touch more surface area faster, testing and release controls have to change. If more experiments can be shipped, product analytics and customer feedback have to change. Otherwise the organization is just producing more work-in-progress, and WIP has a real cost: merge conflicts, context switching, stale branches, review fatigue, and the psychological tax of “I am blocked on three PRs but already started two new tasks because I did not want to sit idle.” That is congestion, not acceleration.

The market data is already pointing in this direction

The interesting thing is that the public data is starting to say the quiet part out loud.

DORA’s 2024 report found that AI adoption improved several local or upstream measures: documentation quality, code quality, code review speed, approval speed, and code complexity. That sounds great, but the same report also found that AI adoption was associated with a 1.5% reduction in delivery throughput and a 7.2% reduction in delivery stability for every 25% increase in AI adoption. That is a strange result only if you assume coding speed and delivery performance are the same thing.

DORA’s own hypothesis is very close to the Theory of Constraints lens: AI may increase code generation speed so much that teams forget fundamentals like small batch sizes and robust testing. Larger changes are slower and more prone to instability, so the local gain in coding can become a downstream loss in delivery.

The 2025 DORA report is more nuanced and more optimistic, but its core message is still systemic: AI is an amplifier that magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. The report says 90% of respondents use AI at work and more than 80% believe it has increased productivity, while 30% still report little or no trust in AI-generated code. A system that produces more code without raising trust will not ship faster; it will just move more uncertainty into review, QA, and production.

Stack Overflow’s 2025 survey tells a similar story from the developer side. AI usage is high, trust is not. More developers actively distrust AI accuracy than trust it, the biggest frustration, cited by 66% of developers, is “AI solutions that are almost right, but not quite,” and the second is that debugging AI-generated code is more time-consuming.

The shape of the problem is that AI lowers the cost of generating code, but does not automatically lower the cost of understanding, validating, approving, deploying, and learning from that code.

So what should change?

If you take the Theory of Constraints seriously, the AI adoption playbook does not start with “buy licenses for everyone.” That may be part of it, but the actual strategy is:

  1. Map the system.
  2. Find where work waits.
  3. Use AI and process change to improve the constraint.
  4. Repeat when the constraint moves.

In software delivery, I would look at the pipeline in roughly this order.

1. Context and acceptance criteria

The first bottleneck might be before code. This is the part people underestimate. Agents are very sensitive to the quality of the task definition. A vague ticket that says “improve billing flow” is an invitation for the agent to invent missing context, not a spec it can execute.

Good agent-ready work usually includes:

This is the human–agent contract, and it is more important now than it was. In the old world, a senior engineer could fill in the gaps from memory. In the AI-assisted world, the gaps become expensive because the agent will fill them in quickly and incorrectly. If your constraint is unclear work, better coding agents will not help much; they will just create polished implementations of ambiguous ideas.

2. Pull request size and shape

AI makes it easy to generate large diffs, which is exactly why teams need stronger pressure toward smaller changes. Small PRs are a control system more than a preference: they reduce review time, reduce blast radius, reduce merge conflicts, and make rollback easier. They also make AI-generated code easier to inspect because the reviewer can reason about one coherent change instead of a pile of adjacent edits.

One of the simplest AI-era rules I would introduce is:

Agents can produce a large plan, but they should ship small PRs.

The agent can break the work into steps, prepare the dependency order, write the tests, and even draft the PR descriptions and rollout notes, while the unit of review stays small enough that a human can understand it.

3. Risk-based review routing

Not every PR deserves the same review path, and this is where AI can help a lot. A typo fix in documentation should not wait behind a payment authorization change, a generated test update should not require the same level of review as a migration touching customer data, and a CSS tweak should not be routed like an authentication refactor.

The future review system probably looks more like risk routing:

Tools like BugBot, CodeRabbit, Copilot Code Review, Greptile, and similar products are early signals of this direction. The specific vendor is not the point; the pattern is. Use machines to remove low-value review work so humans can spend scarce attention on judgment, which is how you exploit the constraint instead of wasting it.

Illustration of pull requests being routed by risk: low-risk changes flow through automated checks, while critical changes go to human reviewers

4. QA as a feedback system, not a final inspection department

If AI doubles the amount of code entering QA and QA remains a manual final inspection step, the bottleneck has simply moved. The answer is to turn QA into a faster feedback system, not to remove it.

Some of that is deterministic and boring in the best possible way:

Some of it can be agentic:

The key is that QA cannot remain only a downstream queue; it has to become part of the loop that lets agents and humans correct course earlier.

5. Deployment and production learning

The last constraint might be after the code is merged. This is common in larger organizations, where teams can write and review code, but deployment is slow because of release windows, change advisory boards, manual approvals, fragile environments, or missing rollback mechanisms. In that world, AI-assisted coding can make the backlog behind release even bigger.

So the AI-first engineering conversation has to include continuous delivery, feature flags, progressive rollout, observability, fast rollback, production health checks, product analytics, and customer feedback. The point of software delivery is validated change in the hands of users, not merged code, and until the organization can observe whether the change worked, the loop is not complete.

What to measure if you actually care about value

This is where many AI adoption programs go sideways. They measure what is easy:

Those metrics are not useless. Adoption and usage matter, and DX is right to call self-reported time savings a leading indicator. But if the question is business value, these metrics are incomplete on their own. I would pair them with system metrics:

Then I would add a few AI-specific questions:

The point is to find the constraint, not to build a giant dashboard nobody reads. If PRs sit for two days before review, review is a candidate constraint. If reviews happen quickly but CI takes hours and flakes constantly, CI is the candidate. If everything merges but waits for a weekly release train, deployment is the candidate. If everything ships but nobody knows whether customers care, feedback is the candidate. You cannot know where to apply AI until you know where the system is waiting.

The AI-first company is not the one with the most agents

I think this is where the language around “AI-first” needs to mature. An AI-first engineering organization is the one that redesigns its delivery system around faster learning, not necessarily the one running the most autonomous coding agents in parallel. That means better specs at the beginning, smaller changes, stronger contracts, risk-based review, automated checks, agentic QA where it helps, human judgment where it matters, progressive delivery, and production feedback. AI belongs in all of those places, not only in the editor.

The companies that get this right will reduce the time between a business idea and reliable customer learning, rather than simply producing more code. The companies that get it wrong will have impressive demos, busy agents, bigger PR queues, tired reviewers, and executives wondering why the AI budget did not show up in the business metrics.

The uncomfortable truth is that AI does not remove the need for engineering discipline, it raises the return on it. If your system is healthy, AI will amplify it. If your system is slow, opaque, and overloaded, AI will amplify that too.

So before asking how to get every developer to produce more code with AI, I would ask where valuable work waits in the system. That is usually where the real AI opportunity is hiding.