7.8
Subagents And The Critic Loop
Why this exists
Two techniques that look similar and do opposite things. One makes work faster. One makes it more likely to be right — and given what Level 6 asked of you, the second is the one worth more.
The idea
Subagents split work up. A critic checks it. Don't confuse them.
Subagents are extra sessions spun up to handle a piece of a job, each with its own clean context, reporting back. From 2.2 you know why that helps: three questions in one session compete for the same window and dilute each other. Three subagents each get a clean one.
They earn their place when the pieces are genuinely independent:
| Good | Bad |
|---|---|
| Same question, three different angles | Steps that depend on each other |
| Read four files, summarise each | A conversation that builds |
| Check the same thing three ways | Anything needing shared context |
The failure is using them for sequential work. If step two needs step one's answer, splitting them means passing context back and forth and losing more than you gained.
The critic loop is the more valuable one. Have something review work that something else produced — ideally a different model, because a model reviewing its own output tends to agree with itself.
The move: build with one, review with another. Ask the reviewer to find problems, not to approve. "What's wrong with this?" gets you something. "Is this good?" gets you yes.
Why this matters more for you than most people: everything you learned in Level 6 was about not shipping things you can't verify. A second opinion is the cheapest verification available, and it's genuinely useful on exactly the things you're least equipped to judge — code you didn't write, in a system you're still learning.
The strongest version is adversarial: tell the reviewer to try to break the argument, not to assess it. Default-to-refuting produces sharper findings than default-to-approving, because agreement is the easy answer and a reviewer looking for a reason to agree will find one.
And one honest limit: a critic that always approves is worthless. If yours never finds anything, it isn't being asked properly. Adjust the prompt until it starts disagreeing with things, then check whether it's right.
Do
Part one — subagents
- Pick a question with genuinely independent angles. "Where should this system be improved — from a reliability view, a cost view, and a maintainability view?"
- Run it as a fan-out with a subagent per angle.
- Note whether the three answers were genuinely different or largely the same. If the same, the angles weren't independent.
- Now deliberately misuse it: try a fan-out on something sequential. Note where it goes wrong.
Part two — the critic loop
- Take something real you produced in Level 5, 6 or 7 — the MCP server, the fix, a skill.
- Ask a different model to review it: "What's wrong with this?"
- Then ask adversarially: "Try to break this. Assume it's wrong and work out why." Compare what the two prompts surfaced.
- Verify what it found. A critic can be confidently wrong too — everything from 2.1 still holds.
- Fix anything real it caught.
- Write
review.md: what you had reviewed · what the two prompts each found · what was real · what you fixed.
Step 7 is the comparison worth making. The adversarial prompt almost always finds more, and seeing that gap once changes how you ask for review permanently.
Done when
Never do
Never use subagents for work where one step needs the previous step's answer. You'll spend more moving context than you save running in parallel.
Never accept a critic's findings without checking them. A second model is a second opinion, not a verdict — and it can be confidently wrong in exactly the way 2.1 described.
Never ask "is this good?" You'll get yes. Ask what's wrong with it.