The Builder Does Not Inspect: Red Team, Blue Team, and AI Agents on a Factory Tool

There was no dramatic moment. No agent deleted production, no board came off the line mirrored. The scale just crept up on me. One week I was reading every change my AI agents made to Assembly Hub, the manufacturing tool I run our SMT line on. A few months later there were four hundred merged pull requests, and I realised I had been skimming for a while and calling it review.

Back in May I wrote about giving the agents a constitution: split the Architect who plans from the Worker who builds, and never let one agent do both. That settled who decides what gets built. It did nothing about who decides whether it was built right. Writing the code stopped being the bottleneck long ago. Knowing whether the code is right is the bottleneck, and it does not scale with typing speed.

The oldest rule on the floor

On a PCBA line we solved this problem decades ago, and the solution is almost insultingly simple: the person who builds the part does not inspect it. The placement machine does not grade its own placements; AOI does. AOI does not get the final word either; the flying prober checks the electrical truth underneath. Every stage assumes the stage before it is lying a little.

My agents were doing the opposite. The same session that wrote a change also wrote its tests, ran them, watched them pass and reported success. That is not verification. It is a student marking their own exam, and then being surprised by the average.

So I split the work into three teams. Green builds, from a written plan, and is locked to the files that plan names. Red attacks: first the plan, before a line of code exists, then the finished change. Blue repairs whatever Red finds. I sit above all three as referee.

A finding you cannot argue with

The rule that made it work is not the team names. It is this: when Red finds a defect, it has to prove it with a failing test. The test goes into a quarantined folder where it cannot break the normal build, and it stays there, failing, until Blue fixes the code. Blue is not allowed to delete that test, skip it, or loosen it until it passes. When the fix lands, the test graduates into the permanent suite and guards that spot forever.

This matters because agents are very persuasive. Ask one whether a finding is real and you will get a thoughtful, well-structured paragraph explaining why it isn't. A failing test does not care how well the argument is written. Either the code behaves or it doesn't.

Here is the one that convinced me. A plan came through to change how placement files are exported: the coordinates the pick-and-place machine uses to put every part on the board. The plan relied on two code paths that read the same placement table. Red wrote a test showing that the two paths disagreed on the sign of the X coordinate for bottom-side parts. In plain terms, one of them would have mirrored every component on the bottom of the board.

That was caught at the planning stage. No code had been written and no board had been built. On the floor, a bug like that is a scrapped panel and a very quiet conversation with the customer.

What it costs

I would be lying if I sold this as free. Assembly Hub now has more test code than application code, roughly 156,000 lines against 102,000. There are fifty Red reports in the repository and forty-seven Blue reports answering them. I spent more of my evenings refereeing arguments between agents than I ever spent writing code, and I capped the loop at two rounds, because an attacker and a defender will happily argue until the heat death of the universe.

There is also a subtler cost. Red can only attack what it can see. It will find a sign error in coordinate maths all day long. It cannot know that our Seica prober writes each re-probe to a separate file, so a board that passed on its second try looks like a failure unless you roll the files up by the test time inside them. It cannot know that a Class 2 board can live with a cosmetic defect a Class 3 board cannot. That knowledge came from four years of standing next to the machines, and none of the agents had it.

The engineer still matters more

Which brings me to where I have landed. The agents typed the code, all hundred thousand lines of it. But every decision that mattered was mine: which machine format is authoritative, which failure mode is worth a test, when a number is good enough to ship to a production line. The Red/Blue split did not replace that judgement. It freed up the time for it, by making sure that when I did look, I was looking at the arguments that survived a real attack rather than at everything.

The factory taught me that quality is a system, not a person trying hard. It turns out the same is true when the workers are language models. Build the system so that no one grades their own work, make the evidence executable, and keep the engineer where the engineer belongs: in the loop, holding the pen on the decisions that the machine cannot see.

If you want to see what that system produced, the full build is on the Assembly Hub project page: 300+ production jobs, about half the programming time, and a test suite that no agent was allowed to weaken.