Subagent-driven development: Sonnet+Opus splitsen voor plan-executie
Definitie
Executie-patroon voor implementatieplannen waarbij elke task wordt uitgevoerd door twee subagents: een Sonnet-implementer die de code schrijft, commits en test, en een Opus-reviewer die spec-compliance en code-quality in één oordeel beoordeelt. Ontwikkeld in tegenstelling tot parallel-subagents: hier is de stroom sequentieel per task met twee gates.
Context
Toegepast in april 2026 op het Atelier sub-project A implementatieplan (40 tasks voor @atelier/vault-contract). De subagent-driven-development skill uit superpowers schrijft drie subagents per task voor (implementer + spec-reviewer + code-quality-reviewer). Voor mechanische tasks in een token-budget-krap 5-uursvenster is dat overkill. De Sonnet+Opus splitsing reduceert de cost tot circa 45-55K tokens per mechanische task zonder merkbaar kwaliteitsverlies.
Kernpunten
Rolverdeling.
Implementer op Sonnet. Mechanische file-creatie, npm install, expliciete git add met specifieke paden, commit. Krijgt de volledige task-tekst uit het plan (geen samenvatting), plus harde waarschuwingen over pre-existing WIP die niet mag worden aangeraakt. Rapporteert DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT of BLOCKED met commit-SHA en verificatie-output.
Reviewer op Opus. Verifieert zelf op disk met git show, cat, ls; gelooft de implementer niet blind. Geeft verdict APPROVED, APPROVED_WITH_FOLLOWUP of NEEDS_FIX. Combineert spec-compliance en code-quality in één output van onder 400 woorden.
Waarom niet andersom. Implementer op Opus en reviewer op Sonnet klinkt logisch (duurste model voor de code). Het is omgekeerd: implementer doet mechanisch werk, Sonnet is genoeg. Reviewer doet oordeel en ving in de pilot een echte spec-bug (plan schreef git rm package-lock.json voor terwijl npm install juist een nieuwe workspace-lockfile genereert die gecommit hoort te worden). Judgment verdient Opus.
Token-economie per task. Pilot Task 1 (monorepo workspaces): implementer 21K, reviewer 24K. Pilot Task 2 (package skeleton): implementer 18K, reviewer 31K. Plus parent-coordinatie circa 5-10K per task voor prompt-schrijven en summary-lezen. Totaal per mechanische task circa 50K tokens. Voor complexe tasks (integratie-werk, rewrites) wordt implementer beter Opus en loopt de kost op naar 150-300K per task.
Model-selectie naar taaktype (2026-04-18 observatie). Op een autonome 5-uurs uitvoering (vault Fase 2c + eindredacteur testcases) zijn vier mechanische implementatietasks uitgevoerd met Haiku (code schrijven, bestaande patronen volgen, typecheck) voor circa 60-75K tokens per task. Task 5 (skill-executions + Backlog-updates) vereiste oordeel en WebSearch; Sonnet was daar de ondergrens. Haiku werkt goed bij: 1-2 bestanden aanmaken/aanpassen op basis van compleet codeblok in de prompt, typecheck draaien, committen. Haiku werkt NIET bij: multi-file integratie zonder expliciete instructie, debuggen van onverwachte fouten, oordeel over spec-compliance. Grensregel: als de task volledig mechanisch is en de prompt het exacte eindresultaat toont, kan Haiku; anders Sonnet.
Harde discipline-regels bij dispatch.
- Implementer krijgt de volledige task-tekst inclusief alle code-blokken uit het plan. Geen “zoals in task N” verwijzingen.
- Waarschuwingen expliciet maken: welke WIP NIET aanraken, welke files WEL, welke build-stappen WEL of NIET.
git add <specifieke paden>altijd, nooitgit add .of-A.- Reviewer krijgt als input: task spec uit plan + acceptance criteria uit backlog + implementer-rapport met commit-SHA. Verifieert zelf, gelooft niet blind.
- NEEDS_FIX maximaal één fix-ronde. Daarna escaleren naar mens.
Plan-inconsistenties zijn systematisch. Plannen geschreven door AI op basis van een spec bevatten vrijwel altijd kleine inconsistenties: een test verwacht ander gedrag dan de spec beschrijft, of twee tasks maken tegenstrijdige aannames over een returnwaarde. Implementers mogen dit oplossen door het gedrag te kiezen dat overeenkomt met de tests (die het gewenste gedrag het meest concreet uitdrukken) en het in het rapport te noemen. Controller pre-scant elke task voor dispatch om grote inconsistenties vroeg te signaleren.
Lichtere reviewregime bij goed gespecificeerde plannen (optie 2). De volledige drie-subagent review per task (implementer + spec-reviewer + code-quality-reviewer) is te zwaar voor plannen van 15+ goed gespecificeerde tasks. Alternatief: implementer rapporteert, controller doet snelle spec-check op het rapport (geen aparte subagent), daarna één code-review subagent per task. End-to-end commando’s (CLI-wiring, integratie) krijgen de volledige drie-fase review. Mechanische taken (types, pure functies, config) krijgen alleen de lichte variant. Toepassing: CyberChecker 18-task plan in april 2026 — 57 tests, 0 regressies, geen kwaliteitsproblemen door deze vereenvoudiging.
Backlog-integratie. Elke task een backlog-entry met expliciete acceptance criteria (--ac) en Definition of Done (--dod). Status naar “In Progress” met --append-notes datum en aanpak. Bij afronding: alle ACs en DoD afvinken, --append-notes met tokens en commit-SHA, --final-summary met wat er gebouwd is. De backlog dient als audit-trail en handoff-document.
Plan-bugs komen bovendrijven. Een plan geschreven door een agent op basis van een spec blijft foutgevoelig. De Opus-reviewer vond in Task 1 een reele spec-bug; dat betekent: verwacht dat latere tasks ook bugs bevatten. Pre-scannen elke task voor dispatch helpt, maar vervangt review niet.
Toepassbaar buiten code. Het patroon werkt ook voor niet-code taken zoals MCP-backlog beheer. De implementer-subagent voert MCP tool calls uit (bijv. task_search + task_create), de spec-reviewer leest het aangemaakte bestand op schijf en checkt of de veldspecificaties overeenkomen met de opdracht. Dezelfde gates, andere output. Gedocumenteerd: vier backlog-taken aangemaakt via subagents in mei 2026 (TASK-125 t/m TASK-128), spec-review op bestandsniveau werkte zonder aanpassingen aan het protocol.
Verbanden
- Zie ook: wiki-parallelle-subagents-workflow
- Zie ook: wiki-atelier-architectuur
- Zie ook: wiki-cc-scheduled-tasks
- Zie ook: wiki-tdd-claude-code-skills
Bronnen
Gedestilleerd uit Atelier pilot Task 1-2 en CyberChecker 18-task plan. Skill-referentie: superpowers:subagent-driven-development.