Building Block 5 - Sub-Agents (Maker vs Checker)

Why You Can't Grade Your Own Homework

Think about the last time you wrote something and proofread it yourself. You missed typos, right? Not because you're careless - because your brain reads what it meant to write, not what's actually on the page. You're too close to it.

AI agents have the exact same blind spot, except worse. As Addy Osmani puts it, the model that wrote the code is "way too nice grading its own homework." Ask an agent "is this correct?" right after it wrote the code, and it will almost always say yes. It talked itself into the solution; it will talk itself into approving it.

The Pattern Has a Name: Evaluator-Optimizer

One agent generates a solution. A completely separate agent evaluates it against the spec and says what's wrong. The maker tries again with that feedback. Repeat until the checker is satisfied. That back-and-forth is the Evaluator-Optimizer pattern.

   ┌─────────────┐   code    ┌──────────────┐
   │   MAKER     │ ────────▶ │   CHECKER    │
   │ writes code │           │ critiques it │
   └─────────────┘ ◀──────── └──────────────┘
        ▲          "still wrong:        │
        │           token expiry"       │ "passes spec
        └───── tries again ─────────────┘  + tests" → DONE

How Sub-Agents Are Set Up

In modern tools you declare sub-agents in small config files - for example in .claude/agents/ or .codex/agents/ - each with a name, a description, and instructions. The clever part: you can give each one a differentmodel based on the job.

A common three-agent split:

  explorer  → a fast, cheap, read-only model
              "find the relevant files, don't change anything"

  implementer → a capable model
              "write the fix"

  verifier  → a strong, careful model on high effort
              "check the fix against the spec and the tests;
               be skeptical; try to break it"

You spend your "smart, expensive model" budget where it matters most - on the checker - because a verifier you actually trust is the only reason you can walk away from the loop.

This Is Also How /goal Works

Remember /goal from Lesson 58 - "keep going until the condition is true"? Under the hood, it uses this exact split. After each turn, a fresh, separatemodel decides whether the goal is met, instead of the agent that just did the work. The maker-vs-checker idea isn't just for code - it's applied to the stop condition itself, so the loop can't lie to itself about being finished.

The Cost, and When It's Worth It

Sub-agents aren't free. Each one does its own thinking and tool use, so a maker-checker setup burns more tokens than a single agent. That's the trade: you pay more to get a second opinion you can trust.

Hands-On: Write Your Checker's Job