There’s a version of software development that looks like this: a developer needs a feature, opens their AI-assisted editor, and generates the first draft in minutes instead of hours. The PR then sits in review for three days. The deployment pipeline runs for forty minutes. The feature requirement was vague, and the implementation needs to change anyway after the first user test. None of the delay moved faster.
Andrew Murphy’s piece resonated with 300+ points on Hacker News partly because it names something practitioners already feel: code writing was rarely where development got stuck, and tools optimizing for it are solving a visible problem rather than the actual one. The premise holds, but tracing exactly why it holds leads somewhere more concrete than a general observation about software complexity.
Where Developer Time Goes
The intuition that coding is the bottleneck doesn’t match how developer time distributes across a workday. GitLab’s annual DevSecOps survey and the Stack Overflow Developer Survey consistently find that code writing accounts for roughly a quarter to a third of developer time. The rest goes to code review, meetings, reading and understanding existing code, waiting on CI pipelines, debugging, and managing deployments.
The SPACE framework, published by Nicole Forsgren and colleagues at GitHub and Microsoft in 2021, was explicitly designed to push back against reducing developer productivity to lines written or features shipped. The framework treats Satisfaction, Performance, Activity, Communication, and Efficiency as distinct dimensions precisely because the coordination and communication work that fills most of a developer’s week doesn’t produce code, yet often determines whether code gets shipped at all.
McKinsey’s 2023 research on developer productivity documented what most senior engineers recognize from experience: the biggest reported blockers are unclear requirements, technical debt, slow review cycles, and context switching. Typing speed doesn’t appear on that list.
Goldratt’s Constraint Applied to Software Pipelines
Eliyahu Goldratt’s Theory of Constraints, developed in “The Goal” (1984), makes a claim that seems obvious after you hear it but has counterintuitive consequences: in any system optimizing for throughput, there is exactly one constraint, and improving anything that isn’t that constraint doesn’t improve system throughput. It only builds queue.
Software development is a pipeline. Code gets written, reviewed, tested automatically and sometimes manually, merged, deployed, and then interacts with users. If the constraint is at review, writing code faster doesn’t ship features faster; it means more code waits in the review queue. The queue grows, review quality degrades under overload, and context-switching costs increase for reviewers cycling through more outstanding PRs.
Gene Kim, Jez Humble, and Nicole Forsgren documented this dynamic in Accelerate (2018). Their research into high-performing software teams found that the distinguishing factor wasn’t raw development velocity in isolation; it was cycle time from commit to production. High performers have short cycle times because they manage the whole pipeline, not just the code-writing portion.
The 2024 State of DevOps Report continues to show this pattern. Elite performers deploy multiple times per day with change failure rates below 5% and lead times from commit to production under an hour. Those numbers aren’t achievable by writing code faster; they require a fundamentally different relationship with review, testing infrastructure, and deployment processes.
The Ironic Effect of Optimizing the Wrong Step
There’s a dynamic where AI coding tools, deployed without awareness of where the constraint is, can worsen delivery times rather than improve them.
Consider a team where review is the bottleneck: reviewers are already stretched, PR queues regularly back up, and review latency is measured in days. An AI tool that helps developers write code twice as fast in this environment doubles the review backlog. Reviewers now face more code in the same time window, which increases cognitive load, reduces review quality, and makes it harder to give useful feedback. More code waits longer, and lead time from idea to production increases even as individual developers feel more productive.
This is the natural consequence of improving a non-constraint. For most software teams, the constraints cluster in a few familiar places.
Requirements ambiguity. Unclear or shifting specs cause rework. Code written faster against a vague spec gets caught in review, or makes it to production and surfaces as a bug. The specification problem doesn’t shrink because AI generated the implementation; in some cases it gets worse, because generated code looks plausible enough that ambiguities get less scrutiny.
Review bottlenecks. At many organizations, PR review time is measured in hours to days. Producing review queue faster doesn’t fix this, and the volume pressure tends to produce shallower reviews.
Slow CI pipelines. Test suites that run for 20 to 40 minutes create structured idle time. Developers context-switch away to other work, which increases the cost of returning to the original task when the pipeline finishes. Code generation speed has no bearing on this.
Deployment friction. Teams that release infrequently do so because their deployment process carries risk or requires manual steps. This is a process and automation problem, not a code-writing problem.
Debugging and incident response. Time investigating production issues often exceeds time writing the features that caused them. Better observability, structured logging, and fast rollback capabilities matter here, and none of those come from faster generation.
Where AI Tooling Can Move the Needle
This is not a case against AI coding tools. The question is whether they’re applied where the constraint is.
Code generation provides real value for work that is boilerplate-heavy, well-specified, and straightforward to review: test scaffolding, integration glue code, documentation, configuration generation. These tasks consume developer time without providing much intellectual leverage, and automating them frees attention for harder problems. From my own experience building Discord bots, the slash command scaffolding, the message formatting utilities, and the boilerplate for new event handlers are exactly where AI-generated first drafts pay off. The reconnection logic and rate limit backpressure code, where getting it wrong has real consequences, require more careful attention.
More interesting is whether AI tooling can address the constraints that matter. AI-assisted code review that flags inconsistencies with existing patterns, common failure modes, or potential security issues could address the review bottleneck more directly than any typing improvement. Tools that help clarify requirements by surfacing ambiguities and generating concrete test cases as a form of specification could reduce rework earlier in the pipeline. AI-assisted debugging and log analysis could reduce incident response time.
Some of this is emerging. GitHub Copilot’s PR description and review summary features are steps in this direction. Repository-aware context in tools like Cursor attempts to help with understanding unfamiliar codebases, which is a genuine time sink distinct from writing new code. The more interesting competition in AI developer tooling is moving up the stack from code generation toward the harder parts of the pipeline, and the tools that make progress there will likely deliver more measurable impact at the team level.
What This Means for Engineering Organizations
Organizations evaluating AI coding tools primarily on raw code generation metrics are measuring the wrong output. The question isn’t how much code gets produced; it’s how quickly working software reaches users, and at what defect rate.
Teams that will extract the most value from these tools are those that have the rest of their pipeline functioning reasonably well: fast review cycles, automated testing they trust, low-friction deployments, and clear enough requirements that generated code doesn’t require constant rework. For these teams, AI tooling helps at the margins and the gains are real.
For teams where those fundamentals aren’t in place, AI coding tools land in an environment that can’t process what they produce. The queue builds somewhere, usually in review or in production defects, and system-level productivity doesn’t improve even as individual developers feel faster.
The uncomfortable implication of Murphy’s piece is that many organizations excited about AI productivity tools would benefit more from fixing their review processes, deployment pipelines, or requirements practices first. Those are harder and less visible improvements than adopting new tooling. Constraints don’t move by improving non-constraints, and the tooling that makes code faster to write doesn’t automatically make software faster to ship.