I should say this at the start. I am a Chartered Engineer and was once an ISO 9000 Lead Auditor, and I am about to argue that AI needs more people like me. You are entitled to discount that. My answer is that I spent the first half of my career in precision engineering and rail, where a claim had to be evidenced before anyone relied on it, and I recognise what I see happening in AI. It is not new. It has a name.
The industry is rediscovering what manufacturing learned
Spend a week reading AI engineering blogs and you will meet a vocabulary that sounds new:
- Evals and benchmarks. Quality engineering calls this inspection and appraisal.
- Human in the loop. Final inspection. Deming's third point told industry to "cease dependence on inspection to achieve quality" in the 1980s.
- Guardrails. Mistake-proofing. Toyota called it poka-yoke.
- Reward hacking and benchmark gaming. Goodhart's law: when a measure becomes a target, it stops being a good measure.
- The model reviewing its own work. A failure of auditor independence. ISO 19011 has a section on it.
- Canary releases and staged roll-outs. Pilot runs and first-article inspection.
- Drift monitoring. Statistical process control, which Walter Shewhart developed in the 1920s.
- Prompt and harness changes. Management of change and configuration control.
- Post-mortems. Root-cause analysis and corrective action: 8D, CAPA, the five whys.
- Provenance and lineage. Traceability.
Every one of these is a real problem, and the people working on them are doing serious work. But each is being worked out again from first principles, in public, often by people who have never been told that a mature discipline already solved it, measured it and wrote it down.
That matters because the original discipline did not just name these things. It learned, at great cost, what works and what does not.
The evidence that something is going wrong
AI has made writing code dramatically faster. It has not yet made getting good work into production faster, and the industry's own measurements show it.
Speed up, stability down. Google's DORA research programme found in its 2024 report that for every 25% increase in AI adoption, delivery stability fell by an estimated 7.2% and throughput by 1.5%. Its 2025 report found the throughput penalty had gone. The stability problem had not. Writing code was never the bottleneck. Getting good code into production is.
Feeling faster is not being faster. In a July 2025 study by METR, experienced open-source developers took 19% longer to complete real tasks when using AI tools. Afterwards, they believed AI had made them about 20% faster. Deming would not have been surprised. Without measurement, perception is all you have, and perception is unreliable.
Passing the test is not passing the customer. In VentureBeat's June 2026 survey, half of enterprises had shipped an AI feature that passed their internal evaluations and then failed in front of a customer. Only one in twenty fully trusted those evaluations.
The fixes come after the failure. In July 2024 a faulty content update from CrowdStrike passed its validator and went out to every customer at once. Microsoft estimated 8.5 million Windows devices were affected. The fixes the company then committed to included staged release rings with canaries, more testing, and an outside review of its quality processes. That is textbook practice. The lesson is not that nobody knew. It is that the known practice was applied after the failure instead of before it.
What the discipline actually teaches
Quality engineering is not inspection. That is the first and most important thing it learned. You cannot inspect quality into a product at the end of the line. You build it into the process, so that defects are prevented or caught at the source.
Its core lessons translate directly to AI:
- Build it in, don't bolt it on. Reliability comes from how the system is designed and run, not from a test at the end.
- Improve at the constraint. Speeding up anything other than the bottleneck does not speed up the whole. (Goldratt.)
- Don't react to noise. Changing a process in response to results that sit inside its normal variation makes it worse. (Shewhart and Deming.)
- Hold the gains. An improvement without a plan to keep it will decay. (Juran.)
- Control change. A change to a running system goes through a control the person making the change cannot bypass.
- Never let the work mark itself. The one who does the work cannot be the one who accepts it.
- Count the cost of poor quality. Rework, failure and lost trust have a price. Prevention is cheaper. (Juran, Feigenbaum, Crosby.)
Each of these will get its own article in this series, with current examples from across the AI industry.
This has happened before, and it worked
Software has done this kind of crossover before.
DevOps brought operations expertise into development teams. Google's Site Reliability Engineering put people who understood running systems inside the teams that built them. DevSecOps did the same for security. Concurrent engineering did it in manufacturing design decades earlier. Each time, a discipline that had been treated as a gate at the end became part of the design from the start, and each time both sides learned something.
The quality world also solved a problem AI has not reached yet: trust across borders. Under the ILAC and IAF mutual recognition arrangements, a test report from an accredited laboratory in one member economy is accepted in the others, so a product is not tested again at every border. China's accreditation body, CNAS, and India's, NABL, have both been signatories since 2000. The recognition works because every signatory meets the same standard for how a result is produced and checked, not because they trust each other's goodwill.
The international standards world is now at the AI table. China holds several convenor posts on the ISO and IEC committee writing AI standards. When India hosted that committee's plenary in New Delhi, more than 350 experts from 70 countries attended. That committee is working with ISO's conformity-assessment committee on how schemes for checking AI systems should be built. It is quality engineering's own vocabulary, applied to AI.
Quality engineering is the next crossover.
The call
I am not arguing for a return to human inspection. AI produces work far faster than people can check it, and that will not change. The answer to machine-speed output is not more inspectors. It is better systems: built so that defects are caught at the source, so that "done" has a clear and checkable meaning, so that no change is accepted by the one who made it, and so that gains are held.
That is what traditionally trained quality engineers know how to design. So my call has two halves.
To AI and software teams: bring quality engineers in as co-designers of the system, not as reviewers at the end.
To quality engineers: AI systems do not behave like production lines. They vary, they learn, they change. The tools will need adapting, and you will learn as much as you teach. That is why this is a team effort, not a transplant.
The discipline exists. It has decades of evidence behind it. We do not need to reinvent it. We need to bring it in.