Two reactions to AI coding tools have become common enough to be a genre.
The first: lay off engineers, because the code writes itself now.
The second, slightly more sophisticated: keep the engineers, but announce that the bottleneck has moved — it's the product people now, the ones who decide what to build, who can't keep up with how fast software gets made.
Both are presented as insights. Hard-won, a little rueful, the wisdom of an industry adjusting to a new reality.
Neither is an insight. Both are confessions.
The Thing You Were Already Told
The claim buried inside "the bottleneck is product now" is that, until recently, the bottleneck was code — the typing, the implementation, the engineering labour of turning a decision into a running system. Remove that cost and you find the real constraint underneath: deciding what's worth building in the first place.
I've made the forward-looking version of this argument already — that AI didn't make engineers faster at the thing people imagine, it moved the binding constraint upstream where it always belonged. I won't re-argue it. I want to make the uncomfortable version instead.
The constraint didn't move. It was always there, and the industry has known it was there for at least twenty years — because it built entire methodologies around it and then printed them on every careers page.
Extreme Programming, late 1990s. Agile, 2001. DevOps, late 2000s. Three movements, endlessly cited, certified, consulted upon. Ask most teams what they have in common and you'll hear about standups, sprints, retrospectives, pipelines, two-week cycles. Ceremonies and tooling.
That is not what they had in common. At the core, all three were answers to a single question: how do we find out what's worth building before we waste everything building the wrong thing?
XP's short cycles, its on-site customer, its test-first discipline — all of it existed to shorten the distance between an idea and real feedback on that idea. The Agile manifesto valued working software and responding to change over plans and documentation because its authors had watched enough projects spend a year building exactly the wrong thing, precisely to specification. DevOps tightened the loop between writing code and watching it run in production because the lag between those two moments was where learning went to die.
None of it was about typing faster. Every one of those methods was a machine for making it cheap to be wrong — for learning what to build by building a little, watching, and correcting, instead of guessing big and finding out late.
The learning rate was always the point. The code was never the bottleneck. They told you. Out loud. In books you can still buy.
Why It Got Missed
So why does the industry get to act surprised?
Because the parts of those methods that were easy to adopt were the parts that didn't matter, and the part that mattered was the part nobody wanted to do.
Standups are legible. You can hold one tomorrow. Sprints fit a calendar. Pipelines can be bought. There are certifications, frameworks, consultants — an entire economy built on the teachable surface of these ideas. A company can adopt every visible artifact of Agile in a single quarter and put it in the recruiting deck by Friday.
The actual principle — make being wrong cheap, run a tight loop, let real feedback decide what gets built next — is none of those things. It is cultural. It threatens the people whose authority comes from deciding what to build in a room with no users in it. It requires saying "we don't know yet," which is expensive for anyone whose job is to look certain. So it got dropped, quietly, while the ceremonies stayed.
The result is an industry that ran "Agile" for two decades as a project-management technique for shipping more features faster — roughly the opposite of the intent — and is now genuinely startled to discover that deciding what to build is hard and important. It was always hard and important. You renamed the loop a velocity chart and stopped running it.
Speed Is Not Precipitation
Here is where the new tools come in, and where it gets sharp.
There is a difference between speed and precipitation, and most of the industry has spent twenty years confusing the two.
Speed is a tight feedback loop. You move fast because you've made it cheap to be wrong — you ship something small, you watch what happens, you correct. The fastness is real and it compounds, because every cycle teaches you something that aims the next one better.
Precipitation is motion without the loop. It's doing whatever brings dollars in this quarter, as fast as possible, without ever checking whether it was the right thing — and calling the resulting blur "speed." It feels identical from the inside. It produces a great deal of shipped software and very little learning.
AI coding tools do not fix this. They cannot. A tool that removes the cost of writing code amplifies whatever discipline you already had. If you ran a real loop, you now run it faster and the compounding accelerates. If you were precipitating — building quickly without knowing what was worth building — you now build the wrong thing faster and cheaper than ever, and you accumulate more of it before anyone notices.
The tool is a multiplier. It multiplies a discipline you have, or it multiplies its absence.
The Panic Tell
This is why the two reactions I opened with are tells.
Firing your engineers the moment code gets cheaper, or announcing that the bottleneck has freshly relocated to your product team — these are not the moves of an organisation that understood what it was doing. They are panic moves. Reactions to the feeling of being suddenly behind, made fast, to look decisive.
I've written that calm under pressure is not a temperament but a practice — the residue of having drilled the fundamentals until they no longer need your attention. The fundamental here, the one the methods were always teaching, is the loop: knowing what's worth building, and finding out cheaply when you're wrong. A team that internalised that loop does not panic when the cost of code drops. It runs the loop faster and pulls ahead.
The teams reorganising in alarm are the ones that never had the loop. The tool didn't create their problem. It exposed it.
What It Cost
The bill for this is not hypothetical, and it did not start arriving with AI.
For twenty years, companies that mistook precipitation for speed were already paying — in software built to specifications nobody validated, in features shipped that no one used, in the slow erosion of teams asked to move fast in no particular direction. They were too busy chasing whatever brought dollars in to run the loop that would have told them which dollars were worth chasing. So they wasted both, at scale: the money, and the engineers' finite willingness to build things that don't matter.
AI didn't change that arithmetic. It turned up the volume on it. The cheap code makes the loop-runners faster and the precipitators more wasteful at the same time — which is why the gap between the two kinds of company is about to become very hard to hide.
The bottleneck was never the code. It was the willingness to find out what's worth building before building it. That was the whole point, the first time someone said it.
Twenty years ago. In a book you can still buy.
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.