Let AI Grade Its Own Homework and It Will Always Give You an A

One person writes code, then signs off on it themselves and says there is no problem. Would you believe them?

The same applies to AI agents. CyrilXBT published an article about how to build an AI agent team with Claude Code, and he calls out this problem right at the start: putting a single agent in charge of the whole project is playing with fire. It plans, writes code, runs tests, and scores itself. Naturally, it says everything passed.

His judgment is blunt: the agent that writes code should not be the agent that approves it.

Four Problems a Single Agent Will Face

CyrilXBT lists four problems.

Context gets polluted. If you have the same agent do five things in a row, it will carry memories of the first four into the fifth. Research notes, failed code, and the three edits you suggested an hour ago all pile up in the context. By step five, the model is reading a novel full of irrelevant history, and quality naturally drops.

It cannot check itself. If you have the model write and then review in the same conversation, it tends to agree with itself, because it already decided that answer was right when writing it. Only another agent with a different task description and no memory of the writing process can catch problems the author cannot see.

A generalist is the same as having no specialty. A prompt saying 'You are a world-class researcher, copywriter, engineer, and editor' does not create four experts; it creates one generalist pretending to be four people. An agent that does only one thing, follows one set of rules, and has one definition of done will perform much better.

Serial work is inefficient. A single agent can only go step by step: research, then plan, then write. A team can split the work into separate pieces and run them in parallel.

How to Split the Team

CyrilXBT's architecture is not complicated: a Lead is responsible for understanding the goal, breaking down tasks, and making final decisions; several specialists each own one thing; a shared workspace is used to hand off files; and one set of rules everyone must follow.

In his team, called Launch Team, the four roles are strictly divided:

• Lead (main session, runs the strongest model) writes the brief, assigns work, and makes the call.
• Scout only researches: finds facts, competitors, pricing, and user pain points. Every piece of information must have a source; it never writes copy.
• Maker only writes deliverables. Based on the brief and research, it writes landing pages, posts, and emails; it never does its own research.
• Critic only reviews. It reads Maker's draft cold, checks it against the brief and research, and only flags problems; it does not edit the draft.

The key to division of labor is boundaries. Scout does not write, Maker does not research, and Critic does not fix. As soon as any agent starts doing someone else's job, the team degrades into one overloaded brain.

Critic Is the Role Most People Skip

CyrilXBT says Critic is the agent he thinks is most worth adding. He even put a line in Critic's system prompt: You did not write this draft; you have no reason to defend it.

But @Wukoayos's addition in the comments is even harsher than the original. His approach is: before the code even exists, write the review criteria into a Markdown file and have the review agent score against that file, instead of listening to the coder describe what they did. He also offers a way to validate the reviewer: first give the review agent a version you know has problems. If it lets that version pass, it is not really reviewing.

This test is very practical. Many people set up a review agent and assume it works, never verifying whether it actually catches flaws.

A Team That Only Nods at Each Other Is No Team at All

@E1ev3n raised a more fundamental question in the comments: an agent team is only useful when it disagrees about something real. He has seen too many setups where several agents just echo each other.

This is indeed the biggest weakness of this kind of setup. If four agents use the same model family, the same tendencies, and the same vague brief, they will very likely collectively produce a mediocre but internally consistent result. On the surface, it passed four gates; in reality, it is just the same voice repeated four times.

@Shivanath offered a data point: after he switched the reviewer to a different model family, in one test the two families agreed on 194 out of 200 judgments, and all the errors fell among the 6 disagreements. In other words, cross-model-family review is not about finding more problems; it is about not being led by the same bias on those 6 key disagreements.

Another commenter, @Aleksandar Janca, takes a more fundamental angle: if a test can actually run, let it judge first; do not let a review model judge first. A check that can execute code cannot be talked into passing.

Taken together, these three comments add an important lesson to CyrilXBT's plan: multi-agent does not mean multi-perspective. For a team to be truly useful, there must be room for disagreement to happen.

How to Control Costs

Four agents mean four contexts, and with review loops, consumption doubles. CyrilXBT's principle is: put strong models where judgment is needed. Lead, Maker, and Critic run Opus, because planning, writing, and review require taste and reasoning. Scout runs Sonnet, because research, summarization, and formatting are high-volume work with low judgment requirements. Pure grunt work, such as rearranging files, is fine with Haiku.

Loops also need caps. His commands hard-code 'send Scout back at most once' and 'Critic reviews at most one more round.' Without a cap, the Lead will keep looping in pursuit of perfection.

The Core of This Setup

At the end of the article, CyrilXBT says something quite accurate: after you build your first team, you stop asking 'What should I have AI do?' and start asking 'Who on my team should handle this?' That is a manager's mindset, not a user's.

But I think what is more worth remembering is those rebuttals in the comments. The value of a team is not in having more people; it is in whether there is an independent judge who, holding pre-written criteria, dares to say no to work they had no part in creating.

If several agents just change their avatars and nod at each other, you are better off with one person doing it. At least then you know where the problem is.