Four AI agents build my code. The most valuable one knows nothing.
How I split the work between AI agents with locked-down roles, and why the last one — the one that arrives with no context — is the one that finds what everyone else misses.
I recently finished a change to a KPI and payroll platform in eight steps. I verified every step myself, with my own eyes, before moving to the next. At the end, an agent I had told nothing about any of it found two problems I had completely missed.
This article explains how I work with AI agents, who does what, and why that last agent is worth more precisely because it knows nothing.
The rule that changes everything
The AI builds; I direct. I don't write the code: I write the instructions, hand out the work, and verify what comes back. It sounds like delegation, and it is. But it has a trap that took me a while to see: directing is not reviewing. Whoever runs the build site knows too much about it to look at it with fresh eyes.
To make the analogy work, picture a construction site with four people: an inspector, a bricklayer, a site foreman, and, at the very end, an outside surveyor. Each has a locked-down role and a list of things they are forbidden to do.
1 · The inspector writes the test before the wall exists
In software, a test is a small program that checks one single thing: "if this goes in, that must come out." The inspector writes one test, for one behavior, before the code that satisfies it exists. By definition, that test fails (it's "red"). There is no wall yet.
Its most important rule is easy to say and hard to follow: the correct answer is written by hand from the rule, never copied from what the program returns. If the inspector runs the program and writes down whatever came out as "correct," the test will approve anything and can never contradict anyone.
A real example. The work card said: "there are 15 browser tooltips to replace." That 15 came from the system's own counter. Counting by hand, there were 17: the counter had two holes and was missing two. Had we trusted the program, the job would have finished "green" with two tooltips still alive.
Forbidden: writing solution code, touching any other test, and inventing business rules. If the expected value isn't on the card, it stops and asks.
2 · The bricklayer builds that wall, and only that one
The bricklayer receives the red test and writes the minimum code that turns it green. Nothing speculative, no "while I'm at it." Only the files it has been authorized to touch.
It is forbidden to touch the test. If it thinks the test is wrong, it says so and justifies it; it doesn't quietly rewrite it or mark it as "skipped." It doesn't fix other things along the way either, and it doesn't add anything nobody asked for.
What I liked most about this role I saw when I was the one who got it wrong. In one instruction I told it where to put a certain technical detail, and I was mistaken. The bricklayer neither obeyed nor changed it silently: it stopped, explained why my instruction was incorrect, and reported it. I fixed the following instructions. An agent that pushes back with good reason is worth more than one that obeys.
3 · The foreman doesn't trust the report
That's me. The foreman writes neither code nor tests: it hands out the assignments and verifies every delivery independently. It's not enough for the inspector to say "the test fails": I run it myself and read why it fails. It's not enough for the bricklayer to say "it passes now": I run it myself.
And there's one check I consider the most important of all: the test of the test. Once everything is green, I remove only the bricklayer's fix and confirm the test goes red again. If it stays green without the fix, the test was useless and has to be redone. In this case, removing the fix turned the test red listing the 17 tooltips — not one more, not one less.
The inspector → bricklayer → verification cycle repeated eight times, from small to large. On the last step, when running all the platform's tests — not just the new one — nine old tests broke: they were looking up elements by the very attribute we were removing. The bricklayer stopped and reported it instead of tweaking them to pass. That is exactly the behavior you want: a broken test is a question, not an obstacle.
At the end, I counted browser tooltips on the running platform: 186 before, 0 after. Forty-six screenshots, light and dark. Everything verified.
And still, things got past me.
4 · The outside surveyor: arrives knowing nothing
The reviewer is an agent in a clean session: it has no access to the conversation where everything was planned and built. It receives exactly two things: the original card (what was asked) and the final result (what changed). It is read-only: it can't fix anything, only report.
Its instructions begin like this:
You arrive without the context of the build and look at the
change as if it were someone else's. That ignorance is the
value: don't accept anything just because "it makes sense."
It checks seven angles, always the same ones:
- Did it do what the card asked, and only that? Anything extra gets flagged.
- Did it stay where it belonged? Some areas of the system are off-limits. Touching one is a blocker.
- Does the test actually work? Would it fail without this fix? It says so explicitly.
- Did it invent business rules? Thresholds, texts, or criteria the card didn't bring.
- Does it hide any failure? Errors swallowed in silence, defaults that paper over a real gap.
- Does the interface follow the standards? Components, accessibility, keyboard, contrast.
- Does every touched screen answer its seven states? Empty, loading, error, no permission, one item, many items, very long text.
It reports from most serious to least, separating blocker from suggestion. And if it finds nothing in an angle, it says so: "I found nothing here" is information; silence is not.
What it found
Eight findings. Two blockers. Both fixed.
| Finding | What was done |
|---|---|
| Blocker. There was a folder of browser tests — the ones that simulate a person using the platform — still looking up elements by the removed attribute. In eight steps nobody had opened it. | Fixed and verified by actually running those tests, not by reasoning about them. |
| Blocker. The written plan said twice "nothing becomes keyboard-focusable," and the code made three cells focusable. | The code was right: the decision changed mid-way, with new information, and the plan wasn't updated. The plan was corrected. |
| "No screen-reader label is lost" was inaccurate: descriptions are lost, not names, in four places. | Text corrected and declared in the delivery as a real loss. |
| On the heaviest screen, tooltips had no width cap. | Fixed and measured. |
| The plan required measuring performance on the screen with the most elements, and there was no measurement. | Measured, three runs. Opening a week goes from 152 ms to 265 ms; nothing else moves. |
| The counter still has three theoretical holes. | Declared, not fixed: none exists in the system today. Closing them is another card. |
None of the findings was resolved by touching a test to make it pass. None was dismissed without a reason.
Why I can't be the reviewer
Look at the first blocker. I verified eight steps, ran every test twice, removed the fix to see it fail again, took 46 screenshots. And I never opened that folder. Not because I was careless, but because I knew where to look, and that's why I didn't look where I didn't know.
That's the problem with context. Whoever planned and directed a build reviews with a map in their head: they check the places the map marks. The surveyor has no map. It looks at the whole result, with the same seven questions as always, and finds what the map didn't include.
The second blocker is the same lesson from the other side: the plan and the code contradicted each other, and I didn't see it because I knew why. The decision had changed mid-way, for good reason, and in my head the contradiction didn't exist. For someone who only reads the paper and the result, it did.
In the previous article I wrote: automate the proposal, never the approval. This is the other half: whoever approves cannot be whoever built, not even when the builder is the AI and the director is you. A reviewer with no context is not a luxury. It's the only way anyone looks with fresh eyes.
Tools: Claude Code with file-defined agents (one per role, with restricted tools: the reviewer can only read). The method comes from a decades-old practice — the failing test first — applied to agents instead of people.