Andrew Murphy’s post landed on HN with 300+ points and over 200 comments because it names something the industry has been dancing around for two years: faster code generation is not the same as faster software delivery. The argument is obvious once stated, yet the past two years of tooling investment have concentrated heavily on exactly that optimization.
The useful frame here is Eli Goldratt’s Theory of Constraints, laid out in “The Goal”. A system’s throughput is determined by its slowest step. Improving any other step does not improve throughput; it builds inventory at the bottleneck. Apply that to software delivery and the implications are uncomfortable for anyone who bought seats on an AI coding tool expecting it to move their delivery curve.
A software delivery pipeline has many steps: requirements clarification, implementation, code review, automated testing, deployment, and production validation. Speeding up implementation while leaving everything else constant means PRs arrive at the review queue faster than reviewers can process them. You have improved one step and created an inventory problem everywhere downstream.
What the queue looks like in practice
Little’s Law, from queuing theory, states that L = λW: the average number of items in a system equals the arrival rate multiplied by the average time each item spends there. If review bandwidth is fixed and the arrival rate λ increases because developers are generating code faster, then L, the number of PRs in flight, grows proportionally.
More PRs in flight means more merge conflicts, more context switching as reviewers jump between unrelated changes, more stale branches, and more integration failures when multiple long-running branches finally merge. Teams that get burned by this pattern describe it consistently: they are shipping more code but somehow things feel slower. That is not a paradox; it is queuing math.
Code review is not just reading code. It involves reconstructing intent, checking edge cases, validating that a change fits the broader system design, and catching what automated tests miss. That work scales with the cognitive complexity of the change, not with how fast the code was written. A PR generated in ten minutes with AI assistance takes the same amount of reviewer attention as one that took two hours to write by hand.
Where the real bottlenecks live
The DORA (DevOps Research and Assessment) research program, which underlies Nicole Forsgren, Jez Humble, and Gene Kim’s “Accelerate”, identifies four metrics that distinguish high-performing engineering teams: deployment frequency, lead time for changes, mean time to recovery, and change failure rate. None of them are about code writing speed.
Elite performers as classified by DORA deploy multiple times per day with lead times under an hour. Low performers deploy less than once every six months with lead times measured in months. The gap between those two categories is not typing speed or even raw engineering talent. It is organizational structure, deployment pipeline automation, testing culture, and how teams handle incidents. These are slow, structural changes that do not appear in a tool demo.
The State of DevOps reports consistently find that developer productivity correlates with fast feedback loops: CI that finishes in minutes, test suites that are reliable rather than flaky, and PR review cycles measured in hours rather than days. Organizations with two-day average review times do not become elite performers by giving everyone Copilot or Cursor. They become elite performers by fixing the two-day review cycle.
Research on how developers actually spend their time reinforces this. Across multiple surveys, actual code writing accounts for roughly 30 to 40 percent of working hours. The rest goes to meetings, debugging, code review, documentation, and coordination. AI tools that optimize code writing are optimizing a minority of the workday.
The individual vs. team throughput mismatch
Software engineering organizations are largely structured around individual contribution metrics: tickets closed, PRs merged, features shipped per developer. Those metrics made sense when implementation speed was a meaningful variable. AI tools expose the gap between individual output and team throughput.
A single developer generating PRs at twice their previous rate creates a local improvement that can degrade global performance. Reviewers who share a queue now face a higher arrival rate from that developer. If review capacity does not scale alongside PR volume, the queue grows, latency increases for everyone, and developers whose output was not accelerated see their work buried behind a backlog of AI-assisted code.
This is a structural problem, not a personal one. The system was not designed to absorb the throughput increase, and individual performance metrics do not surface the team-level effect. The developer looks productive by every metric the org is measuring; the team looks slower by every metric that matters.
Teams that navigate this well tend to shift focus from individual output metrics toward cycle time metrics: how long does a PR sit before first review, how long from merge to deployment, how often does CI fail. These numbers reflect system performance rather than individual performance, and they respond to the interventions that actually matter.
The code generation gains are real, just not primary
None of this means AI coding tools are useless. They reduce time on mechanical tasks: boilerplate generation, test case scaffolding, format translation, explaining unfamiliar code to new reviewers. Those are genuine gains at the individual level.
The issue is that these gains are local. A developer who generates twice as much code per day is not twice as productive in terms of shipped value unless the rest of the system can absorb that output at the same rate. In most teams, it cannot.
What helps is deploying AI assistance across the full delivery pipeline rather than concentrating it at the code-writing stage. Automated PR summaries reduce the time a reviewer needs to orient to a change. AI-assisted test generation catches regressions before code reaches the review queue. Documentation that generates alongside code reduces the clarifying back-and-forth that clogs review threads. These are systemic interventions. They address the constraint rather than increasing throughput at a non-constraint step.
The inventory problem compounds
In lean manufacturing, inventory between process steps is waste: capital tied up in goods that have not reached the customer. The software equivalent is work in progress: unmerged branches, undeployed features, incidents that are resolved in staging but not in production.
High work in progress correlates with slower delivery and higher defect rates. This is counterintuitive because having many things in flight simultaneously feels productive. The reality is that each item in progress requires ongoing maintenance. It needs to stay synchronized with the main branch, it accumulates context that reviewers need to reconstruct weeks later, and it creates integration complexity when it finally merges alongside three other large changes.
AI tools that make individual developers faster can, if not paired with process changes, steadily increase average work in progress. The developer writes more features per sprint; the features pile up in review; the reviewer approves them in batches; the deployment carries accumulated, poorly-understood risk.
What the argument is actually pointing at
The pattern the HN thread surfaces across many team contexts is that organizations adopted AI coding tools as if they were solving a known constraint, when in fact they were solving the part of the problem that was not the constraint. The tools are genuinely useful; the expected delivery improvements have not materialized because the constraint was somewhere else the entire time.
The teams that have seen real throughput gains from AI tools tend to be the ones that had already fixed their pipelines. They had short review cycles, high deployment frequency, reliable CI, and a culture of small changesets. On that foundation, AI assistance compounds meaningfully because implementation speed was, in fact, the binding constraint for them.
For teams that have not done that work, the correct sequence is to find and fix the actual constraint first. That means instrumenting where PRs wait, where deployments fail, where incidents drag on, and where requirements arrive too vague to act on. Then, once the pipeline moves, add the tool that helps fill it faster.
Goldratt’s observation was that managers tend to optimize what they can measure and control rather than what actually constrains the system. Code generation is measurable, controllable, and now dramatically improvable with AI. The review queue, the deployment pipeline, and the requirements process are harder to instrument and harder to change. That is exactly why they stay broken while the upstream keeps getting faster.