{"slug": "revisiting-the-toyota-production-system-tps-in-the-age-of-coding-agents", "title": "Revisiting the Toyota Production System (TPS) in the Age of Coding Agents", "summary": "A developer argues that AI coding agents have shifted software development's bottleneck from code production to verification, drawing a parallel to the Toyota Production System's Jidoka principle of stopping production when an abnormality is detected. The piece contends that agents which keep generating changes after a failed test accumulate defective work, and that manufacturing quality practices offer a model for building verification into agent workflows.", "body_md": "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.\n\nI mean something more interesting.\n\nSome 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.\n\nAnd at the center of that story is the Toyota Production System (TPS).\n\nToyota 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.\n\nThese 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.\n\nFor 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.\n\nWe built processes around this constraint:\n\nThen 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.\n\nThe 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**.\n\n```\nTRADITIONAL SOFTWARE\n\n┌──────────────┐\n│ Human writes │\n│    code      │\n└──────┬───────┘\n       │\n       ▼\n┌──────────────┐\n│ Verification │\n└──────────────┘\n\nProduction and verification are relatively balanced.\nAI CODING AGENTS\n\n┌──────────────────────────────┐\n│                              │\n│      CODE PRODUCTION         │\n│                              │\n│          ████████████        │\n│          ████████████        │\n│          ████████████        │\n│                              │\n└──────────────┬───────────────┘\n               │\n               ▼\n        ┌──────────────┐\n        │ VERIFICATION │\n        │      █       │\n        └──────────────┘\n\nThe factory produces faster than quality control can inspect.\n```\n\nThat is a manufacturing problem, and manufacturing has spent a very long time thinking about it.\n\nThe 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:\n\nThese are the exact questions that led to modern manufacturing quality practices.\n\nOf 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.\n\nA conventional automated system behaves like this:\n\n**Produce → Produce → Produce → Inspect → Discover Problem**\n\nJidoka aims for something different:\n\n**Produce → Produce → Detect Abnormality → STOP**\n\nImagine 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:\n\nTest failed. I’ll try another approach… and another… and another.\n\nIn doing so, it accumulates a massive amount of unverified state. A Jidoka-inspired agent behaves deliberately:\n\n```\nAgent Makes Change\n       │\n       ▼\n  Verification\n       │\n       ▼\nAbnormality Detected ──► STOP ──► Investigate ──► Fix ──► Verify ──► Continue\n```\n\nThe agent should not merely be capable of stopping; it should be designed to stop.\n\nToyota 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:\n\nThe 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.\n\nPoka-yoke focuses on using fail-safe mechanisms to avoid simple mistakes entirely. We tend to frame software verification as:\n\n“How can we detect whether the agent made a mistake?”\n\nA far better question is:\n\n“Can we make it impossible for the agent to make this particular mistake?”\n\nIf 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:\n\n```\n┌───────┐      ┌──────────────┐      ┌──────────────┐      ┌──────────────────┐\n│ Agent │ ───► │ Database Tool│ ───► │ Policy Layer │ ───► │ Allowed Operation│\n└───────┘      └──────────────┘      └──────────────┘      └──────────────────┘\n```\n\nA destructive operation simply isn’t available through the interface. The agent cannot execute it because the capability does not exist in that context.\n\nThis applies equally to dependency installation, secret access, schema migrations, and permission changes.\n\n**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.\n\nAn 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.\n\nAI 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.\n\n```\n    Make Small Change\n            │\n            ▼\n         Verify\n            │\n            ▼\n    Make Another Change\n            │\n            ▼\n         Verify\n```\n\nConsider an agent operating with a **Verification Debt** budget:\n\nUnverified Integration = +1\n\n**Verification Debt = 0**: Agent proceeds freely.\n\n**Verification Debt = 3**: Agent must verify before taking further actions.\n\n**Verification Debt = 5**: Agent is stopped completely.\n\nNot every verification step needs to carry the same execution cost. Cheap defects must be caught cheaply through a tiered inspection pipeline:\n\n```\n┌───────────────────────────────────────────┐\n│              Syntax / Parsing             │  ◄── Fast / Cheap\n├───────────────────────────────────────────┤\n│               Type Checking               │\n├───────────────────────────────────────────┤\n│              Static Analysis              │\n├───────────────────────────────────────────┤\n│                Unit Tests                 │\n├───────────────────────────────────────────┤\n│               Contract Tests              │\n├───────────────────────────────────────────┤\n│             Integration Tests             │\n├───────────────────────────────────────────┤\n│              E2E / Behavioral             │\n├───────────────────────────────────────────┤\n│          Adversarial Verification         │  ◄── Slow / Expensive\n└───────────────────────────────────────────┘\n```\n\nIf 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.\n\nIn 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).\n\nTracking process-level metrics provides visibility into the health of the system:\n\n| Metric | Target Baseline | Out-of-Control State | \n|---|---|---|\n| Compile Failures / 1,000 Changes | 0.7% | 4.8% | \n| Test Failures / 1,000 Changes | 3.1% | 8.2% | \n| Reverted Changes | 0.9% | 5.7% | \n| Security Findings | 0.03% | 0.11% | \n\nWhen metrics breach baseline thresholds, the relevant question isn’t “Is this code change bad?” but “Has the production process itself gone out of control?”\n\nWhen 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.\n\nWhen a failure occurs, the agentic loop should produce process knowledge rather than simply retrying:\n\n```\nTest Fails ──► Containment ──► Identify Abnormality ──► Root-Cause Hypothesis ──► Fix & Regression Protection\n```\n\nEvery failure should permanently update the system constraints:\n\n```\nAgent Task Fails (Stale API Docs)\n              │\n              ▼\n    Add Contract Test\n              │\n              ▼\n   Update Agent Constraint\n              │\n              ▼\n  Improved Production System\n```\n\nWhen a defect manifests in production months after deployment, tracing its origin in an agent-generated codebase requires a complete provenance chain:\n\n**Requirement → Agent Session → Model/Version → Context & Tools → Verification Logs → Human Approval → Commit**\n\nUnderstanding defect origin shifts our diagnosis from “Who wrote this code?” to “What production process generated this code, and where did that process fail?”\n\nThe conversation around AI coding agents focuses heavily on the agent itself: which model, which benchmark, which context window, which reasoning capabilities.\n\nThese 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.\n\nThe 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.\n\nThe 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.\n\nThe most important question in modern software development is no longer “How do we build software faster?”\n\nIt is: **“How do we build a system that produces software extremely fast without letting defects escape just as fast?”**", "url": "https://wpnews.pro/news/revisiting-the-toyota-production-system-tps-in-the-age-of-coding-agents", "canonical_source": "https://dev.to/remojansen/revisiting-the-toyota-production-system-tps-in-the-age-of-coding-agents-2bb5", "published_at": "2026-09-23 23:36:43+00:00", "updated_at": "2026-09-23 23:58:32.067803+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Toyota", "Toyota Production System"], "alternates": {"html": "https://wpnews.pro/news/revisiting-the-toyota-production-system-tps-in-the-age-of-coding-agents", "markdown": "https://wpnews.pro/news/revisiting-the-toyota-production-system-tps-in-the-age-of-coding-agents.md", "text": "https://wpnews.pro/news/revisiting-the-toyota-production-system-tps-in-the-age-of-coding-agents.txt", "jsonld": "https://wpnews.pro/news/revisiting-the-toyota-production-system-tps-in-the-age-of-coding-agents.jsonld"}}