Coding speed was the bottleneck that software teams complained about for decades. It was concrete, measurable, and satisfying to address. Then GitHub Copilot launched, Cursor took off, and a generation of AI pair programmers arrived. Now Andrew Murphy’s piece circulating on Hacker News is making a pointed observation: if you thought writing code faster would fix your team’s output, you were optimizing the wrong stage.
The observation is a direct application of Goldratt’s Theory of Constraints, which says that any system has one binding constraint, and speeding up non-constraints only piles more work in front of the actual bottleneck. In manufacturing, that means inventory stacks up before the slow machine. In software, it means pull requests pile up in review queues.
The Inner Loop Is Already Solved
The “inner loop” of software development is everything a single developer does in isolation: write code, run tests, iterate, commit. AI tools are genuinely strong here. Code completion, generation from a natural language comment, refactoring a method, explaining an unfamiliar codebase, writing test scaffolding. These tasks have gotten dramatically faster. Engineers report writing certain categories of code three to five times faster than before, and that figure is plausible for boilerplate-heavy work.
But the inner loop has never been what determines when software ships. The DORA research from Google, which has tracked software delivery performance across thousands of teams for over a decade, identifies four key metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. None of these metrics measure how fast an individual writes code. They measure how fast code moves through a system, and whether it works when it gets there.
Elite teams in DORA research deploy multiple times per day and recover from incidents in under an hour. What separates them from lower performers isn’t typing speed. It’s process characteristics: trunk-based development, automated testing with high coverage, deployment automation, and a culture of small frequent changes. These are organizational properties, not individual capability properties.
Review Is a Queue, Not a Gate
The place where faster code generation most visibly creates pressure is code review. Review has always had a throughput ceiling: one reviewer can read only so much code per day, and that capacity doesn’t scale with the number of contributors or the volume of pull requests submitted.
Approval workflows compound this. A pull request that requires two approvals doesn’t take twice as long as one that requires one. It takes the time until the second reviewer is available after the first has approved, which is a separate scheduling problem from the first. A three-stage approval chain multiplies queue wait times rather than adding them. Teams that added approval requirements for compliance or risk management did so when code volume was lower. Those policies now operate against substantially higher code volume without a corresponding increase in reviewer capacity.
Research from Laura MacLeod et al. on code review at Microsoft found that review-related delays account for a significant fraction of lead time from commit to merge. The average wait time for a first review response was measured in hours to days. AI coding tools change none of that. If a developer generates code in a third of the time, the pull request arrives in the review queue faster, and then waits the same amount of time it always did.
What does change is the pressure on that queue. A team that previously produced ten pull requests per week now produces thirty. The same two senior engineers who reviewed the ten are now expected to review the thirty, while also writing more code themselves with AI assistance.
Planning and Clarity Are Upstream Bottlenecks
Another constraint exposed by faster code generation is the clarity of specifications. Writing code fast against an unclear spec produces incorrect software quickly. The rework cost of a misunderstood requirement is higher than the cost of writing slowly against a correct one.
Teams that have adopted AI tools heavily report a pattern: they can produce implementations rapidly, but they spend more time than before in early alignment conversations, because the cost of generating something wrong and redoing it becomes more visible. The bottleneck moves upstream to whoever owns the product decisions.
Fred Brooks identified this dynamic in The Mythical Man-Month in 1975. The hard part of building software isn’t the writing; it’s deciding what to build, communicating that clearly, and verifying that what was built matches what was intended. Those problems haven’t changed. AI tools make the writing step cheaper without touching the others.
CI Pipelines Under Higher Load
Deployment pipelines are another system sized for a certain code volume. A monorepo with a fifteen-minute test suite running on a shared build cluster has a specific throughput ceiling. More commits hitting that pipeline means longer queue times for each individual run, or more build infrastructure investment, or both.
Teams generating more code faster discover that CI pipelines which were adequate before are now a regular source of waiting. The fix is more build capacity or faster test suites, both of which require investment that wasn’t anticipated when the team adopted AI coding tools. This isn’t a hypothetical; it’s a common complaint in engineering retrospectives at organizations that moved quickly on AI adoption without auditing the rest of the pipeline.
The Open Source Dimension
The Hacker News discussion on Murphy’s piece surfaced a dimension that deserves separate attention: open source projects are seeing the review burden compound faster than anywhere else. Maintainers of popular libraries have limited time, and the volume of AI-assisted contributions is increasing. The quality distribution of those contributions varies widely, and reviewing a mediocre AI-generated patch takes as much time as reviewing a mediocre human-written one.
Maintainers across projects including CPython, Linux, and popular npm packages have noted publicly that review bandwidth is their binding constraint. Drew DeVault’s essay on the topic describes a signal-to-noise problem that is getting harder to manage as submission volume increases without a corresponding increase in maintainer capacity. The solution that open source projects arrive at, when they arrive at one at all, tends to be stricter submission requirements or smaller contributor circles, both of which reduce the theoretical benefit of easier code generation.
Where the Constraint Actually Lives
The implication for teams is straightforward: adopting AI coding tools without examining the full delivery pipeline means the bottleneck moves rather than disappears. If code review was already slow, it gets slower under higher volume. If CI was already a queue, it queues longer. If requirements are often unclear, more incorrect code gets written faster.
The teams that extract the most value from faster code generation are those that already run tight delivery loops, with small pull requests, fast review cycles, high test coverage, and automated deployment. For those teams, AI tools multiply an already-efficient process. For teams with long lead times and unclear processes, AI tools accelerate the production of work that then sits waiting for the next slow step.
Goldratt’s prescription was to find the actual constraint, subordinate everything else to it, and then work to elevate it. In software teams right now, that usually means measuring pull request cycle time and deployment pipeline throughput before assuming that faster code generation will improve delivery performance. The cycle time metric tells you where the time actually goes. For most teams, the answer will not point at the editor.