I do not generally ask one AI agent to build something and then ask the same agent whether it has done a good job.
That feels a little like asking somebody to mark their own exam.
They may be perfectly honest. They may even be right. But they know what they meant to do, and intention has a habit of making defects harder to see.
So, on work that is complicated enough to justify it, I split the job.
I have a builder.
And I have a critic.
The names are deliberately boring because the roles are boring.
The builder builds.
The critic tries to prove the work deserves to be accepted.
That small separation has changed the way I use AI more than almost any clever prompting technique.
The builder's context is both its advantage and its weakness
The builder usually knows the project best.
It has the brief. It has read the implementation history. It knows why a compromise was made, which approach failed and how the current version ended up looking the way it does.
That context is extremely useful while producing the work.
It is less obviously useful when judging the finished result.
Humans have the same problem. If I have spent hours building something, I see the intended system as well as the actual one. I know where the button is supposed to go, so I can unconsciously read the interface as though it gets there. I remember why the test exists, so I am inclined to assume it proves the thing I intended it to prove.
The builder carries that same narrative.
It knows the story of the implementation.
The critic should care about the evidence.
I do not want a second builder
This distinction matters because “critic” can very quickly turn into “another agent with opinions”.
If I give a second model the brief and ask what it would build instead, I have created two builders and a future argument.
That can be useful during exploration. It is not review.
The critic's job is to inspect the thing that exists against the thing that was required.
Read the acceptance criteria. Look at the diff. Run the relevant tests. Inspect the configuration. Open the page. Check the database state. Follow the evidence trail.
Then answer a very specific question:
Does the result support the builder's claims?
This became much more important to me after an agent produced a beautifully compliant research batch whose supposed evidence had not actually been gathered from the sources it claimed to have checked.
The fields were populated. The validator passed. The report looked excellent.
The evidence was not evidence.
That was a useful lesson in the difference between checking whether an answer has the right shape and checking whether the answer is true.
“Done” is a claim, not a magical state
I now read completion reports differently.
“Tests pass” is a claim.
“The migration is safe” is a claim.
“This is responsive” is a claim.
“The research has been verified” is very definitely a claim.
The critic looks underneath the sentence.
Which tests? What did they assert? Did they exercise the awkward permission path or only the happy path? Did the migration preserve the data it needed to preserve? Does the page work at 320 pixels or simply look lovely on the developer's monitor? Was the source actually retrieved or merely listed in a field?
None of this requires hostility towards the builder.
Software is full of statements that can be technically true while the real requirement is still false.
A build can pass and the user journey can be broken.
A screenshot can look correct while the interaction underneath it fails.
A validator can report 100 per cent compliance while proving only that every required field contains something.
All of those checks are still useful. They are just not larger than what they actually test.
Give the critic reality, not the builder's autobiography
One of the easiest ways to ruin the workflow is to give the critic only the completion report.
If the builder says it implemented everything, added comprehensive tests and verified compatibility, and I paste that report into another chat asking whether it looks good, I have not created independent review.
I have created a book club.
The critic needs access to whatever constitutes reality for the work.
For code, that normally means the repository and the diff.
For database work, the current schema and migrations.
For a public interface, the rendered behaviour.
For research, the sources and provenance.
For design, the actual page at the sizes people will use.
The builder's report is helpful because it tells the critic what the builder believes it did.
That makes the report a useful map.
It should not become the territory.
The critic also needs permission to say nothing is wrong
There is a failure mode on the other side.
Tell an AI that it is a critic and it can become remarkably committed to criticising things.
That is not useful either.
I do not need seventeen theoretical improvements simply because the model feels it should earn its title. Sometimes the work is fine. Sometimes an issue is real but outside the scope. Sometimes fixing a minor imperfection would introduce more risk than accepting it.
A critic therefore needs boundaries just as much as the builder did.
What was this work meant to achieve? What is explicitly out of scope? What would actually block acceptance? What is worth recording for later without derailing the current branch?
A good critic does not maximise findings.
It improves the decision.
Different models help, but the separation matters more than the logo
I often use different models for building and criticism, partly because different systems notice different things and partly because a genuinely fresh context is useful.
But I would not turn that into a permanent rule that Model A builds and Model B criticises.
The products change too quickly for that kind of religion.
A fresh session using the same model family can still provide useful separation. A supposedly superior critic model can still do a dreadful review.
What matters is that the reviewer did not spend the previous hour constructing and explaining the implementation, and that the reviewer has explicit permission to disagree with the builder's story.
The useful separation is between production attention and inspection attention.
One asks: how do I make this work?
The other asks: what would I need to see before I believe it works?
I still make the decision
This is the part that gets lost in some conversations about autonomous agents.
I do not use a builder and critic because I want two machines to argue until one wins.
I use them because they give me better evidence.
The builder tells me what it changed and why.
The critic tells me which claims survive independent inspection and which do not.
Then I decide what happens next.
Sometimes I send the work back. Sometimes I accept it with a documented follow-up. Sometimes the critic is wrong. Sometimes both agents miss the thing that bothers me immediately because I know the wider product, the person using it or the commercial consequence of the decision.
That is not a failure of the arrangement.
That is the part I am there for.
AI has made it possible for one person to organise work in a way that resembles a much larger team. That is genuinely remarkable.
The value is not that judgement has disappeared.
The value is that I can assign different kinds of attention to the same piece of work cheaply enough to do it routinely.
Builder says done.
Critic says prove it.
I decide whether I believe either of them.