Origins
Three lineages, one factory floor.
T2D2 doesn't sit in one category. It sits at the intersection of three lineages that mostly haven't talked to each other — a century-old quality tradition, a twenty-five-year software methodology tradition, and a two-year-old agentic-coding problem that's still naming itself.
Three lineages
Where the discipline inherits from.
Quality & lean manufacturing
Statistical process control — the idea that manufacturing variation can be measured and controlled with data, not just inspected after the fact.
Took Shewhart's statistical thinking and built a management philosophy around it. The 14 Points. Plan-Do-Check-Act. More influential in postwar Japan than in his home country at first.
Taiichi Ohno and Shigeo Shingo at Toyota. Kaizen, Jidoka, Kanban, and — the direct ancestor of this discipline's name — poka-yoke: mistake-proofing a process by its shape, not by inspecting output afterward.
Poppendieck & Poppendieck's translation of TPS principles into software engineering. The direct bridge to the next lineage.
Software methodology
Kent Beck. The origin of Test-Driven Development — write the failing test before the code that makes it pass. T2D2's own name is a direct extension.
Seventeen authors including Beck. A free, freely-published document with no certification attached at origin. The reference case for "the free document earns trust; what gets built on it later is a separate question."
DevOps coined by Patrick Debois. SRE made public via O'Reilly's freely-available book. Same "publish the philosophy freely" pattern.
Declare desired state, diff against observed reality, break the build on drift. The nearest pre-AI precedent for what Fidelity Check does at the whole-codebase level rather than just the API boundary.
The agentic-coding moment
From autocomplete (GitHub Copilot, 2021) to increasingly autonomous, conversational code generation. The distribution channel changed; the review workflow did not.
Coined by Andrej Karpathy. Directing an AI by intent rather than authoring code line by line. Collins Dictionary's Word of the Year for 2025. Originally scoped to low-stakes prototyping; the term broadened well beyond that.
As more code gets generated this way, on larger codebases, the gap between what was asked for and what got built grows — silently. The traditional check (a human reading a diff) doesn't scale to the volume or velocity of agent-generated change.
The failure mode gets a name. ARCTIC, Aviator Verify, Tricentis AI Workspace and a growing set of tools begin addressing it — at the diff layer, after a change is already made.
The organic moment
What actually produced the discipline.
T2D2 started from a narrow, practical irritation: videocoding works fine on a small script and falls apart on a large, complex codebase. Not because the model gets dumber — because nothing in the workflow tells it, or you, when the shape of what's being built has quietly drifted from what was asked for.
The gap doesn't announce itself. It shows up weeks later as a bug nobody can explain, or never shows up at all and just becomes technical debt with no paper trail.
The instinct that follows from that is old, not new — it's Deming's, from a Toyota factory floor seventy years before any of this: catch the mistake by the shape of the process, not by inspecting the output afterward. Applying that to code meant asking what the equivalent of a factory's physical jig or gauge would be for software. The answer turned out to be a graph — a structural map of what the code actually looks like, that could exist before the code does, be checked against the code once it's built, and keep being checked after it ships, against what the system actually does at runtime.
A second, personal influence shaped how that graph gets used day to day, borrowed from Heinlein's Waldo — a story about a man who builds tools that extend what he can physically do, and whose invented word for those tools became a real engineering term. The practical version of that idea here: build tools to build tools, and — the less obvious part — give an agent its constraints before its instructions, not after, and make it show its reasoning before it acts. That ordering, tried repeatedly, produced better results than the more natural instinct of stating the goal first and hoping the constraints get respected.
Honest positioning
Where Poka-yoke actually sits.
At the point where all three lineages meet. The quality tradition supplies the philosophy (mistake-proof by design, don't inspect in after the fact — literally the product's name). The software-methodology tradition supplies the form (a free, open discipline with a commercial reference tool, the way Agile/Jira and IaC/Terraform split). The agentic-coding moment supplies the urgency.
Not "nothing else does this." Narrower and more defensible: nothing confirmed so far combines a compiler-accurate structural graph, live telemetry correlation, and a pre-code comprehension ceremony in one loop. Intent and Kiro are the two closest strategic matches found; the open question with both is mechanism, not intent — whether they work from a diffable structural graph or a looser spec document.
Further reading.
- Shewhart, W. A. (1931). Economic Control of Quality of Manufactured Product.
- Deming, W. E. (1986). Out of the Crisis. MIT Press.
- Ohno, T. (1978). Toyota Production System.
- Shingo, S. (1986). Zero Quality Control: Source Inspection and the Poka-yoke System.
- Beck, K. (1999). Extreme Programming Explained.
- Poppendieck, M. & Poppendieck, T. (2003). Lean Software Development.
- Heinlein, R. A. (1942). Waldo.
- Karpathy, A. (2025). Remarks introducing "vibe coding."