Three weeks into a client’s AI rollout, we were watching the numbers move. The developers had the tools, the harness, and enough practice for it to show: code was arriving noticeably faster.

But the product was not speeding up with it. Delivery improved — some — but nowhere near as far as the code had.

The flow measurements we had put in on day one showed the details, weeks before it would have surfaced as a missed date. No incident, nobody escalating; the queue had simply relocated to testing.

This Has a Name

Dr. Eliyahu Goldratt worked this out forty years ago and named it the Theory of Constraints: a system has one binding limit at a time, and improving anything else changes nothing. There is a part of the theory the one software development sometimes skips — once something else has become the limit, go back to the beginning. Organisations can spend years working hard on problems that are no longer where the problem is.

The Obvious Fix

The obvious move is the one that surfaces in every organisation under pressure: add people where it is going badly. Put another tester on it.

But hiring is not a purchase, it is a subscription. You are not paying once to clear a queue that is long this month; you are committing to pay every month afterwards, against capacity you hope you will keep needing. In a company of fifteen or twenty people, a single hire also visibly changes the shape of the team. Sometimes it is exactly the right call, but it is also the longest commitment of any option on the table — a good reason to exhaust the faster, cheaper and more reversible ones first.

The Proper Fix

We didn’t add testers. The queue was not a capacity problem — the work arriving had changed shape, and started to comes in larger batches than the old arrangement was built for. So we reorganised: automated part of the checking, and moved a share of the testing back into development, where the context already sat. That move was cheap precisely because the developers were already working through the harness, so writing those tests cost them a fraction of what it would have cost a year earlier.

That worked. Within weeks the queue reappeared one step upstream, at requirements. Development and testing were now consuming work faster than anyone was deciding what the work should be: items were reaching the team not yet defined and commonly understood well enough to start.

The Same Move, One Level Up

So we made the same move again — not the same fix, but the same aim: at the step where the queue now sat. We put an AI agent into the requirements conversations themselves. What it changed matters more than what we built (how it works is a different article):

  • The cognitive load in the room dropped. Attention went to what the client needed, not to who was writing it down and whether they had caught it.
  • The meetings got shorter, because servicing the meeting stopped being part of the meeting.
  • People came out of them more satisfied — every sentence now served a real problem rather than the record.
  • The time that used to go into formulating requirements went into weighing two or three ways to get there.

Point that same agent at the developers instead and almost nothing would have happened, because nobody was queuing in front of them. Speeding up a step that is already keeping up does not raise throughput anywhere. It can lower it, by pushing more work into the queue that is actually the limit.

That is the part that does not transfer between companies. Neither fix was the clever bit. The diagnosis was — working out which stage was asking for help, and only then choosing what to put there.

The Constraint Does Not Stop Moving

Each time we removed a limit, the system did not become limitless. It handed the limit to whatever was next in line — and each time, the next place was somewhere nobody had been looking, because everybody had been looking at the last one.

A system will always have a binding constraint somewhere, and that is not a failure state — slack everywhere else is what protects the constraint from starving. The costly idleness is at the constraint, where an hour lost is an hour the whole system never gets back.

So the skill is not eliminating constraints; it is knowing which one is currently yours — and in an AI rollout, that ability matters more than the tools being rolled out. The work is putting a good tool at the one place in the process that is actually asking for it, and where the queue currently sits is what tells you which place that is.

It Was Supposed to Be Five Times Faster

If you have run a rollout of your own, the shape may be familiar. The first weeks were dramatic. Then the curve flattened. You were expecting something like five times and you are looking at one and a half, and the obvious conclusion is that the tooling was oversold.

The sloppy version of that conclusion says you sped up the part that was never the problem. Nothing in the sequence above was a mistake. Code production was the problem — for thirty years the longest step, the one that consumed the budget and shaped every methodology. Making it fast was right. So was moving the testing, and so was putting an agent where the requirements were being decided. Each removed a real limit and each one paid.

Your rollout did not underdeliver; it delivered its whole increment, and then the limit moved while you were still measuring the old one. Money going into a step that is now keeping up buys nothing at all — while the real limit sits one move away, unmeasured and untouched. The team works hard, the numbers do not shift, and nobody can say why.

What nobody mentions is how much is left standing. An organisation that does the first step and stops there — buys the tools, speeds up development, calls it done — collects a fraction of what was available. Not nothing. A fraction. The rest was never inside development at all. It is in how requirements arrive, how decisions get made, how work moves between the people doing it. That is what those meetings were: the same class of tool, aimed one step up, made nobody type faster — it changed what the room spent its attention on. And none of it is visible from inside a codebase.

The next improvement is also cheap by comparison. Ours took a reorganisation, then an afternoon’s decision.

Buying your team an AI subscription buys a small improvement. What you are actually buying is the entry point to a much larger one.

What This Asks of You

Not a tool. Not a hire. Not a framework with a capital letter.

Using AI well opens a path through your organisation that was not there before, and the path is where the return is. But look at what the steps along it are actually made of. The first one was an investment — licences, training, streamlining and measuring your development process. The ones after it usually are not. They are changes to how work moves: some testing shifted to where the context already sits, a meeting run differently, responsibility routed to someone closer to the problem.

Those are cheap. Most of them need a decision rather than a budget.

Which is also what makes them hard. When we moved part of the testing into development, nobody’s budget changed — but somebody’s remit did. Every change of that kind redraws a line that was drawn for a reason that sounded good at the time, and the person holding the line pays for the redrawing. That is the real price of the second improvement, and it is not payable in money.

So if you have been waiting to start, the first step is smaller than it looks. And if you have already started — if the team is faster and the delivery is not — you are standing at the point where stopping is the expensive choice.

Which change in your organisation is waiting on a decision rather than a budget?