Recently I ran a session at Okanagan Agile, our local agile meetup, on what happens to a development team when AI makes coding dramatically faster. Before we got into the theory, I wrote each step of a typical delivery workflow on paper cards and laid them end to end on the table. It sounds simple, and it is. But being able to point at a card and say “this is where things are piling up” changes the conversation from abstract to concrete in a way that a slide never does.
Someone asked the question that almost always comes up: was development (coding, thinking, verifying your own work) ever really the bottleneck?
My answer is yes, and the evidence is the fact that we’ve been staffing up on developers for decades to address the bottleneck. Why else would we have seven developers in a team of ten people, if that piece wasn’t slow?
AI tools have made developers much faster at writing code and moderately faster at the rest, and yet on many teams, value isn’t reaching customers any faster. On some, it’s gotten objectively worse.
Eliyahu Goldratt, in his 1984 book The Goal, introduced the Theory of Constraints. Every system has a single active constraint — the bottleneck that limits overall throughput. Speeding up any other part of the system doesn’t improve output; it just builds up inventory in front of the constraint. And when you do speed up the bottleneck, the constraint moves somewhere else.
Most development teams have more developers than testers, and more testers than product people. That staffing shape has traditionally been because of where the bottleneck was, and now AI has shifted it to where the team is thin.
Some teams had already built amazing quality into their products, and had automated away most of the need for manual testing, but for those who hadn’t, testing has now become a significant bottleneck. We’re flying through the coding stage and are piling up in testing. This is the bottleneck shifting right, or closer to completion.
Many teams are letting the AI write all the code and are still doing fully manual PR review, which causes another significant bottleneck. Nobody can meaningfully review hundreds of changed files under time pressure.
The bottleneck also shifts left, back towards product decisions. Most teams have always had a significant number of items in their backlog, from which we pulled a little at a time. Since it took so long for the actual development, we were forced to prioritize which of those items from the backlog would get worked on. What’s happening now? Since we’ve sped things up so much, many teams are pulling things from the backlog that never should have been implemented. Things that had been accumulating but that never would have been built in the old days. Now we have the capacity to do them all, and aren’t stopping to think if we should.
Building the wrong thing fast doesn’t help anyone.
The answer isn’t to thin the developer ranks; it’s to grow the capacity everywhere else. We should be doing more with the same people, not the same with fewer. The goal is a team where the bottleneck keeps moving because we’re growing capacity across the whole team.
If development wasn’t your bottleneck to begin with, then you’ll see different shifts, but the concept is the same. AI doesn’t guarantee that you’ll deliver more value to your customers, faster. It just shifts the bottleneck to where the team is thinner, and now you have a different problem to solve.
Your bottleneck has moved. Do you know where it is now?
See also: