AI: The Illusion of Productivity - The bottleneck problem

In the previous article of this series, AI: The Illusion of Productivity, we explored the coordination overhead problem: once several AI agents run in parallel, the job stops being about writing software and becomes about managing it, arbitrating between agents that can't converge and deciding, round after round, which output to trust. This time, we turn to the assumption sitting underneath all three of the problems described so far: that coding speed was worth optimising in the first place. In most organisations, it never was.

***

The speed of writing code is rarely what's actually standing between an organisation and shipping good software. Far more often, the real constraint sits upstream: knowing what to build, for whom, why, with what tradeoffs, and how it's genuinely supposed to work. Just as often, it’s having an architecture solid enough that the answers to those questions can actually be implemented cleanly. Those are product and engineering-judgement problems that no amount of typing speed can solve. Pointing AI at coding speed (a step that, in most teams, was never the bottleneck) doesn't speed the system up. It produces more output against specifications that were never properly interrogated, on top of architectures that were never properly stress-tested, and it creates a convincing sensation of progress while the actual constraint sits untouched, harder to see than before.

This argument leans directly on Eliyahu Goldratt's Theory of Constraints, laid out in his 1984 business novel The Goal. The core claim: a system's throughput is set by its single most constrained step. Improving any other step doesn't raise throughput:  it just builds inventory in front of the real bottleneck. The formulation widely attributed to Goldratt sharply puts it as: "An hour saved at the non-bottleneck is a mirage."

I'd extend that slightly: optimising a non-bottleneck doesn't just fail to speed the system up, it can actively make things worse. By generating more output against an unclear specification and an under-designed architecture, AI-accelerated coding manufactures the sensation of progress while the real constraint sits untouched. Time, attention, and budget flow toward the step that's visibly busy, and away from the ones that actually needed it.

In software specifically, I think this shows up in two places more than any other. One is product clarity: what are we actually building, for whom, and why. No amount of coding speed answers those questions, and they get harder to keep asking once code is already flowing, because a fast-moving pipeline creates its own pressure to keep committing to the plan rather than stopping to check whether it's still the right one. The other is architecture, asking whether the system is designed well enough, with clear enough boundaries and honest enough tradeoffs, that new code can be added to it without the whole thing becoming harder to reason about with every commit. Neither of these gets easier when AI writes the code faster. If anything, both get harder, because the volume of decisions embedded in that code (decisions about structure, about scope, about what a feature is actually supposed to do) increases at the same rate the code does, without a matching increase in the thinking that should have preceded each one.

I don't think this is a purely theoretical worry, either. Between 2025 and 2026, something close to a live experiment played out at economic scale. While anecdotal, it's a relevant one: unlike a survey response, a company reversing a layoff is a decision made with real money on the line. Staffing firm Robert Half found that roughly three in ten U.S. hiring managers (estimates range 29–32% across survey waves) who'd cut a role primarily because of AI had already rehired for the same or a similar position, and Forrester Research found 55% of employers now regret their AI-driven cuts.

Two named cases make the mechanism concrete. Ford hired, promoted, or rehired 350 experienced engineers over roughly three years, after AI-based quality-control systems and 900 AI-powered inspection cameras failed to catch defects that veteran engineers could see immediately. In June 2026, Ford topped the JD Power Initial Quality Study for the first time in sixteen years, and its CEO credited the returning engineers with hundreds of millions of dollars in warranty and recall savings. The expertise that actually protected product quality turned out to be the real constraint all along, while design speed was simply irrelevant to it.

IBM's AskHR assistant automates 94% of routine HR queries competently. The remaining 6%  (cases needing ethical judgement) still need a person. IBM's response was to triple entry-level hiring instead of continuing to patch the AI, explicitly to protect the pipeline that produces the judgement AI can't replicate.

Both cases share the same shape, and it's the shape I'd want an engineering team to sit with: the AI in question produced plenty of output. What it lacked was judgement about what that output should be and why, exactly the layer this piece has been arguing is the actual bottleneck across most software work, HR queries and quality inspection alike. Of course not every AI-attributed layoff in this period was a genuine capability failure; some were ordinary cost-cutting using AI as a convenient story. But the point still holds:it just means the gap between the AI narrative and the delivered reality was wide enough to absorb both kinds of case.

The thing is AI clearly has value in software development, but the point is narrower: the productivity gains AI can genuinely deliver are currently being aimed at a part of the system that was rarely the thing limiting output in the first place, while the two things that actually were limiting it, understanding the problem and designing well for it, get no faster, and if anything get more neglected, because a coding layer that now moves quickly enough creates its own illusion that the hard part is already handled. 

None of the four problems above are really separate. They lock together into two feedback loops, one running at the level of the individual developer and one running at the level of the organisation, and each one quietly reinforces the other.

At the individual level: a shallow prompt (in the first article of this series) produces an output that gets reviewed in a degraded, fragmented state (as covered in the second article). The degraded review misses things. What it misses surfaces downstream as bugs, rework, incidents. The rework adds to the cognitive load that made the prompt shallow in the first place. The loop closes on itself,  and running several agents at once (the subject of the third article) accelerates every stage of it simultaneously.

At the organisational level, AI-accelerated coding against an unclear specification produces more unvalidated output. More unvalidated output means more rework and more product pivots. Rework and pivots create pressure to move even faster. Moving faster means reaching for AI more. Reaching for AI more leaves less room,  cognitively, and on the calendar,  for the upstream thinking (requirements clarity, product validation, honest architectural tradeoffs) that would have prevented the rework to begin with.

The METR perception inversion sits at the exact point where these two loops meet, and I think that's why it's the right anchor for the whole piece. The feeling of productivity survives at both levels for the same reason: output keeps visibly appearing, at the individual level and in the organisational pipeline both. The loops keep everyone busy. Busy looks like productive. And the debt at both levels accumulates quietly, invisibly, right up until it becomes a delivery failure, a quality incident, or  (as an entire wave of hiring reversals now shows)  a product built on a premise that turned out not to hold.

There's no tidy list of fixes coming. I don't think this problem gets solved by a better prompting technique, a smarter agent orchestration pattern, or a new productivity dashboard. Those are all real and useful things, in their place. None of them touch what I actually think is going on.

At the individual level, AI rewards clarity of thought before the prompt and depth of attention during review,  both of which require treating focus as a genuinely finite resource. The current default way of working with these tools (more agents running, faster iteration, higher visible output) optimises for exactly the pressures that erode both.

At the interactional level, the chat model these tools are built around is designed for continuous iteration, not the sustained depth that hard technical problems actually need. The flow state experienced developers have spent years building is the precondition for being able to tell whether what the AI produced is any good, which is exactly why it can't be suspended for the duration of an AI session.

At the organisational level, AI rewards teams that have already done the hard work of resolving their own upstream clarity,  because it amplifies whatever you feed into it. For teams that haven't done that work, it amplifies the noise instead, fills the pipeline with the wrong things faster, and makes the real constraint even harder to find.

Which brings me to the only question I think is actually worth asking before pointing AI at any part of a workflow, and it isn't "can we go faster here?", it's Goldratt's question, restated for this moment: "is this the constraint?" For most teams, in most contexts I've seen, the honest answer is no.

Whether the industry is capable of asking that question honestly (while the tools are this compelling, the benchmarks this visible, and the competitive pressure this intense) I genuinely don't know. I don't think anyone does yet. I'm not going to pretend otherwise by ending on a tidy resolution.

The question is left standing. I think it's supposed to be.

***

This is the fourth and final article in the AI: The Illusion of Productivity series. Across the four problems it examined (attention quality, flow state, coordination overhead, and the bottleneck itself), the same pattern kept resurfacing: AI amplifies whatever thinking already went into a task, and covers for none of the thinking that didn't. The hard part remains knowing what to build and building it on an architecture solid enough to hold the answer.

Missed the earlier articles in this series? You can catch up here:

• The Attention Quality Problem - first article

• The Flow State Problem - second article

• The Coordination Overhead Problem - third article

***

We wrote this article with the support of AI. If you’re interested in how we use these tools as part of our writing process, you can read more here.

***

References 

• Eliyahu M. Goldratt, The Goal: A Process of Ongoing Improvement (North River Press, 1984) - book; the widely-attributed formulation cited in this piece could not be traced to a specific page/edition, see Part IV's editorial notes in the companion outline

• CNBC, Employers who laid off workers citing AI are already starting to regret it (July 2026)

• Forbes, Ford Hiring 350 Engineers After AI Failed Shows Human Value In AI Era (June 2026)

• Axios, IBM plans to triple entry-level hiring this year because of AI (February 2026)