The pitch for AI coding tools is remarkably consistent across every product in the space: you will write code faster. GitHub Copilot’s own research advertises that developers complete tasks 55% faster. Cursor markets itself around uninterrupted flow state. Every new model release leads with coding benchmarks. The implicit assumption threading through all of it is that writing code is the constraint on software delivery, and that reducing it is the lever most worth pulling.
That assumption deserves scrutiny, because the pushback against it keeps surfacing in developer communities with hundreds of upvotes, which usually indicates the argument is identifying something real.
Where Developer Time Actually Goes
Research on how software engineers spend their working hours consistently points away from writing new code as the dominant activity. Studies from Microsoft Research’s software engineering group have found that developers spend significant portions of their week in meetings, reviewing others’ code, reading existing code to understand it, and waiting on build and test infrastructure. A 2018 Stripe report on the developer coefficient estimated that developers spend roughly 42% of their time dealing with technical debt and maintenance rather than new development. Separate productivity surveys cluster around similar findings: reading code, debugging, reviewing, and coordinating with others consume the majority of the working day.
If writing new code occupies a minority of the week, tools that make writing faster produce a proportionally smaller gain on overall output than their framing implies.
Bottlenecks and the Shape of Software Delivery
Eliyahu Goldratt’s Theory of Constraints provides a useful frame here. In any system, throughput is limited by the single most constrained resource. Optimizing a resource that is not the constraint does not improve overall system output; it shifts work faster onto the actual constraint, which can make things worse.
Apply this to software delivery. Suppose a team’s real constraint is that code review takes 48 hours on average. Engineers write a feature, submit it, and wait. If AI tools make the writing phase twice as fast, what changes? Engineers finish their next task and submit it for review before the first review is complete. The queue grows. The constraint gets more pressure, not less. The visible metric, code written per day, improves. The shipping metric, features delivered per sprint, may not move at all.
This is not a hypothetical. Teams that instrument their delivery pipeline with DORA metrics, specifically lead time for changes, deployment frequency, change failure rate, and mean time to restore, often find that changes to individual productivity have little effect on system-level numbers unless the change happens to address the actual constraint.
The Bottlenecks Faster Writing Won’t Touch
Requirements and specification. The hardest part of most software projects is determining what to build with enough precision that implementation can proceed without rework. This is slow, iterative, and depends on human communication. AI tools can accelerate implementation once a clear specification exists; reaching a clear specification is still manual and expensive.
Code review. Review is a cognitive and social process. Reviewers need to understand a change in context, evaluate its approach, catch defects, and give feedback that is useful enough to act on. This does not get faster because the author used AI to write the code. Review bandwidth is roughly proportional to the number of senior engineers willing and available to review, which is a people constraint, not a tooling one. AI-assisted review products are emerging, but the quality ceiling is real and adoption is early.
CI/CD pipeline throughput. On a large codebase, CI pipelines routinely run for 20 to 40 minutes or longer. Each change waits in that queue. Faster code writing accelerates the rate at which work arrives at the queue; it does nothing to the queue itself. Improving CI throughput requires investment in test infrastructure, parallelization, smarter caching, and test suite discipline, all of which are independent of how the code was written.
Deployment and release validation. Shipping to production safely takes calendar time. Canary deployments, feature flags, staged rollouts, monitoring validation, and rollback procedures are all compressible through investment in infrastructure and process, but not by making coding faster.
Organizational coordination. Any engineering team beyond a handful of people spends substantial time in alignment-related work: sprint planning, design reviews, incident retrospectives, cross-team syncs. This overhead does not shrink because individual engineers generate code more quickly.
The Irony of Accelerating a Non-Bottleneck
When you remove a constraint from a system, you do not eliminate the problem. You surface the next constraint. If AI coding tools produce a real, sustained increase in the rate at which engineers generate code, the first visible effect in many organizations will be an accumulation of work downstream: more pull requests queued for review, more work backed up in QA, more tickets waiting on deployment approval.
Teams that see code produced per day increase while features shipped per sprint stays flat are experiencing this effect. The productivity gain is real and local; it is just not propagating through the system because the system’s constraint is elsewhere.
There is a secondary problem worth naming. More code produced faster also means more code to maintain, review, and eventually understand or debug. If the tooling lowers the activation energy for generating code without raising the bar for what gets written, codebases can accumulate complexity faster than the team can absorb it. The maintenance burden that was always the dominant cost of software does not go away; it can grow.
What Would Actually Help
The honest starting point is measurement, because most teams do not know precisely where their constraint is. If lead time for changes, from code complete to production, runs in days or weeks, the constraint is almost certainly review, testing, deployment, or organizational approval, not implementation speed.
If mean time to restore after incidents is high, the constraint is observability, incident response process, and rollback capability, none of which are affected by how quickly code gets written.
If features are frequently reworked because requirements were unclear, specification and communication are the constraint.
The situations where faster code generation genuinely helps are real but narrower than the marketing implies: greenfield work with clear specifications and an unblocked downstream pipeline; individual contributors whose personal bottleneck is genuinely implementation speed; exploratory prototyping where the goal is to build and discard quickly. These situations exist. They are not the majority situation on established teams.
The Framing Problem
The coding tools industry has a strong incentive to frame the problem in terms of the metric it can move. Writing code is measurable, attributable, and immediate. Lead time reduction and organizational throughput improvements are harder to attribute to a single tool purchase. That is a natural commercial distortion, and understanding it helps when evaluating what a tool can actually do for your specific team.
Evaluating AI coding tools on whether they make code faster to write is not the same as evaluating whether they address your team’s actual delivery constraint. For most established teams, those are different questions with different answers. Figuring out which question to ask first is, to put it plainly, the bigger problem.