The Speed Trap

“The machine made writing code almost free, and in doing so it made everything that is not writing code the entire job.”

The Afternoon That Was Never Free

When generative coding assistants arrived in strength, the pitch was that they would absorb the drudgery, the boilerplate, the forgettable connective tissue of software, and hand the human engineer back the scarce and satisfying part: the thinking. Compress a week of implementation into an afternoon, the reasoning went, and the afternoons would start to pile up. Developers would design more, worry less, and go home earlier.

The speed trap is the condition in which the part of the work that got faster is the part you can see and feel, and the part that got slower is the part you cannot. Typing accelerated. Understanding did not. Because understanding is silent, the acceleration is the only thing that registers, and so the industry has spent three years optimising for a number that measures the wrong half of the job.

“Efficiency does not shrink the work. It lowers the price of the work, and a lower price summons more of it.”

Rebuilding it was not a matter of adding features. Authentication, shared persistence, concurrent editing, and an audit trail are not modules you attach to a finished application. They are decisions that shape the architecture from the first commit, and every one of them had already been decided, silently, by the choice of a desktop framework and a local file. The atomic business logic survived the rewrite. Almost nothing else did.

This is the failure mode of the new era in miniature, and it is not a story about a weak model. It is a story about what happens when generation becomes so cheap that the only remaining constraint is the quality of the intent behind it, and the intent is written by someone who has never had to make the implicit explicit.

This is not a failure of management discipline, though discipline would help. It is the structural gravity of the situation, and it means the human engineer remains the binding constraint no matter how fast generation becomes. The tools designed to relieve the pressure are precisely what raises it, because they enlarge the estate that a fixed number of humans must comprehend, secure, and maintain. The volume of code an organisation owns is now growing faster than its capacity to understand what it owns.

Reading Is Harder Than Writing

The deepest structural change is not that we write more code. It is that the human role has quietly migrated from producing code to adjudicating it, and adjudication is the more expensive act.

Any working programmer knows this in their body even if they have never said it aloud. Writing code externalises a mental model you already hold. Reading code requires you to reconstruct a mental model you do not, reverse-engineering the intent of the author from the artefact alone. When the author is a language model reaching for unfamiliar abstractions, inventing a plausible-looking variable, or placing correct logic in the wrong architectural layer, the reconstruction gets harder still, because the usual cues of human intent are absent. The work has shifted from composition to comprehension, and comprehension does not parallelise, does not autocomplete, and does not get cheaper when the model improves.

The consequences show up wherever code changes are measured. LinearB’s 2026 analysis of roughly 8.1 million pull requests across some 4,800 teams found that AI is reshaping the review stage, not just the writing stage. Pull requests produced with heavy AI assistance are markedly larger than human-authored ones and contain almost no refactoring, meaning they add rather than integrate. They also wait far longer to be picked up for review, and pull requests from autonomous agents wait longer still. The generation is instantaneous; the queue it creates is not.

 

The Apprenticeship We Are Automating Away

The costs described so far fall on people already in the profession. The most serious cost falls on people trying to enter it, and it is measurable now.

The industry has always run on an apprenticeship. Junior developers learned the craft by doing the unglamorous work, the boilerplate, the simple bugs, the tests, the small refactors, and through that mundane repetition they built the mental models that eventually made them senior. AI is extraordinarily good at precisely this entry-level work, and so the bottom rung of the ladder is the first thing organisations have automated. The result is not a hypothetical. Stanford’s Digital Economy Lab, tracking millions of workers, found that employment among software developers aged twenty-two to twenty-five fell by around twenty per cent from its late-2022 peak, even as employment for older developers held or grew. A Harvard study of some 62 million workers across roughly 285,000 firms found that junior employment at firms adopting generative AI declined by around eight per cent relative to non-adopters within six quarters, and characterised the shift bluntly as seniority-biased technological change. The effect came from reduced hiring rather than layoffs, which makes it quieter and no less consequential.

The second-order effect is worse than the first. By closing the entry route, the industry is declining to manufacture the senior engineers it will need in a decade, and it is simultaneously producing a cohort of nominal seniors whose formative struggle was outsourced to a model. Call this the hollow senior: an engineer with the title and the salary but without the hard-won intuition to trace a subtle memory leak, untangle a monolith under a production outage, or sense that a specification is silently wrong. Those are exactly the judgements that AI does not supply and that only accumulated experience does, and they are the judgements a review-heavy, comprehension-bound future depends on most.

Inter-Developer Competition and the Weaponization of Velocity

The Jevons Paradox does not merely alter the volume of work; it fundamentally mutates the social dynamics and competitive landscape within engineering teams. As AI tools drive the ceiling of individual output upward, they create a sharp divide between developers who seamlessly integrate these tools and those who rely on traditional, manual coding practices. The resulting environment is characterized by intense peer competition, stack-ranking by output volume, and pervasive anxiety regarding professional irrelevance.

Because the efficiency of AI tools multiplies individual output by up to 55%, developers face intense pressure to adopt them simply to maintain parity with their peers. This competition manifests vividly in the daily workflow. A specific archetype has emerged in modern development teams, often referred to as the “Builder,” who leverages AI to generate massive volumes of code and open multiple pull requests per day. While this individual is often celebrated by management for their high velocity, they externalize the cost of their speed onto their colleagues, who must review their voluminous output. Some teams are seeing up to 30 pull requests per day directed at only six available reviewers, creating an unsustainable ratio that breeds resentment. The manual reviewer becomes the organizational bottleneck, penalized for their slowness, while the AI-augmented generator is rewarded for their speed.

 

The Shift from Creation to Verification: The Review Bottleneck

The most profound structural disruption caused by AI coding assistants is the reallocation of human effort from code creation to code verification. Traditional software engineering was fundamentally constrained by the speed at which a human could type, think through logic, and synthesize syntax. Under that paradigm, code review, while important, was a proportional fraction of the development lifecycle. The advent of AI has inverted this ratio entirely. Machine-speed generation has collided violently with human-speed verification, creating a massive bottleneck in the pull request and code review phases of software delivery.

While developers using AI complete tasks faster and merge up to 98% more pull requests, the actual time spent reviewing these pull requests has increased by 91%. A comprehensive 2026 analysis by LinearB, evaluating 8.1 million pull requests across 4,800 organizations, reveals a dangerous illusion of speed: while developers feel they are operating 20% faster, the end-to-end delivery cycle is actually 19% slower, highlighting a massive 39-point gap between perceived productivity and actual systemic throughput.

This discrepancy is driven by the sheer size and complexity of AI-generated pull requests. AI tools can instantly generate hundreds of lines of code, resulting in massive diffs that intimidate human reviewers. Furthermore, AI-generated code is demonstrably more defect-prone. Data from 2026 shows that AI-coauthored pull requests contain an average of 10.83 issues each, compared to 6.45 issues in human-only pull requests, representing a roughly 1.7-fold increase in the defect density that reviewers must identify and catch.

The burden of reviewing this code is not distributed equally. In many organizations, a small cadre of senior engineers bears the brunt of the review load, leading to severe localized bottlenecks. The backlog is particularly severe for pull requests authored by autonomous AI agents, which experience extreme reviewer abandonment. Analysis of agent-authored PRs across major open-source and enterprise repositories demonstrates that AI-only pull requests achieve a mere 45.2% merge rate, compared to a 68.37% merge rate for human-only pull requests. Over 60% of closed AI-agent pull requests are abandoned entirely due to low signal-to-noise ratios in the code or unhelpful, noisy automated review comments. Agents frequently generate correct logic but place it in the wrong architectural layer, or they fail to account for the broader repository context, triggering continuous integration failures and requiring extensive human intervention to salvage the submission.

Structural Decay: Code Churn, Duplication, and Technical Debt

The friction generated by the review bottleneck and cognitive fatigue is compounded by a verifiable decline in the structural integrity of the codebases being produced. As developers face unrelenting pressure to maintain high output velocity, they increasingly rely on AI to generate complex logic. Because AI models operate as sophisticated pattern-matching engines rather than reasoning entities, they optimize for local correctness at the expense of global architectural health.

The most concerning metric is the exponential rise in code duplication. AI-assisted coding is linked to a four-fold increase in code cloning. For the first time in measured software history, the volume of copy-pasted code, which rose from 8.3% to 12.3% of all changed lines has exceeded the volume of moved or refactored code, which plummeted from a historical average of 25% down to below 10%. AI tools, lacking holistic codebase awareness, frequently solve localized problems by hallucinating new implementations of functions that already exist elsewhere in the repository. Developers, overwhelmed by notification creep and velocity pressure, often accept these duplicated blocks rather than taking the necessary time to abstract and refactor the code into reusable, modular components.

The long-term consequence of this structural degradation is severe. Code duplication linearly multiplies the maintenance burden; a bug present in a duplicated block must now be tracked down, verified, and patched in multiple disparate locations. Over time, this inflates the codebase, making navigation exponentially more difficult and slowing future development to a crawl. The pursuit of short-term velocity through AI has thus initiated a compounding cycle of long-term technical debt, guaranteeing that future developers will spend the majority of their time untangling the bloated legacy systems currently being generated.

 

Share This Post

MORE TO EXPLORE