Software has borrowed a surprising amount from manufacturing. Not from manufacturing in the sense of “let’s put programmers on an assembly line.” Thankfully, we’ve tried enough variations of that idea already.
I mean something more interesting.
Some of the most influential ideas in modern software development came from looking at how Toyota transformed manufacturing. Lean Software Development, Kanban, limiting work in progress, reducing waste, optimizing flow, continuous improvement, pull systems—many of these ideas have a lineage that leads back to manufacturing.
And at the center of that story is the Toyota Production System (TPS).
Toyota describes TPS around two pillars: Jidoka and Just-in-Time. Jidoka is roughly “automation with a human touch”: when an abnormality is detected, the process stops rather than continuing to produce defective products. Just-in-Time is about producing what is needed, when it is needed, and in the amount needed.
These ideas were developed for a world of physical products. But we are entering another period where software development is changing dramatically—and this time, the manufacturing analogy might be useful for a completely different reason.
The Software Bottleneck Is Moving
For most of the history of software development, producing software was expensive. Writing code took time. Understanding a codebase took time. Testing, debugging, and reviewing code all took time. Because developers are human, all of these activities were constrained by the number of humans available to perform them.
We built processes around this constraint:
- Integrated Development Environments (IDEs) to make writing and navigating code faster
- Languages & Frameworks to make code easier to express
- Continuous Integration (CI) systems to automatically build and test changes
- Agile & Kanban to improve feedback loops and flow
Then coding agents arrived. Suddenly, the cost of producing code changed. An agent can read a codebase, modify dozens of files, run commands, inspect test results, make another change, and repeat the process without waiting for a human to type every line.
The production capacity of software development can increase dramatically. But if an agent can produce changes faster than we can establish that those changes are correct, we have created a new bottleneck: Verification.
That is a manufacturing problem, and manufacturing has spent a very long time thinking about it.
Looking at the Factory Floor Again
The answer is not to blindly copy Toyota. Software has no physical inventory, no physical assembly line, and no truck waiting for parts. But the underlying challenges are identical:
- How do you prevent defects?
- How do you detect problems as early as possible?
- What should happen when an abnormality occurs?
- How much unfinished work should be allowed to accumulate?
- How do you improve the production process rather than merely inspecting its output?
- How do you increase production speed without increasing the rate at which defects escape?
These are the exact questions that led to modern manufacturing quality practices.
Jidoka & The Software Andon CordJidoka & The Software Andon Cord
Of all the Toyota concepts, Jidoka is the most interesting for AI coding agents. The basic idea is simple: if a machine detects an abnormality, it stops. The objective isn’t simply to detect defective products at the end of the line—it is to prevent the production of more defective products in the first place by building quality directly into the process.
A conventional automated system behaves like this:
Jidoka aims for something different:
Imagine an agent working on a task. It modifies several files sequentially. Tests pass until an important invariant — a condition that must always remain true — breaks. A naïve agent continues attempting fixes randomly:
“Test failed. I’ll try another approach… and another… and another.”
In doing so, it accumulates a massive amount of unverified state. A Jidoka-inspired agent behaves deliberately. This is where the lean idea of standardized work becomes interesting: the agent should operate within clearly defined constraints — what must remain true, what must be checked, and when work must stop.
The agent should not merely be capable of stopping; it should be designed to stop.
The Andon Cord
Toyota uses an Andon signal to make abnormalities visible and draw immediate attention to the point of failure. While software already uses signals like failed CI builds or production alerts, AI agents allow us to make every invariant an Andon cord:
- A type error that would cause the program to crash
- A change that breaks an agreed interface between two services
- A security rule that has been violated
- A database change that would destroy existing data
- A drop in the percentage of code protected by tests
- A performance budget that has been exceeded
The critical distinction is that the signal is not just a passive warning displayed on a dashboard; it is an active control mechanism. The agent loses permission to continue until the abnormality is resolved.
As with an Andon signal on a Toyota production line, stopping is only the beginning. Someone must investigate the abnormality, determine whether the problem is with the product or the process, and decide what should happen next. In an agentic system, that role may increasingly belong to the engineer overseeing the production system rather than the person reviewing every individual line of code.
Poka-yoke: Mistake-Proofing the Environment
Poka-yoke focuses on using fail-safe mechanisms to avoid simple mistakes entirely. We tend to frame software verification as:
“How can we detect whether the agent made a mistake?”
A far better question is:
“Can we make it impossible for the agent to make this particular mistake?”
If an agent needs to modify a database, giving it unrestricted access relies on post-hoc testing to catch dangerous operations. Designing a poka-yoke environment changes the interface:
A destructive operation simply isn’t available through the interface. The agent cannot execute it because the capability does not exist in that context.
This applies equally to dependency installation (adding external software libraries), secret access (credentials and other sensitive information), schema migrations (changes to the structure of a database), and permission changes.
Core Design Principle: Don’t teach the agent not to make a mistake when you can design the system so the mistake cannot be made.
Quality at the Source & WIP Limits for Uncertainty
An agent executing a dozen changes before running verification creates a massive search space when a failure inevitably occurs. Diagnosing which assumption failed becomes exponentially harder as unverified work accumulates.
AI coding agents require a concept similar to Work-in-Progress (WIP) limits. Instead of tracking open tickets, we should limit the amount of unverified change in the system.
This connects directly back to Just-in-Time. If Jidoka tells us when to stop, Just-in-Time tells us how much work should be allowed into the system in the first place. Why should an agent generate more changes than the verification system can absorb? The answer is not to maximize production, but to establish a pull-based system in which new work is released as verification capacity becomes available.
Consider an agent operating with a Verification Debt budget: a simple measure of how much unverified change the system is currently carrying.
- Unchecked Invariant = +1
- Unvalidated Dependency = +1
- Unverified Integration = +1
The exact numbers are less important than the principle: as unverified work accumulates, the agent’s freedom to continue should decrease.
- Verification Debt = 0: Agent proceeds freely.
- Verification Debt = 3: Agent must verify before taking further actions.
- Verification Debt = 5: Agent is stopped completely.
The Economics of Inspection
Not every verification step needs to carry the same execution cost. Cheap defects must be caught cheaply through a tiered inspection pipeline:
Verification should follow the principle of catching problems as early and cheaply as possible. An agent that introduces a simple syntax error — such as a missing parenthesis or a misspelled keyword — should be stopped in seconds by the first layer, not after a lengthy end-to-end test that exercises the entire system. The same principle applies as we move from increasingly local checks to increasingly expensive checks of the whole system.
If an agent references a non-existent function, a basic automated test or check should catch it immediately; it should not require a 45-minute suite of tests that exercises the entire system. In a high-throughput environment where an agent generates dozens of candidate changes an hour, optimizing the verification loop itself is critical to preventing systemic bottlenecks.
Process Control and Root-Cause Analysis
Statistical Process Control
In traditional manufacturing, Statistical Process Control (SPC) monitors the process, not just individual outputs. The goal is to distinguish an isolated defect from a change in the underlying process. If an agent’s defect rate suddenly spikes, focusing only on single test failures misses system-level shifts (e.g., context window truncation, degraded model weights, altered tool behavior, or stale API specs).
Tracking process-level metrics provides visibility into the health of the system:
| Metric | Target Baseline | Out-of-Control State |
| Compile Failures / 1,000 Changes | 0.7% | 4.8% |
| Test Failures / 1,000 Changes | 3.1% | 8.2% |
| Reverted Changes | 0.9% | 5.7% |
| Security Findings | 0.03% | 0.11% |
When metrics breach baseline thresholds, the relevant question isn’t “Is this code change bad?” but “Has the production process itself gone out of control?”
Human Review Shifts Upward
When an engineer oversees dozens of autonomous agents, manual line-by-line code review becomes impossible. The human role shifts from reviewing individual changes to evaluating the integrity of the production process: verification coverage, failure patterns, architectural invariants, and root causes.
This is not entirely new. Toyota’s use of automation with a human touch was partly about allowing one person to supervise multiple processes while still responding when an abnormality occurred. Coding agents may create a similar shift: engineers spend less time producing and inspecting individual changes, and more time designing, monitoring, and improving the system that produces them.
This raises a harder question: if agents perform more of the improvement work themselves, how do engineers continue to develop their skills?
There is a real risk here. Engineers traditionally learn by writing code, debugging failures, and seeing the consequences of their decisions. If agents perform all of those activities, we cannot assume that expertise will automatically develop at a higher level.
The answer is not to keep humans artificially busy writing code. Engineers will need to learn to understand the system at a different level: defining what good looks like, identifying meaningful abnormalities, challenging the agent’s proposed improvements, and deciding whether a local optimization actually improves the whole system. Agents may increasingly perform the mechanics of improvement; engineers remain responsible for the judgment of improvement.
Kaizen (Continuous Improvement)
When a failure occurs, the agentic loop should produce process knowledge rather than simply retrying. The agent can increasingly identify patterns and propose improvements; the surrounding system must ensure that those improvements are validated before becoming new constraints:
Every failure should permanently update the system constraints:
End-to-End Traceability
When a defect manifests in production months after deployment, tracing its origin in an agent-generated codebase requires a complete provenance chain:
Understanding defect origin shifts our diagnosis from “Who wrote this code?” to “What production process generated this code, and where did that process fail?”
Conclusion: The Quality System Is the Deliverable
The conversation around AI coding agents focuses heavily on the agent itself: which model, which benchmark, which context window, which reasoning capabilities.
These factors matter, but the system surrounding the agent will ultimately matter more. A mediocre agent operating inside an exceptional verification environment will consistently outperform a brilliant agent operating inside a weak one.
The future of autonomous software engineering is less about building an AI that never makes mistakes, and more about building a production system in which mistakes are cheap, contained, visible, and quickly corrected.
The first wave of Lean software development optimized for flow, reduced batch sizes, and shorter feedback loops. The next evolution will focus on verification. As production costs drop toward zero, quality engineering becomes the primary constraint.
But there is another question we should not lose sight of. If agents increasingly perform the work of improvement, we must also design systems in which engineers continue to learn. The goal is not to remove engineering expertise from the production system, but to move it to the level where it has the greatest leverage.
The most important question in modern software development is no longer “How do we build software faster?”
It is: “How do we build a system that produces software extremely fast without letting defects escape just as fast?”
This article and graphics have been developed with the assistance of AI.
Lean AI Basics
Learn to get consistently good answers from any AI tool — not just lucky ones.
