Ohno: Nobody Pulled This
Taiichi Ohno returns for Building, and his least-quoted idea explains why your delivery got slower.
Two numbers from CircleCI’s 2026 delivery report, which nobody reads together. Across all projects, average daily workflow runs rose 59 per cent year on year, an enormous increase in activity by any measure you like. For the median team, feature-branch throughput rose 15 per cent while main-branch throughput fell 7 per cent. More work started. Less work finished. The gap between those two figures is where the whole story of AI-assisted building currently lives.
Ohno had a word for that gap, and it is not the word anyone quotes. He is remembered for muda, waste, and for the seven categories that made waste visible to a shop floor that had been swimming in it. But he was explicit that muda is downstream. The root is mura, unevenness, and mura produces both muri, overburden, and muda. Attack the waste without attacking the unevenness and you are treating a symptom, which is probably why waste-elimination programmes have to be run again every three years. Deciding used Ohno for seeing: gemba, standard work, the five whys. Building needs the part of him that is about flow, because free making has installed unevenness at the centre of the way software now gets produced, and almost nobody has named it.
1. You installed unevenness deliberately
Consider what an engineering organisation actually is: a flow with a generation step and a verification step. Somebody produces a change; somebody else, or the same person on a different day, works out whether it is safe, correct and comprehensible enough to keep. Until about three years ago those two steps ran at roughly comparable speeds, because both were performed by humans reading and writing at human pace. The balance was invisible precisely because it was never in question.
Then one side of the flow got a hundred times faster and the other did not.
That is mura in its purest form. Not a mistake, not misuse, not a tooling problem: a structural mismatch between the rate at which one step can produce and the rate at which the next can absorb. Faros AI’s telemetry across more than 10,000 developers found teams with high AI adoption completing 21 per cent more tasks and merging 98 per cent more pull requests. Over the same period review time rose 91 per cent, and average pull request size rose 154 per cent. LinearB’s 2026 benchmarks, drawn from 8.1 million pull requests, found agentic pull requests waiting 5.3 times longer than unassisted ones before a reviewer even picked them up: 1,055 minutes against 201. The generation step improved enormously. The flow did not.
The consequences arrive in Ohno’s order. Muri lands on the reviewers, who are now asked to absorb twice the volume in change sets two and a half times the size, written by someone who was not present for the decisions. Ousterhout gave the last article the name for what that feels like from inside: cognitive load, the amount a person must hold in their head to act safely. Muri is cognitive load measured on a queue rather than on an individual. And then the muda follows, exactly as predicted, in GitClear’s numbers. Refactoring is down around 70 per cent against 2022 levels, duplicated blocks are up 81 per cent, and copy-pasted code climbed from 9.4 per cent of new code in 2022 to 15.7 per cent by early 2026.
2. The queue is inventory
Ohno’s most counter-intuitive teaching was about inventory, and it is the one that translates here without losing anything.
Conventional manufacturing regarded work in progress as an asset. Stock between stations meant no station ever starved; buffers absorbed variation; the line kept moving. Ohno insisted the opposite. Inventory was a waste in its own right, and worse, it was the waste that concealed all the others. A deep buffer means a defect can sit for a week before anyone downstream sees it, by which point the conditions that produced it are gone and so is the person who could explain them. Every problem your buffer absorbs is a problem you have paid for and not learned from.
An unreviewed branch is inventory. So is a merged change nobody has read, a generated module with no owner, a feature behind a flag that has been off for five months. It has all the properties Ohno objected to: it looks like progress, it sits between stations, it hides defects by delaying their discovery, and it costs money to hold in a currency nobody records.
His image for this was a lake. Lower the water and the rocks appear. The rocks were always there; the water was what let you pretend otherwise. The instruction is to lower the level on purpose, hit the rocks, and fix them, and it is the opposite of every instinct a delivery organisation has, because rocks look like incidents and water looks like resilience.
3. Who pulled this?
Which brings the question that survives the translation from a Toyota plant to a codebase with nothing lost at all.
Pull, not push. Push means you produce because you have the capacity to produce, and you send the output downstream because that is where output goes. Under pull, nothing is made until something downstream signals that it is needed. The signal is the authorisation. No signal, no work, however idle the machine.
So: who pulled this? A customer waiting, a defect reproducing in production, a hypothesis that cannot be settled without building the thing, a regulator with a date. Those are pull signals. “We had the tool available”, “it was in the backlog”, “the agent was running anyway” and “it seemed like it would be useful later” are not. Those are push. And push under free generation has no ceiling, because the ceiling used to be the cost of writing the code by hand.
Ask the question of a week’s output in any large engineering organisation right now and the honest proportion with a real pull signal behind it is uncomfortable. I have not seen a leadership team that could answer it from data, which is itself the finding.
4. Levelling, and what it costs you to do it
Ohno’s remedy for mura is heijunka, levelling: match the rate of release to the rate the next step can absorb. On a plant floor that means a mixed, steady sequence rather than long batches of one thing. In software it means a cap on how much change can be open at once, which sounds administrative and is actually the hardest political act available to a technology leader.
The reason it is hard is that levelling looks like deliberately going slower, and every visible metric will confirm that impression for a quarter. Pull request counts fall. Individual engineers, who genuinely feel more productive with an agent, will say so, and they are not wrong about the feeling. LinearB’s data catches the shape of it: developers reported feeling around 20 per cent faster while measuring around 19 per cent slower. That is a 39-point gap between what the work feels like and what it does. A leader who levels chooses the measurement over the feeling, in public, against people whose own experience contradicts them.
But note what levelling actually restrains. It does not cap ambition or ration the tools. It caps the amount of unfinished, unverified, unowned change permitted to exist at one time, which is a cap on inventory rather than on work. And it converts the invisible cost of the queue into a visible cost at the front: somebody has to decide what not to start this week. That decision was always being made. It was simply being made later, by whoever eventually gave up on the branch.
5. The constraint moved and nobody sent a memo
Goldratt’s rule holds here with unusual force. Improving anything other than the constraint improves nothing. For thirty years the constraint in software delivery was authorship, so every tool, method and hiring decision was aimed at producing code faster, and that aim became so deeply assumed that it stopped looking like a choice.
The constraint has moved to verification. Everything downstream of the keystroke, review, integration, environments, comprehension, is now the narrow part, which is why organisation-level DORA metrics have stubbornly refused to improve in the studies while individual-level metrics have soared. Pointing more generation at a verification constraint does not raise throughput. It raises inventory, and inventory is where the bill accumulates.
Ohno built his system for a factory that could out-produce its own ability to absorb what it made, which may be the fairest description currently available of a modern engineering organisation. Hence a man who died in 1990, and never worked on software, being one of the more useful people to read this year. The next article stays with what happens to code that nobody understands well enough to change, which is Parnas’s territory and the long-run price of everything described here.
Where this sits: Building, the third of four phases; Learning, Deciding, Building, Transforming. Ohno arrives here carried forward from Deciding, where he held Information, because overproduction is what free making does to a build. What an organisation gets out of that work is a working system and the discipline to subtract from it. The Build Is the Test opens this stretch of the argument, and From Deciding to Building is the bridge into it.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
Count your inventory, then ask who pulled it.
Take one team and one week. Count four things: pull requests opened, pull requests merged, the age of the oldest open branch, and the number of merged changes nobody outside the author has read. That last one will require asking rather than querying, and the asking is part of the exercise.
Then take a sample of ten merged changes and ask a single question of each: who pulled this? Name the customer, the defect, the hypothesis or the date. Not the ticket, which records that somebody wanted it, but the demand signal underneath the ticket.
Sort the ten into pulled and pushed. Do not argue about the borderline cases; put them in pushed, because a pull signal you have to argue for is not one.
Now show your leadership team two numbers side by side: opened against merged, and pulled against pushed. If opened exceeds merged you are accumulating inventory, and the gap is compounding while you look at it. If pushed exceeds pulled you are running a push system with the cost cap removed, and Ohno would tell you what that produces, because he watched it happen to people who thought full shelves meant a good month.
Further Reading
Taiichi Ohno: Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988; first published in Japanese, 1978). Short, blunt, and much stranger than its reputation. Read chapters one and two for pull and for why he treats inventory as a moral failing rather than a working capital line.
GitClear’s AI code quality research, now spanning hundreds of millions of changed lines, is the longest continuous measurement of what generated code is doing to maintainability. Read the duplication and churn series rather than the headline.
LinearB’s engineering benchmarks and CircleCI’s state of software delivery are the two datasets large enough to separate activity from throughput. The split between feature-branch and main-branch numbers is the single most useful thing in either.
I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.