The Transaction Cost Collapse

The argument about batch size has a hinge in it, and most people miss the hinge. Batch size is not a preference, a maturity level or a cultural trait. It is an economic consequence. Organisations batch because getting one change from an idea to a customer carries a fixed cost that does not depend on how big the change is, and batching amortises that cost. Lower the fixed cost and batch size falls on its own, without anybody being persuaded of anything. Raise it and batch size climbs back no matter how many posters you put on the wall.

That fixed cost — the transaction cost of a change — has several components. Producing the change is one of them. Reviewing it, testing it, approving it, deploying it and standing behind it afterwards are the others. For most of the history of commercial software, production was the largest single term and the one everybody planned around. Estimation practice, team sizing, capacity planning, the entire apparatus of delivery management assumes that writing the code is the expensive part.

Coding assistants have made a serious dent in that term. Not uniformly, not for every kind of work, and not to the degree the marketing suggests — but a real and structural dent in the cost of producing a plausible candidate change. The interesting question is not whether that is impressive. It is what it does to the rest of the equation, because the rest of the equation did not move.

This article is the answer to that question, and it is the spine of everything else in this part of the library. The short version: the transaction cost did not collapse. One term in it did. The cost redistributed rather than disappeared, the constraint moved downstream, and organisations that respond by producing more without touching what sits downstream have not sped up. They have built a longer queue in front of an unchanged bottleneck, which is the oldest mistake in delivery wearing a new costume.

The economics, stated properly

The batch size argument rests on two opposed costs. Transaction cost is what it takes to process one batch regardless of its contents: the regression run, the change paperwork, the deployment, the warranty period. Holding cost is what it costs to keep finished work sitting unreleased: delayed revenue, delayed learning, delayed defect discovery, decay of the assumptions the work was built on.

Total cost is a U-shaped curve. The optimum batch size sits where the two are roughly balanced. Reduce transaction cost and the optimum moves left — smaller batches, more often, at lower total cost. This is not controversial and it has been well understood since Reinertsen wrote it down.

The part that matters here is a distinction that sounds pedantic and is not. Transaction cost has two halves, and they behave completely differently.

The cost of producing a candidate change. Writing the code, wiring the plumbing, translating an intent into an artefact that might work. This is the half that assistants attack directly, and where the gains are genuine and sometimes large.

The cost of establishing that the change is correct. Reading it and forming a judgement. Running tests and believing the result. Confirming it does not break something three modules away. Getting whatever sign-off your estate requires. Deploying it and watching it.

Only the first half has fallen. The second half is, for most organisations, exactly where it was — and in a few specific respects it has got worse, because the volume of things requiring verification has gone up while the capacity to verify has not.

Why a partial reduction moves the constraint

Theory of Constraints makes a claim that is easy to nod at and hard to act on: improvement anywhere other than the constraint is an illusion. Local efficiency that does not relieve the bottleneck produces inventory, not throughput.

Apply that to a delivery system where production has become dramatically cheaper. Changes now arrive at the review stage at a higher rate. Review capacity is bounded by the number of engineers who can hold the system in their head and the hours they have, which has not changed. Test confidence is bounded by whether your suite is trusted, which has not changed either. Deployment throughput is bounded by your pipeline and your approval path, which have certainly not changed.

The result is queueing, and queueing behaves the way it always does. As arrival rate rises against a fixed service rate, utilisation of the constraint approaches one and wait time goes non-linear — the curve described in why busy teams are slow teams. You do not need to model it. You can see it: pull requests ageing, reviewers becoming a named dependency, authors context-switching between six open changes, review quality dropping because reviewers are rushing.

Little's Law is indifferent to how the work got created. Average cycle time equals average work in progress divided by average throughput. If throughput is capped by verification and you increase work in progress by generating more, cycle time rises proportionally. You have bought nothing. You have bought a longer queue with cheaper items in it.

This is the specific failure mode to name and watch for, because it presents as success. Output metrics look wonderful. Commits are up, lines are up, pull requests raised is up, everybody feels productive. Lead time to production is flat or worse. If your organisation measures activity rather than flow, you will not find out for two quarters.

Redistribution, not elimination

It is worth being precise about the claim, because the sloppy version of it is everywhere and it is wrong in both directions.

The sloppy optimistic version says the cost of software has collapsed. It has not. The cost of one component of software delivery has fallen sharply. Meanwhile some costs have risen: reviewing changes you did not write is harder than reviewing changes you did; maintaining conceptual integrity across a larger volume of change is harder; deciding what should be built has not become any easier and is now a larger share of the total.

The sloppy pessimistic version says nothing has really changed. That is also wrong, and it is the more comfortable error for experienced engineers to make. A structural reduction in the cost of the production half of the transaction is a genuine change to the economics, and the strategic implication is significant: it makes reducing the rest of the transaction cost far more valuable than it was before, because the payoff to fixing the bottleneck is larger when everything upstream of it is cheap.

Here is the redistribution, stated as a comparison.

Cost component	Before assistants	Now	Direction
Producing a candidate change	Dominant term	Substantially reduced	Down, sharply
Reading and judging a change	Moderate	Unchanged, higher volume	Up in aggregate
Test confidence	Depends entirely on your suite	Unchanged, matters more	Up in importance
Deciding what to build	Often underweighted	Unchanged in cost, larger share	Up as a proportion
Integration and merge	Proportional to batch size	Worse if volume rises without discipline	Up unless managed
Approval and release path	Policy-determined	Entirely unchanged	Flat, now dominant

Read the last row carefully. If your release path was already the expensive part — a fortnightly change board, a manual regression pack, an environment that takes a day to provision — then the production-side gains are almost entirely absorbed before they reach a customer. You have made the cheap part cheaper. Nothing arrives sooner.

The two responses, and why one compounds

Faced with cheaper production, organisations take one of two paths. They look similar in the first month and diverge sharply after that.

The volume response. Generate more, faster. Keep the same review process, the same test suite, the same pipeline, the same approval path. Measure the gains in output. This is the path of least resistance because it requires no negotiation with anybody. It produces a growing inventory of unverified change, a review queue that lengthens, and eventually a quality event that gets attributed to the tooling rather than to the queue.

The verification response. Take the freed capacity and spend it on the constraint. Make the test suite trustworthy. Build evaluation harnesses where behaviour is not deterministic. Shrink changes so each is independently reviewable and independently releasable. Make the pipeline fast enough that running it is not a decision. Delete approval steps that produce no assurance.

The second path compounds, and the mechanism is worth spelling out rather than asserting. Each cycle gets cheaper because production is cheap and verification is cheap. Each cycle also produces trustworthy learning, because a small verified change generates an attributable signal rather than an ambiguous one. Cheaper cycles plus better learning per cycle is a genuinely multiplicative effect, and it is the only honest version of the exponential claim. Note the condition attached: the compounding is entirely contingent on verification keeping pace. Without that, more cycles produce more noise and more rework, which is compounding in the wrong direction.

What the freed capacity is actually for

If production capacity is no longer the scarce input, then spending it on more production is a category error. It should be spent on whatever is now scarce. In most estates that is one of four things.

Test confidence. Not test coverage — confidence. A suite nobody trusts does not reduce verification cost, it adds a step. This is the subject of verification as the new bottleneck and of the existing test strategy argument, which needed no revision.

Change size discipline. Smaller changes are cheaper to review, and review is the constraint. The economics of trunk-based development got stronger, not weaker, when generation got cheap. The temptation runs the other way — a large change costs almost nothing to produce now — and that temptation should be resisted deliberately.

Pipeline speed. Every minute of pipeline latency is a minute of the constraint's cycle time. When production was the expensive part, a slow pipeline was an annoyance. Now it is the main event.

Deleting approval steps that produce no assurance. This is usually the largest single term and it is pure policy, which means it is available. The test is simple: ask what a given gate has actually caught in the last year, and whether the same assurance could be produced automatically and continuously. Even in regulated estates the requirement is evidence of control, not a particular meeting.

What to do on Monday

Take your last twenty merged changes and, for each, record two numbers: hours from first commit to pull request raised, and hours from pull request raised to deployed. You are looking for the ratio. If the first number has fallen over the last year and the second has not, you have measured the transaction cost collapse and its redistribution directly, in your own estate, without needing to believe anything I have written.

Then find the single largest contributor to the second number and ask whether it is physics or policy. Reviewer availability is capacity — attack it with change size and with review practice. A fortnightly approval board is policy. A manual regression pack is an investment decision you have been deferring.

Finally, look at what you currently report upward about assistant adoption. If the numbers are about output — commits, lines, suggestions accepted, tickets closed — replace them with lead time and change failure rate before someone builds a target on them. Measuring a system whose capability is shifting is genuinely difficult, but measuring the wrong end of it is not difficult at all, and it is what most organisations are currently doing.