Building a Subagent Team That Reviews Its Own Work

A single agent writing code is a very fast autocomplete. It produces something plausible, you review it, you fix what it missed. Useful, but the quality ceiling is your patience for reviewing.

The change that actually moved my output was giving the work to several specialists and making them check each other before anything reached me.

Why one agent plateaus

One agent holds one perspective at a time. It is optimising for finishing your request, which means it is systematically bad at noticing the thing you did not ask about — the accessibility regression, the RTL layout that broke, the endpoint that now returns a different shape than the frontend expects.

That is not a model failure. It is the same reason developers do not review their own pull requests.

The shape of a team

For frontend work I run a small set of roles, each with a narrow brief:

• A visual builder that owns art direction and brand tokens — hero areas, composition, the parts that carry identity.
• A data-UI builder that owns dense interactive screens — tables, filters, dashboards. Completely different instincts from the first one.
• A forms and conversion builder for anything where a user submits something.
• A QA lead that reviews all of the above and is allowed to edit it.

The last role is the one that matters. A reviewer that only files complaints produces a list you now have to work through yourself. A reviewer that can open the file and fix the inconsistency produces a finished result.

Give them different instructions, not different names

The failure mode I hit first was spawning three agents with the same brief and expecting variety. I got three near-identical implementations and a reviewer with nothing to say.

Specialisation has to be real. Each role gets its own instruction file with its own priorities, and crucially its own idea of what a defect is. The data-UI specialist treats a slow filter as a bug. The visual specialist treats an off-token colour as a bug. Neither notices the other's problem, which is precisely why running both beats running either twice.

Convergence is a step, not an assumption

Parallel builders produce work that is individually fine and collectively incoherent. Three good components, three slightly different spacing scales.

So the last stage is explicit: one pass whose only job is to reconcile. Same type ramp, same border weights, same motion timing, same empty states. Nothing new gets built during convergence — it is purely about making the pieces read as one product. Skipping this is how you end up with a site that feels like it was assembled by a committee, because it was.

What I learned the hard way

Isolation prevents most collisions. Two agents editing the same file at the same time is a merge conflict you did not ask for. Give parallel work separate surfaces, or separate worktrees.

Context is not free. Every agent starts cold and re-derives what you already know. Spawning a team for a two-line fix costs more than doing it yourself — and the more agents involved, the more expensive being wrong is.

Reviewers need permission to be blunt. If the instruction is "check the work", you get "looks good with minor suggestions". If the instruction is "find the three things most likely to embarrass us in production and fix them", you get useful output.

Read the diff anyway. The team raises the floor; it does not replace your judgement about what should have been built in the first place.

The pattern is not "more agents equals better code". It is "a builder and a critic produce better code than a builder alone" — which has been true of human teams for as long as software has existed.

When it is worth it

I reach for a team when the surface is wide: a full page, a feature crossing frontend and backend, anything where the risk is inconsistency rather than difficulty. For a single component, one agent and my own review is faster and cheaper.

The useful mental model is that you are not hiring more typists. You are installing a process — and processes only pay off on work large enough to drift.