Who it's for
Engineering leaders setting up roles for AI agents.
You'll be able to
Explain who does what in a factory, and why no worker checks its own work.
An agent that marks its own homework will pass itself. A factory gives each kind of worker one job, and lets another kind check it.
People, agents and scripts
| Worker | Does | Never |
|---|---|---|
| Person | Writes or approves the task. Reads the checker report. Reviews and merges. | Hands an agent a key that can publish |
| Builder agent | Writes the test first, then the code. Runs the checks itself. Reports. | Approves its own work, or edits the rules |
| Script | Runs lint, types, tests, a secret scan and a package audit. Puts merged code live. | Changes its answer: it is plain code, with no AI |
The same check command runs on a laptop, in a git hook and in CI. Different AI tools can take the builder's seat. Each one gets the same rules.
Three kinds of workers, and none of them is trusted alone.
Why none is trusted alone
Each worker has a blind spot that another one covers.
- The builder agent wrote the code. When it reviews its own work, it shares its own blind spots. Its "done" is a claim.
- Scripts behave the same every time, which is why they can block. But they cannot tell whether the code does what the spec asked.
- People judge what matters. But they cannot read every line from many agents, and they get tired.
So the agent builds, the scripts check what can be checked by rule, and the person decides with the evidence in front of them.
AI checkers: a second opinion
Between the scripts and the person sits one more helper. Four AI checkers read each change and write one report:
- spec: is each point of the spec met, missing, or added without being asked for?
- security: secrets, injection, login and permission mistakes, risky new packages.
- test: does new code have tests, and was any test deleted, weakened or skipped?
- architecture: does the change follow the team's own rules, each written as true or false?
A checker starts fresh, with no memory of how the code was written. It only reads. It never edits a file. A security finding that does not quote the code is dropped. A team can also ask a second reviewer from another model to read the same change. Models of one family tend to miss the same things.
Advice, not a gate
A checker's verdict never blocks a merge. Two reasons. A checker is a model, so it can miss a real defect and report one that is not there. And the change it reads can hold text that tries to steer it, like "ignore the rules above". Because checkers only read and block nothing, the worst result is a wrong report, and a person reads it.
Try it
Pick a recent pull request that an agent helped write. Write down who built it, what checked it, and who approved it. If the same worker appears in two of those places, you have found a step where nothing independent looked. Decide which kind of worker should take it over.