This is part of an ongoing series about building Gomi Bunrui, an AI-powered waste classification app for Japan, using AI tools at every layer of the stack. Start with Part 1.


Originally published on Substack

In the rapidly evolving landscape of AI-assisted engineering, a subtle but dangerous failure mode has emerged: the erosion of critical oversight. During the development of Gomi Bunrui, I observed a recurring pattern of “silent defects” that bypassed manual review not because the AI was inherently incapable, but because the human operator accepted the output too quickly. The AI’s confidence, coupled with passing tests, created a false sense of security that masked deep-seated logic errors.

To address this, I looked toward a framework developed over a century ago in a Japanese textile factory. The principle of Jidoka offers a sophisticated mental model for modern developers: a system where machines handle detection, while humans handle judgment.

The Industrial Roots of Quality: Understanding Andon

In the Toyota Production System, “Andon” refers to a visual signal system used to indicate the real-time status of a production line. Far from being a mere status light, the Andon system is a cultural imperative that empowers every worker to halt production the moment a defect is identified. This “Andon Cord” ensures that quality is built into the process rather than inspected at the end.

Andon Cord

Jidoka: The Human Inside the Machine

The concept of 自働化 (jidoka) was pioneered by Sakichi Toyoda. Disturbed by the wasted labor and ruined fabric caused by broken threads in manual looms, Toyoda invented a machine that detected abnormalities and stopped automatically.

The brilliance of Jidoka lies in its linguistic modification. Toyoda replaced the standard character for “movement” (動) with “work” (働), which includes the radical for “human” (人). This “automation with a human touch” suggests that true productivity is not the absence of humans, but the elevation of human judgment to oversee automated processes.

In AI-assisted development, this distinction is paramount. The AI handles the “movement”(the generation of code), while the developer handles the “work”(the essential judgment that confirms the code’s validity).

Strategic Implementation: Jidoka in Practice

Applying Jidoka to a modern software stack requires a shift from “inspection” to “specification.”

Building Quality In: Constraint-Driven Generation

Jidoka’s core insight is that quality must be an inherent part of the production process. In my workflow, this was achieved through the Kiro Spec Workflow. By defining requirements in EARS format and establishing 60+ correctness properties before code generation, I created a “tight solution space.” This ensured the AI was weaving within a precisely configured loom, significantly reducing the surface area for logic defects.

Furthermore, the Bedrock System Prompts served as the ultimate loom setup. By embedding municipality-specific terminology (可燃ごみ vs. 燃えるごみ) and explicit rejection conditions directly into the prompt, the quality of the classification was determined long before the model processed an image.

Pulling the Andon Cord: Halting the Line

The Andon Cord represents the psychological safety to stop. In AI-assisted development, I’ve established three “Red Light” conditions that mandate an immediate halt:

When to Pull the Andon Cord

  1. The Explainability Gap: When the AI generates a solution (e.g., Cognito token rotation) that is functional but conceptually opaque to the developer.
  2. The Pattern Fallacy: When the AI follows a plausible pattern that contradicts specific domain requirements (e.g., Osaka’s unique spray can classification).
  3. The Coverage Illusion: When generated tests achieve 100% coverage but fail to test edge-case logic or state-change properties.

Pulling the cord is often viewed as a loss of momentum, but research into the “Cost of Fixing Defects” consistently shows that identifying a defect during the design or implementation phase is exponentially cheaper than addressing it in production.

Cost of Fixing Defects

The Four-Step Response Protocol

Jidoka defines a rigorous process for handling abnormalities: Detect, Stop, Fix, and Investigate.

In the Gomi Bunrui build, I encountered a defect where the classification model ignored visible recycling symbols. Following the protocol:

  1. Detect: Accuracy dropped on branded packaging.
  2. Stop: Halted feature development for a root-cause analysis.
  3. Fix: Introduced “Chain of Thought” reasoning to the output schema.
  4. Investigate: Realized the prompt lacked identification hierarchy. The fix wasn’t a better model, but a better process for the model to follow.

Addressing the Skill Erosion Paradox

A subtle trap of automation is that it can erode the very skills required to oversee it. If a developer cannot write the logic without AI, they lack the mental model required to review it with AI. To combat this, I maintain a practice of “Manual Sprints” for critical logic: security integrations, domain models, and architectural primitives. The oversight skill and the implementation skill are effectively the same skill.

Strategic Takeaways: What Can You Do Now?

Transitioning to a Jidoka-based workflow requires moving beyond “just using AI” and toward “strategic oversight.” Use the implementation ladder below to audit your current maturity:

Implementation Ladder

Ultimately, Sakichi Toyoda’s 19th-century insight remains a design specification for the AI age: The most effective automation is that which makes human judgment more essential, not less.

Glossary

Jidoka (自働化): “Automation with a human touch.” A principle where machines detect abnormalities and stop automatically, while humans provide the ultimate judgment.

Andon Cord: A physical or mental mechanism used to stop production to prevent defects from moving downstream.

Essential Complexity: Complexity inherent to the problem domain that requires human decision-making (Brooks, 1987).

Accidental Complexity: Complexity introduced by the implementation approach, which can be mitigated through better design and tooling (Brooks, 1987).


References

  1. Ohno, Taiichi. “Toyota Production System: Beyond Large-Scale Production.” Productivity Press, 1988.
  2. Liker, Jeffrey K. “The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer.” McGraw-Hill, 2021.
  3. Brooks, Frederick P. Jr. “No Silver Bullet: Essence and Accident in Software Engineering.” IEEE Computer, 1987.
  4. Evans, Eric. “Domain-Driven Design: Tackling Complexity in the Heart of Software.” Addison-Wesley, 2003.
  5. NIST. “The Economic Impacts of Inadequate Infrastructure for Software Testing.” Planning Report 02-3, 2002.

This post is part of a series about building with AI tools. Read Part 1: I Used 8 AI Tools to Build and Ship a Product Solo for the full picture.

Follow the series: Substack · Dev.to · LinkedIn · X