# Revisiting the Toyota Production System (TPS) in the Age of Coding Agents > Source: > Published: 2026-09-23 23:36:43+00:00 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. 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: 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**. ``` TRADITIONAL SOFTWARE ┌──────────────┐ │ Human writes │ │ code │ └──────┬───────┘ │ ▼ ┌──────────────┐ │ Verification │ └──────────────┘ Production and verification are relatively balanced. AI CODING AGENTS ┌──────────────────────────────┐ │ │ │ CODE PRODUCTION │ │ │ │ ████████████ │ │ ████████████ │ │ ████████████ │ │ │ └──────────────┬───────────────┘ │ ▼ ┌──────────────┐ │ VERIFICATION │ │ █ │ └──────────────┘ The factory produces faster than quality control can inspect. ``` That is a manufacturing problem, and manufacturing has spent a very long time thinking about it. 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: These are the exact questions that led to modern manufacturing quality practices. 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: **Produce → Produce → Produce → Inspect → Discover Problem** Jidoka aims for something different: **Produce → Produce → Detect Abnormality → STOP** Imagine an agent working on a task. It modifies several files sequentially. Tests pass until an important invariant 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: ``` Agent Makes Change │ ▼ Verification │ ▼ Abnormality Detected ──► STOP ──► Investigate ──► Fix ──► Verify ──► Continue ``` The agent should not merely be capable of stopping; it should be designed to stop. Toyota uses an Andon signal to make abnormalities visible and draw immediate attention to the point of failure. While software already uses crude signals like failed CI builds or production alerts, AI agents allow us to make every invariant an Andon cord: 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. 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: ``` ┌───────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ Agent │ ───► │ Database Tool│ ───► │ Policy Layer │ ───► │ Allowed Operation│ └───────┘ └──────────────┘ └──────────────┘ └──────────────────┘ ``` 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, secret access, schema migrations, 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. 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. ``` Make Small Change │ ▼ Verify │ ▼ Make Another Change │ ▼ Verify ``` Consider an agent operating with a **Verification Debt** budget: Unverified Integration = +1 **Verification Debt = 0**: Agent proceeds freely. **Verification Debt = 3**: Agent must verify before taking further actions. **Verification Debt = 5**: Agent is stopped completely. Not every verification step needs to carry the same execution cost. Cheap defects must be caught cheaply through a tiered inspection pipeline: ``` ┌───────────────────────────────────────────┐ │ Syntax / Parsing │ ◄── Fast / Cheap ├───────────────────────────────────────────┤ │ Type Checking │ ├───────────────────────────────────────────┤ │ Static Analysis │ ├───────────────────────────────────────────┤ │ Unit Tests │ ├───────────────────────────────────────────┤ │ Contract Tests │ ├───────────────────────────────────────────┤ │ Integration Tests │ ├───────────────────────────────────────────┤ │ E2E / Behavioral │ ├───────────────────────────────────────────┤ │ Adversarial Verification │ ◄── Slow / Expensive └───────────────────────────────────────────┘ ``` If an agent references a non-existent function, it should not require a 45-minute integration suite to catch it. 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. In traditional manufacturing, quality control monitors the process, not just individual outputs. 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?” When an engineer oversees dozens of autonomous agents, manual line-by-line code review becomes impossible. The human role shifts from reviewing individual diffs to evaluating the integrity of the generation process: verification coverage, failure patterns, architectural invariants, and root causes. When a failure occurs, the agentic loop should produce process knowledge rather than simply retrying: ``` Test Fails ──► Containment ──► Identify Abnormality ──► Root-Cause Hypothesis ──► Fix & Regression Protection ``` Every failure should permanently update the system constraints: ``` Agent Task Fails (Stale API Docs) │ ▼ Add Contract Test │ ▼ Update Agent Constraint │ ▼ Improved Production System ``` When a defect manifests in production months after deployment, tracing its origin in an agent-generated codebase requires a complete provenance chain: **Requirement → Agent Session → Model/Version → Context & Tools → Verification Logs → Human Approval → Commit** Understanding defect origin shifts our diagnosis from “Who wrote this code?” to “What production process generated this code, and where did that process fail?” 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. 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?”**