The Token Production System

Materials flow through a factory: metals become parts become assemblies become cars. Each station can only produce so much, and you might try to make each station more efficient, producing more materials in less time. But this is not the way.

It is not the way because information also flows through a factory: orders for cars becomes a need for assemblies, which becomes a need for parts. Bottlenecks become a need for processes become a need for machines. Defects become a need for process improvement. Characteristically, information flows backwards through the factory, from customers to suppliers. This is what "just in time" and "pull production" are about.

The Toyota Production System is also about quality. Quantity without quality means variability, which leads to overwork, which leads to waste. Quality means consistency not just within but between stations, which supports continuous flow, which ultimately reduces waste.¹ [¹ There are eight forms of waste. Ask Tim Woods.]

The most famous form of waste is inventory. Under the Toyota Production System the factory operates in continuous flow. Queues between stations are caused by inconsistency; the ideal factory is empty. Toyota is famous for its low defect rates; the process improvement inventory is empty too.

Agile, Extreme Programming—what were they about?

• Customer collaboration: programmers observe customers and implement the features they need.
• Test-driven development: tests demand code, not the other way around.
• Continuous Integration: small units of software, shipped continuously.
• Refactoring: organizing code make it easier to produce changes.
• Open source: broad, parallel development in public view.

A lot of it was explicitly inspired by Lean Manufacturing. YAGNI is just inventory reduction. Kanban is just 看板.

Toyota won and so did Agile, but in the process they became so well adapted to their context that it's not clear what they mean in an agentic world. Let's go back to basics.

A software factory produces software, sure, but specifically it delivers a steady stream of features, bug fixes, and optimizations. Call them all "updates". Updates flow out of the software factory.

But pushing code ceaselessly doesn't work once the bottleneck moves. We need the backwards flow, pull production for software.

Information flows backwards through the factory, pulling work. Tests are information; they pull code. Issues are also information; they pull tests. Features pull issues. Observability tools pull issues too. This flow is newer and theoretically less developed but it will be more important than the flow of updates.

The stations in the factory are things like design, coding, debugging, testing, reviewing, deployment, and metrics. Stations aren't independent. Don't optimize the stations, optimize the system, the hand-off between stations and the deployment of resources across them.

Optimize quality. We don't need code review agents, we need agents that write reviewable code. Quality means consistency. You need to decide what reviewable means and you need to enforce it. You need to define good design, of good code, of good tests. Don't pass defective code to the next station. Fix the process.

You must walk the floor. Look at agent traces. What commands do they run? What do they mess up? Do not blame your factory workers; yelling at Claude will not help. Every defect becomes a process improvement.

The largest factories² [² POSCO is not literally the largest one, but for the Everett plant you have to take a tour. For POSCO, Google Maps is enough.] are much like the smallest ones. Both produce continuous flow.

Software factories are still scaling up. They do not match genius software craftsmen. But software for the great multitude will come from a factory. The factory must be built.