Manufacturing discipline, not prompt engineering: poka-yoke, MSA, FMEA for AI code
Dr. Aaron Hutzler · 07 August 2026 · 14 min
The AI software world talks like a factory. , , quality metrics, occasionally six sigma. The vocabulary of manufacturing quality has arrived in the tooling. The discipline behind it has not.
A real factory does not release a machine tool for series production because the operator says the part looks good. It runs a gauge and process capability study on standardized reference parts and measures whether the machine holds the tolerances that matter, under load. For an AI code builder, such studies are hard to find. People rely on a handful of as the quality proof.
Green tests are no seal of quality for stochastic code and engineering is why the industry keeps hoping they are. You cannot talk a stochastic model into reliability. Ninety-five percent right is fine for a chatbot and unacceptable for a build. The fix is process control, the same move a quality engineer already knows: you qualify a process, monitor it and bound it. Taken seriously rather than as a metaphor, process control yields the following disciplines. Every one of them is running code, not slideware and every claim carries its evidence.
1. Poka-yoke: hard blocks and soft metrics
Classic poka-yoke, the Japanese method of mistake-proofing, keeps a faulty part from ever reaching the next station [1]. The machine itself makes the wrong move physically impossible, instead of trusting the operator to notice. For AI code that means splitting every rule into two strictly separated classes. The two behave completely differently once an stands on the other side of them:
- Truth-valued rules (hard gates). Conditions with an unambiguous truth value. Does this import cross an architecture boundary, yes or no. Does a named secret appear in the , yes or no. A violation blocks the build, unconditionally. There is no version of the rule an agent can satisfy halfway.
- Shape proxies (soft metrics). Function length, nesting depth and their relatives are monitored continuously and never block the build on their own. They describe the shape of the code, not its correctness. Shape is exactly the property an agent can fake.
Why this split matters is itself a measured result and a surprising one: the two classes are not interchangeable substitutes for each other, they fail in opposite directions when treated as one.
1.1 The announcement effect
We ran preregistered pilots: three runs per arm, one identical task each time. Each pilot tested where in the rule pipeline the gaming incentive acts. Announcing a blocking shape threshold before the agent drafts produced the gaming signature in all three runs. The gate never even fired. The agent complied preemptively: it wrote code shaped to pass the number, not code shaped to be correct. Revealing the same rule only after a first draft produced no gaming in any of the three runs. The gate actually fired then and forced repair. The difference is not the threshold. It is whether the agent could see the target before committing to an approach. A truth-valued rule works differently. It is much harder to game: the condition must actually be met. Announcing it was clean in every run. There is no shape to optimize toward, only a condition to meet.
This is at work. The economist Charles Goodhart observed in 1975, writing on British monetary policy, that a statistical regularity collapses once it is used as a control target [2]. The famous short form appears in a 1997 paper by the anthropologist Marilyn Strathern on metrics in the British university system: when a measure becomes a target, it ceases to be a good measure [3]. Half a century later the same mechanism applies to a machine: our pilots show exactly that split for shape proxies in AI code. The shape metric was usable until the agent knew it was the target.
A note on scale, stated deliberately: our pilots show this effect consistently across three experimental designs at pilot scale. We say "our pilots show", not "proven". Figure 1 shows all three arms and their runs.
Figure 1: Three pilot arms, three runs each. Announcing the shape threshold before the draft produced gaming in every run; revealing it after the draft produced none. The truth-valued rule stayed clean even when announced.
2. A failure-mode review for every diff
Manufacturing has a standing method for this. It is called failure mode and effects analysis, FMEA for short: review a change against everything it could newly break, not against what it was meant to add. The method goes back to a military procedure of 1949 [4] and is an international standard today [5]. A car-parts supplier runs it on every design change before tooling starts. A small change to one part routinely breaks an assumption three stations downstream. Nobody had to think about that assumption before. For AI-generated code the same discipline applies to every diff. A diff is one code change, submitted by a developer or by an agent. Each diff names the failure modes it touches: lost context from a long input, a rule gamed around instead of satisfied, an invented reference to a function that does not exist. Each named risk carries three things in one shared register: its current control, meaning what already catches it if it happens; its evidence, meaning where that control was actually tested; and a note on what risk remains even with the control in place.
A diff that touches no named risk carries no extra review. That matters as much as the opposite case. Reviewers who check everything with equal weight stop checking anything carefully. A diff that does touch a named risk gets a mitigation note and a test aimed at exactly that risk, not a generic re-run of the whole suite. The register grows only when a new failure mode is actually found in production. It never grows speculatively. It stays a list of things that happened, not a list of things that might. Figure 2 shows the register and how a diff passes through it.
Figure 2: The register in action. Every named risk carries its control, its evidence and its residual risk in one row; a diff either touches a named risk or passes without extra review.
3. Gauge study before you measure
Industrial metrology has a standing rule, the measurement system analysis [6]: before trusting an instrument, prove that the instrument itself measures correctly. A caliper that is out by half a millimetre makes every part it checks look fine or look defective at random. Nobody would trust its readings without checking the caliper first. The same logic applies to an automated check or a model asked to judge code. Teams skip this step almost everywhere. A check looks authoritative simply for running in .
To qualify our own checks we fault-injected them: known-wrong answers were fed in on purpose. The check caught 12 of 12 on independent re-validation, meaning a second run by someone who did not build the check reproduced the same result. And we killed the fashionable instrument by its own preregistered criteria. judges, asked to referee code quality pairwise, produced 100% unanimous verdicts that turned out to be position bias, not judgment: they chose the first-shown option in 32 of 36 verdicts regardless of which answer was actually better. Debiasing across both orders collapsed their consistency to null. A negative result, published in full. It is the strongest reason to trust our positive numbers. The same fault-injection method that cleared our own checks also exposed the judge that failed. Figure 3 shows both results side by side.
Figure 3: Fault injection caught every known-wrong answer and qualified the check. The same method exposed the judge: 32 of 36 verdicts followed the first-shown option and debiasing collapsed its consistency to null.
4. Design of experiments: a test plan, not a hunch
Design of experiments plans factor variation in advance instead of tweaking a single setting and hoping the change was the one that mattered [7]. Change one knob, observe a result, change another knob later. Any interaction between the two stays invisible for as long as they are never varied together. A planned run varies them on purpose, in combinations chosen in advance. An interaction then shows up as a pattern, not as noise.
The announcement-effect pilot above is one instance of the same discipline, even though it varied only a single factor. It held everything else fixed on purpose. It changed only the point where a rule became visible to the agent. It measured the outcome across three matched runs. The result could be attributed to that one change alone. The same method scales to several factors at once: model choice, prompt structure, and context length, varied together in a planned run instead of one at a time. Read off the combination that holds across the whole plan, not the one setting that happened to look good on the run in front of you. Figure 4 shows the difference between the two approaches.
Figure 4: One factor at a time leaves interactions invisible. A full factorial design covers every combination and makes them visible.
5. Statistical process control: why the classic chart fails here
Function length and cyclomatic complexity, the shape proxies from section 1, need a trend, not a single threshold. A metric that only trips a hard number tells you nothing about whether it is getting worse over time. The obvious instinct is a classic control chart [8]: freeze three-sigma limits from an early batch of runs and flag anything outside them from then on. The software world itself has run control charts on its processes for decades [9]. That instinct is wrong for AI-generated code. It is wrong for a specific, checkable reason.
Classical control charts assume a stable process with only common-cause noise, meaning small random variation around one fixed target. An AI pipeline breaks that assumption twice over. The same specification produces a different implementation on every seed. Run-to-run variation is real process variation, not measurement noise. A chart built to flag noise ends up flagging normal behavior instead. And the data are non-stationary and thin. At 25 runs, a capability index's own uncertainty band can span roughly half its value. A single frozen limit computed from that sample is itself barely more than a guess dressed up as a number.
Control: bound the metric with quantile bootstrap intervals instead of frozen normal limits. The acceptable range is estimated from the actual spread of the data, not assumed in advance. Run drift charts as an advisory signal only. A threshold turns blocking once its own uncertainty is narrow enough to trust, not at a fixed run count. A chart with too little data behind it stays a hint on a dashboard, not a gate that can stop a build on noise. Figure 5 shows the frozen chart failing on exactly this kind of data and the bootstrap band that replaces it.
Figure 5: The same 25 runs, two conclusions. Frozen limits flag normal seed-to-seed variation as alarms; the bootstrap band is estimated from the actual spread and stays advisory until it narrows.
6. Four supporting records, one build
Beyond the checks themselves, four record-keeping habits move AI generation from the hobby bench into controlled production. None of them catches a defect on its own. Each one makes a defect visible or a claim checkable after the fact. A hobby-bench setup never keeps that:
- An escaped-defect log. Every defect that reached production despite the checks gets one line. The line records what the defect was, the check that should have caught it and what changed in the check afterward. Without this, the same defect class reappears every few months and each time looks new.
- A real cost per defect. The realized cost of a defect that reached production, tracked per change over a shared run id, not an estimate. A defect that costs ten minutes to fix and one that costs a day of incident response are not the same event. Treating them the same hides where the actual budget for quality work should go.
- A named owner per check. Every check carries a named owner and a written reaction plan for what happens when it fires. A check nobody owns degrades quietly: it keeps running, it stops meaning anything. Nobody notices until it has been silently ignored for months.
- A frozen design before the data exists. Every experiment freezes its design, its metric and its threshold by hash before any data comes in; thresholds picked after seeing the result are not thresholds, they are a story told about a number that already existed. This discipline holds across all eleven entries of our experiment register.
7. Key takeaway: one manufacturing tool per build problem
Table 1: Where each tool fits and what it catches.
| # | Tool | What it catches | Apply it |
|---|---|---|---|
| 1 | Poka-yoke | A gate an agent can game by knowing it in advance | Split rules into hard, unconditional gates and soft, non-blocking metrics; reveal a threshold only after a first draft exists |
| 2 | Failure-mode review | A change that introduces a new failure mode unreviewed | Name the failure modes a diff touches, log control, evidence and residual risk in a shared register |
| 3 | Gauge study (MSA) | A check or judge that looks reliable but is not measuring the right thing | Fault-inject the check itself before trusting its verdicts |
| 4 | Design of experiments | A configuration tuned by guesswork, one setting at a time | Vary several factors together in one planned run, read off the setting that holds |
| 5 | Statistical process control | A frozen control chart that is confidently wrong on thin, seed-variable data | Bound metrics with bootstrap intervals, run drift charts as advisory only |
| 6 | Escaped-defect log, real cost, named owner, frozen design | Defects, cost and thresholds that are not tracked anywhere | Log every escaped defect, its cost and a named owner per check |
8. Two honest boundaries
Engineering honesty includes naming the limits:
- Bench against live production. Capability numbers live on the bench with standard workpieces. We deliberately do not compute capability indices over live, one-off production.
- Proprietary thresholds. We publish the principles, data and methods in full; the concrete gate configuration, thresholds and security specifics stay internal for now.
9. Conclusion: AI development needs quality engineers
Six sigma was a discipline that made unreliable machines produce reliable parts. The newest machine on the floor is an AI code builder and it needs the same treatment.
A better prompt does not fix an unreliable machine. No version of prompt engineering was ever built to; poka-yoke separates the gate an agent cannot argue past from the metric that only observes. The failure-mode review catches a new failure mode before it ships. The gauge study tests the judge, not just the code the judge scores. Design of experiments finds a setting a single guess would miss. Statistical process control reads a drift chart without pretending thin, seed-variable data holds a frozen limit. None of the six replaces the others. None of them is optional once an agent writes code unsupervised.
Prompt engineering is dead. AI development needs quality engineers.
10. Sources
[1] S. Shingo, "Zero Quality Control: Source Inspection and the Poka-Yoke System", Productivity Press, 1986.
[2] C. A. E. Goodhart, "Problems of Monetary Management: The UK Experience", Papers in Monetary Economics, vol. I, Reserve Bank of Australia, 1975.
[3] M. Strathern, "'Improving ratings': audit in the British University system", European Review, vol. 5, no. 3, 1997, pp. 305-321.
[4] United States Department of Defense, "Procedures for Performing a Failure Mode, Effects and Criticality Analysis", MIL-P-1629, 1949.
[5] IEC 60812:2018, "Failure modes and effects analysis (FMEA and FMECA)", International Electrotechnical Commission, 2018.
[6] Automotive Industry Action Group (AIAG), "Measurement Systems Analysis: Reference Manual", 4th edition, 2010.
[7] R. A. Fisher, "The Design of Experiments", Oliver and Boyd, 1935.
[8] W. A. Shewhart, "Economic Control of Quality of Manufactured Product", D. Van Nostrand, 1931.
[9] W. A. Florac and A. D. Carleton, "Measuring the Software Process: Statistical Process Control for Software Process Improvement", Addison-Wesley, 1999.