AI coding is often described as a way to get through the same work faster. That assumes the amount of work stays fixed: a team has a backlog, AI shortens each task, and everyone gets time back.
Software rarely behaves that neatly. When implementation becomes cheaper, more ideas become worth trying. Existing plans grow in scope. Small improvements that once cost too much enter the backlog. A faster way to produce code can save time on individual tasks while increasing the total amount of software work a team creates for itself.
Code generation is only one part of delivering and operating software.
Cheaper code creates more demand
In software, a feature that once seemed too expensive can become a reasonable experiment. A team may try several implementations instead of choosing one in advance. People outside engineering can prototype tools for problems they encounter in their own work.
In After Automation, Dan Shipper describes how this has played out at his company: more people can create software changes, while engineers spend more time reviewing and improving what gets produced.
The work moves downstream
A generated change still has to enter a real system. Someone has to decide whether it should ship, verify that it works beyond the immediate task, deploy it, and maintain it over time.
As generation speeds up, these activities take a larger share of attention. Time saved while writing code can reappear when a larger number of changes need to be understood, corrected, and integrated.
One enterprise case study of an AI-forward engineering organization found that per-developer pull-request throughput more than doubled after an internal push for greater AI use. Review demand rose with it, and automated review eventually handled more activity than human review. The study could not isolate AI as the cause, and pull requests are not a measure of product value. It still shows what happens when the rate of proposed changes rises: the review system has to grow with it.
For many teams, code review is the obvious next bottleneck. I do not think it is the final one.
What comes after review
Review, testing, and deployment are also becoming easier to automate. Agents can already inspect changes, run checks, suggest revisions, and keep working after the first implementation. If those systems improve, some of today’s downstream pressure will move again.
The longer-lived constraint is selection: deciding which changes are worth introducing, what standard they have to meet, and who will own the result. Those decisions depend on the product, the architecture, the risks, and the people affected by the software. Better models can supply more analysis, but they do not remove the need to choose what the system should become.
I would call part of this taste. Not visual polish, but a learned sense of which problems are worth solving, what good looks like in a particular system, and when a technically valid change still points in the wrong direction. Jason Liu describes taste as something built through attention: studying what other people made closely enough to see the decisions behind it.
Once a team has decided what good means, it can encode part of that judgment in tests, policies, interfaces, deployment rules, and observability. These controls can enforce the standard; they do not decide what it should be. Faster generation becomes useful when that surrounding system can absorb more attempts without lowering the standard for what ships.
The 2025 DORA report reaches a similar conclusion from organizational data: AI tends to amplify the system around it. Fast tests, clear ownership, small changes, reliable deployments, and useful production signals give a team more room to experiment. Ambiguous requirements and slow feedback produce a larger queue that nobody can confidently merge.
What the tools should optimize for
Most AI coding tools still compete on how quickly they can produce and complete changes.
I expect tools to focus next on control over change. A useful system should keep changes small enough to inspect, connect them to tests and production signals, and make reversal ordinary. It should also preserve enough context for the next person to understand why the change exists and what would make it unsafe.
Some of this will happen inside coding agents, and some in the delivery process around them. Generating an implementation is likely to become easier than building a dependable path from an idea to software a team can support.
Measure the whole change
Lines of code and pull-request counts become less informative as generation gets cheaper. Even task duration can hide work deferred to review, integration, or maintenance.
Some companies have already made AI use itself a score. The practice is sometimes called tokenmaxxing, the push to maximize how many AI tokens a person or company uses. Meta ran an internal competition that rewarded token use. Amazon later removed an unofficial usage leaderboard after employees gave agents unnecessary tasks to move up it. The leaderboard rewarded more usage, regardless of what it produced.
Usage is the wrong level of measurement. Teams need to ask whether something useful reached production sooner and what extra work followed. That includes rework, incidents, maintenance, and the effort needed to understand the system later.
AI coding is likely to make more software economical to attempt. The teams that benefit most will not be the ones that produce the most code. They will be the ones that can discard weak changes early and carry the useful ones into production without losing track of who owns them.