What AI Does Not Change

A team can generate ten times the code it generated two years ago and still wait three weeks for a test environment. When that happens, the team has gained nothing that a customer can detect. The waiting did not get shorter, the environment did not get faster, and the additional code is inventory sitting in a queue rather than value in production.

This is the article that earns the rest of this domain whatever credibility it has, because the argument made elsewhere here — that the transaction cost of producing a change has genuinely collapsed — is only useful if it comes with a precise account of what it did not touch. A change to one variable in a system of many is not a change to the system. The flow physics in the rest of this library were not written about a particular era of tooling. They are consequences of queueing, of structure and of human communication bandwidth, and none of those three has been revised.

What follows is the list of things that are exactly where they were. I would rather over-argue this than under-argue it, because the failure mode in the market right now is not excessive scepticism. It is organisations that have made one term cheaper, declared victory, and have not looked at the rest of the equation.

Little's Law does not negotiate

Average cycle time equals average work in progress divided by average throughput. It is not a heuristic, a model or a rule of thumb. It is an identity that holds for any stable queueing system regardless of what the work is, who does it or how it was produced.

Read the consequence carefully, because it is the single most important sentence in this domain. If throughput is capped by something downstream of production — review, test, environments, approval — then increasing the rate at which work is created increases work in progress and therefore increases cycle time. Proportionally. Not eventually, not as a risk, as arithmetic.

An organisation that raises production output by a large factor without touching its constraint has not made anything faster. It has made everything slower, because every item in flight is now competing with more items for the same finite verification and release capacity. The individual engineer's experience is of enormous speed — the change is written in an afternoon — and the customer's experience is of a system that has got worse. Both of those are true simultaneously, and reconciling them is most of the management work in this area.

Dependencies between teams are untouched

If your team needs another team to change an API before your work can ship, that dependency exists in the organisation, not in the code. Generating your side faster brings the date forward by exactly the duration of your side's work, which was never the long pole. The other team's backlog, priorities and planning horizon are what determine the date, and no assistant has any purchase on those.

The dependency mathematics of scaling is unchanged in every particular. Cross-team dependencies still create queues with wait times governed by the other team's utilisation. The probability that a multi-team deliverable is late still rises with the number of teams involved, because it completes only when its slowest dependency completes. Coordination still costs more than the work being coordinated, at surprisingly small team counts.

There is a worse version of this that is specific to the current moment. If every team generates more, then every team's backlog of changes requiring another team's involvement also grows. Dependency request volume rises across the whole network at once. The organisation experiences this as everything being blocked on everything, and typically responds by adding coordination — more forums, more planning events, more dependency mapping — which consumes the capacity that was supposed to be the gain.

Conway's Law is untouched

Conway's observation is that a system's structure mirrors the communication structure of the organisation that built it. It is about communication bandwidth between humans, and nothing in the current tooling generation changes who talks to whom, who is in which reporting line, or where the boundaries of ownership sit.

If your architecture is a monolith because four teams could never agree on interfaces, it is still a monolith, and now it is a monolith receiving change at a higher rate from four teams that still cannot agree. If your services are misaligned to your team boundaries, every change still requires the same number of conversations. Generation speed acts on a small part of the cost of a cross-boundary change and none of the coordination part.

The uncomfortable corollary: the marginal value of getting your team boundaries and service boundaries right has gone up. When implementation was the expensive part, a badly drawn boundary cost you some duplicated effort. Now that implementation is cheap, the boundary cost is a larger share of the total, and it is the share you cannot automate away.

The queues made of people deciding things

This is where most lead time actually lives, and it is entirely untouched. Map a change through your organisation and mark every period where it was waiting on a human decision rather than human work.

Approval queues. A change board that sits fortnightly imposes an average wait of about a week on everything, regardless of how quickly the change was written. Architecture review, security sign-off, legal review, a release manager's calendar — each is a queue with a service rate set by a meeting schedule.

Funding and prioritisation latency. If new work requires a business case that goes to a quarterly forum, your organisation's minimum idea-to-start latency is a quarter. This is usually the largest single number in the whole system and it is almost never measured. The shift from project funding to product funding is the structural answer and it has nothing to do with tooling.

Environment availability. If a shared pre-production environment is booked by other programmes, your change waits for a slot. The slot did not get shorter.

Vendor and third-party latency. Contract changes, external integration partners, certification bodies, app store review. Cheaper code does not move any of these, and some of them — continuous delivery through app store review is the clearest example — have their own fixed floor that no engineering practice can go below.

Decision latency generally. Time waiting for someone to say yes, someone to be available, or someone to stop escalating. In most organisations that measure honestly, this dwarfs everything technical.

Flow efficiency — touch time over elapsed time — typically sits in the low double digits before deliberate work is done on it, as set out in flow metrics. Halving the touch time in a system that is eighty-five percent queue moves the total by a rounding error. That is the arithmetic that should govern where you spend attention.

The things that get harder

Now the part that is more than neutral. Three costs genuinely rise with change volume, and they rise for structural reasons rather than because anyone is doing something wrong.

Conceptual integrity. Brooks argued that conceptual integrity is the most important single attribute of a system design, and that it comes from a small number of minds holding a coherent model. Higher change volume from more sources erodes it faster. Each change is locally reasonable; the aggregate drifts into incoherence. Three retry policies, two date representations, four ways of expressing the same domain concept. The cost surfaces later as the system becoming hard to reason about, which is expensive in a way nobody attributes correctly.

Coordination cost. Pairwise communication paths grow quadratically with the number of people, and the relevant number is now not just the people but the streams of change in flight. More concurrent change means more chance that two changes collide, more merge conflicts, more integration surprises, and more need to know what everyone else is doing.

Review and comprehension load. The most finite resource in the system is senior engineering attention, and higher volume consumes it directly. This is the subject of verification as the new bottleneck, and it is the mechanism by which an apparent productivity gain converts into a capacity crisis.

Property	Effect of cheaper generation
Little's Law	Unchanged. Still an identity.
Cross-team dependency wait	Unchanged; request volume up
Conway's Law	Unchanged; boundary quality matters more
Approval and funding latency	Unchanged; now a larger share of lead time
Environment availability	Unchanged
Deciding what to build	Unchanged; now a larger share of total cost
Conceptual integrity	Harder to maintain
Coordination cost	Rises with concurrent change
Senior attention required	Rises

What this implies about where to spend

None of the above is an argument against using these tools. It is an argument about sequencing, and it points in a clear direction.

The value of fixing your queues has gone up, not down. When production was expensive, a three-week environment wait was one problem among several. Now it is a larger proportion of a smaller total, which means the return on fixing it is higher than it has ever been. The same logic applies to every fixed cost in your release path: each one now sits in front of a supply of change that is effectively unlimited, and each one is therefore worth more to remove than it was.

The value of organisational design has gone up. Team boundaries, ownership, dependency structure and funding models were always the largest levers. They are now a larger share of the total cost and the share that no tool touches.

And the value of knowing what to build has gone up most of all. When building was expensive, building the wrong thing was expensive and therefore somewhat self-limiting. Now you can build the wrong thing very quickly and at scale, which makes outcome discipline less of a philosophical preference and more of a financial control.

What to do on Monday

Do the value stream exercise on one real change, end to end, with a stopwatch mentality. From the moment the decision was taken to the moment a customer could use it. Mark every wait state: waiting for prioritisation, for a reviewer, for an environment, for an approval, for a release window. Total the wait, total the work.

Then take the largest wait state and ask one question about it: is this physics, or is this a policy somebody wrote? In almost every organisation the largest wait is a policy, and policies can be changed by the people in the room. That is a better use of the next quarter than any tooling decision you could make.

Finally, look at what you are currently reporting upward. If a single number in that pack is about how much code is being produced, you are measuring the one thing that is no longer scarce, and you are creating pressure to increase the arrival rate at a constraint you have not yet found.