The manifesto of the lean software factory
Dr. Aaron Hutzler · 20 August 2026 · 10 min
Software development has left its craft stage behind. Anyone running AI in operates a highly automated software factory. Agents produce code modules in three shifts around the clock. They turn tests by the second. They open new work sites faster than a human eye can follow.
That speed carries a manufacturing paradox with it. Multiply production speed by five and the pile of shavings, scrap and buffer clogs multiplies by five too.
Manufacturing knows three evils for this: Muda, waste. Muri, overburden. Mura, unevenness. An AI agent never delivers the same result twice for the same task, sometimes lean, sometimes verbose. A test battery has to catch exactly that unevenness on top of the scrap.
Whoever wants to run such a factory cannot rely on an AI agent's verbally requested care. No plant manager hangs a sign on a stamping press reading "please produce no scrap today." Physical manufacturing builds mechanical barriers, automatic tripwires and 5S workstations instead.
This post carries seventy years of proven engineering from the Toyota Production System and Lean Production over into cleaning up and preventing chaos in AI agents.
1. The overview: the lean production system for AI code
A countermeasure that ignores the trick has no teeth. states it plainly: once a metric becomes the target, it stops being a good metric. An agent then optimizes the rule itself and skips its intent. That is exactly what the third column of the table below names: the trick an agent uses to formally satisfy a rule while missing its purpose.
Table 1: Eleven building blocks of the lean software factory: the lean principle, the Goodhart risk and the countermeasure.
| Lean principle | Protective purpose (what it prevents) | Goodhart risk (how the agent cheats) | Countermeasure and guardrail |
|---|---|---|---|
| 5S: Seiso (shine) | Forgotten scratch files, debug logs, and temp files in the commit | Renames scratch files into regular filenames (util_tmp.ts) | Strict file allowlist and git status inspection |
| 5S: Seiri (sort) | Code no specification needs anymore stays in place | Deletes safety fences or plants fake calls (if(false)) | Two-way tracing: code knows its specification, the specification knows its code (@spec(ID)) |
| 5S: Seiton (set in order) | Fragmentation and folder sprawl across the repo | Squeezes ten functions into an unreadable 200-line cascade | Paired limits, minimum and maximum lines per function |
| 5S: Seiketsu (standardize) | The standing instruction file keeps growing (hard byte cap: 8192 bytes) | Shrinks rules so far that edge cases go missing | Module rules fall under the same byte budget |
| 5S: Shitsuke (sustain) | No release while quality standards are violated | Tries to manipulate the test environment or test doubles (mocks) | Read-only quarantine sandbox for the test runner |
| Jidoka (tripwire) | Files grow past their frozen baseline | Deletes comments, types, and error handling to save lines | The ratchet counts substance, not lines: comments and error handling count too |
| Poka-yoke (mistake-proofing) | Silent tampering with AI control and check scripts | Tries to falsify test doubles or test inputs | Checksum pinning and write protection on the checker |
| Kanban, WIP limit | Open work sites clog the conveyor belts | Bundles three unrelated features into one giant change | Maximum change size, one change equals one specification, cap at fifteen open changes |
| Kaizen (improvement) | Leaves code simpler after every wave (Boy Scout rule) | Makes things worse through careless rebuilding | Re-think step only under a hundred percent green invariant tests |
| Autonomy | Human bottlenecks on routine cleanup work | Overzealous, irreversible deletion of work in progress | Git reversibility, cleanup in its own commits |
| Waste disposal | Merged, abandoned branches clog the remote | Merges unfinished code just to trigger branch deletion | Merge only with a hundred percent green test battery |
2. 5S in the software factory: from chaos to a clean workstation
The Japanese 5S system is the foundation of every functioning production line. Applied to AI agents, it reads:
Seiri (sort) -> dead code goes out
Seiton (set in order) -> fixed places for modules
Seiso (shine) -> no shavings, no logs in the commit
Seiketsu (standardize) -> byte cap on the instruction file
Shitsuke (sustain) -> automatic main pipeline: a hundred percent green
2.1 Seiri: more than dead lines of code
Sorting does not stop at dead lines of code. Orphaned package dependencies, unread environment variables and images or language keys nobody references anymore are the same waste. They just sit outside the source files. The same tracing that finds dead code finds them too. It flags dead code and dead dependencies alike. Whatever no specification references anymore goes out.
The most expensive case is the safety fence of unknown purpose. Chesterton's fence rule still holds here: a fence comes down only once its purpose is understood [5]. An agent mistakes an old error guard for dead code. It tears down exactly that fence.
2.2 Seiso: no scratch files in the commit
On the shop floor, the worker wipes the metal shavings off after the shift. An AI agent uses the file system as its scratch pad.
The rule: an automatic check step refuses every carrying abandoned scratch files, debug logs (console.log), test fixtures, or .tmp files.
The Goodhart trap: the moment the agent notices .tmp is blocked, it renames its scratch files to src/utils/temp_helper.ts.
The poka-yoke barrier: only files from an explicit allowlist of the get through.
2.3 Seiketsu: the byte budget for prompts
No worker reads a five-hundred-page operating manual. A byte cap limits the agent's standing instruction file to exactly 8192 bytes.
If the agent or a developer wants to add a new rule, an old one has to go, or move into a modularized sub-file. The working context stays razor sharp.
3. Jidoka and poka-yoke: mechanical tripwires against agent tricks
Two protective concepts sit at the center of the Toyota Production System [1]. Jidoka is the automatic tripwire on error. Poka-yoke is the mechanical protection against mishandling.
3.1 Jidoka: the ratchet principle
If a thread snaps on a weaving loom, the machine stops instantly. No flawed cloth keeps getting woven.
The mechanism: every module file carries a frozen size baseline, stated in lines as a stand-in for the file's substance. If a file shrinks from 400 to 320 lines during refactoring, the ratchet freezes the new baseline at 320 lines. If the agent only deletes comments and error handling to reach the same line count more cheaply, the ratchet counts that as a loss of substance. It does not freeze then.
Baseline at 320 lines -> agent builds a feature -> count grows to 325 lines
|
JIDOKA STOP
Build fails, clean up first
If a file grows to 325 lines in a following agent step, the aborts immediately. The agent cannot build any more feature code until the entropy is cleaned up.
3.2 Poka-yoke: protecting the check chain itself
A poka-yoke is a mechanical lockout [2]: a plug fits the socket in only one direction.
The danger: an agent fails the test battery. Sooner or later it tries to edit the check itself and force the "green" grade.
The poka-yoke barrier: control files, , and check scripts are pinned with checksums. The agent has no write access to the test runner sandbox.
The same tripwire applies to time instead of lines. If an agent fails the same repeatedly, a second Andon mechanism kicks in. The session stops for a human review. It burns no further effort in a loop of ever-new tricks.
4. Flow and kanban: preventing a clogged conveyor belt
Under , lead time in a factory rises in proportion to the number of started, unfinished pieces of work, the technical term is work in process:
Work in process = throughput * lead time
A cap limits open changes to fifteen at a time, on the same principle as the kanban inventory cap in lean production [3]. A second rule requires finished changes to be archived immediately.
The payoff: both the developer's head and the agent's context stay free of leftover baggage. Anyone wanting to start a sixteenth piece of work first has to clean up, finish and one of the fifteen open work sites.
5. Kaizen and gemba: continuous cleanup and the acid test
5.1 Kaizen: the re-think step, the Boy Scout rule
Kaizen means: no day without a small improvement. The Boy Scout rule supplies the everyday form of it [4]. Code gets cleaner on the way out. It was not, on the way in.
The rule: a dedicated re-think step runs after every package is implemented. The agent gets one assignment. The code afterward is simpler than the code before.
The guardrail: the re-think step performs behavior-neutral refactoring only. Every invariant test stays green, before and after.
5.2 Gemba: checking the real object, mutation testing
Gemba means: go to where the work happens, trust no report on paper.
The problem with agents: an agent writes duplicate or useless tests (assert true) to satisfy numbers.
The gemba check: an automated mutator injects artificial defects into the cleaned-up code. If the test battery does not answer with a signal, the agent's test counts as a sham test and gets discarded.
6. The ten-point manifesto of the lean software factory
1. Cleanup is a pipeline step, not a prompt request. Verbally demanded care does not hold. Automated barriers on main do.
2. A measurement may only ever improve. The ratchet principle freezes a once-reduced module weight immediately as the new ceiling.
3. Tool waste is as dangerous as code waste. 5S: Seiso. Scratch files, temp files and abandoned test doubles block the commit outright.
4. Control needs a byte budget. 5S: Seiketsu. Prompts and the standing instruction file stay under hard byte limits, around 8 KB, or the context clogs.
5. The measuring tools are untouchable. Poka-yoke. Control files and grader scripts are checksum-pinned inside a read-only sandbox.
6. Tripwires stop the line instantly. Jidoka. If a hygiene gate trips, the feature build halts on the spot. If an agent fails the same gate repeatedly, a second tripwire stops the session for human review.
7. Cap work in progress. Kanban WIP limit. Never more than fifteen open changes at once, archiving is mandatory.
8. Check the real object. Gemba and . A green proves nothing. It has to be able to fail under mutation.
9. Keep cleanup commits separate from feature commits. Autonomous housekeeping runs in its own commits. Tracing the history (git bisect) stays readable that way.
10. Every change leaves the repo cleaner. Kaizen. The re-think step runs after every package, protected by behavior-neutral invariants.
7. Sources
[1] T. Ohno, "Toyota Production System: Beyond Large-Scale Production", Portland: Productivity Press, 1988.
[2] S. Shingo, "Zero Quality Control: Source Inspection and the Poka-Yoke System", Portland: Productivity Press, 1986.
[3] J. P. Womack and D. T. Jones, "Lean Thinking: Banish Waste and Create Wealth in Your Corporation", New York: Simon and Schuster, 1996.
[4] R. C. Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", Upper Saddle River: Prentice Hall, 2008.
[5] G. K. Chesterton, "The Thing", 1929.