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.

Agile is software engineering's version of TPS. The Agile Manifesto, & Extreme Programming—what were they about?

• Customer collaboration: programmers observe customer demands and work backwards to implement it.
• Test-driven development: tests demand code, not the other way around.
• Continuous Integration: ship small units of software continuously
• Refactoring: organizing code make it easier to produce changes
• Open source: development is broadly organized, not centralized

A lot of it was explicitly inspired by Lean Manufacturing (America's version of the Toyota Production System) and happened in the late 90s and early 00s, the pre-smartphone internet era. YAGNI is just inventory reduction, right?

Toyota won and so did Agile, but in the process they became so well known that it's not clear what they even mean in an AI programming 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. There's not a perfect term here but let's call it "updates". Updates flow out of the software factory.

Information flows backwards through the factory, with customers pulling work. Pushing code ceaselessly doesn't work once the bottleneck moves. Tests are information; they pull code. But issues are also information; they pull tests. Customer stories pull issues. Observability tools pull issues too. This flow is newer and less well developed in software engineering theory 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 hand-off with 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 have a definition of good design, of good code, of good tests. No step is done until it is good.

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.

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.