Wanneer subagents schitteren

Je weet hoe je subagents moet maken en goed moet ontwerpen. Nu is de vraag: wanneer helpen ze echt, en wanneer staan ze in de weg? Het verschil komt neer op één ding -- of het tussenwerk belangrijk is voor je hoofdthread.

Subagents werken het best wanneer de exploratie gescheiden is van de uitvoering. Als elke stap in een taak afhangt van wat de vorige stap heeft ontdekt, wil je dat werk in je hoofdthread. Maar als je alleen een antwoord nodig hebt en je niet om de weg ernaartoe geeft, delegeer het dan.

Subagents blinken uit bij taken waarbij:

Je een resultaat nodig hebt, niet een stap-voor-stap beschrijving van hoe het is gevonden
Het exploratieve werk je hoofdthread's context zou vervuilen
De taak baat heeft bij een vers perspectief of een aangepaste system prompt

Onderzoekstaken

Onderzoek is het klassieke use case voor subagents. Stel je voor dat je onderzoekt hoe authenticatie werkt in een onbekende codebase. Je hoofdthread moet weten waar de JWT wordt gevalideerd, maar het hoeft niet elke file te zien die onderweg is doorzocht.

Een onderzoeks-subagent kan tientallen files lezen, functieaanroepen traceren en verschillende codepaden verkennen. Al die exploratie blijft in de context van de subagent. Je hoofdthread ontvangt een schone samenvatting zoals:

JWT-validatie gebeurt in middleware/auth. js regel 42, aangeroepen vanuit de Express router in route/api. js

De subagent deed het zware werk. Je hoofdthread krijgt precies wat het nodig heeft om verder te gaan.

Code Reviews

Claude beoordeelt code effectiever wanneer de code wordt gepresenteerd als geschreven door iemand anders. Als je een feature over veel turns met je hoofdthread hebt gebouwd, vraag je diezelfde thread om het te beoordelen, levert dat vaak zwakke feedback op. Claude was betrokken bij het maken ervan, dus het heeft moeite om het met frisse ogen te zien.

Een reviewer-subagent ziet de wijzigingen in een aparte context. Het voert git diff uit, leest de gewijzigde files en past zijn gespecialiseerde beoordelingscriteria toe zonder de geschiedenis van hoe de code is geschreven. Deze scheiding stelt je ook in staat om projectspecifieke beoordelingsnormen in de system prompt van de subagent in te coderen, wat zorgt voor consistente beoordelingscriteria in het hele team.

Aangepaste System Prompts

De standaard system prompt van Claude Code benadrukt beknopte, code-gerichte reacties. Dat werkt prima voor codering, maar niet voor alles.

Hier zijn twee gevallen waarbij een aangepaste system prompt de subagent echt beter maakt dan de hoofdthread:

Copywriting-subagent \-- Geef het instructies over toon, publiek en stijl. De standaard prompt van Claude Code neigt naar beknopte technische schrijfstijl, wat echt niet is wat je wilt voor een landingspagina of e-mailcampagne. Een copywriting-subagent kan volledig andere instructies hebben over stem en structuur.
Styling-subagent \-- Wijs het naar je design system-files. Wanneer de subagent wordt uitgevoerd, worden die files automatisch in zijn context geladen, dus het kent je kleurvariabelen, spacing-conventies en componentpatronen voordat het zelfs maar begint CSS te schrijven.

Wanneer Subagents Schadelijk Zijn

De overhead van het starten van een subagent -- het verliezen van zichtbaarheid in zijn werk en het comprimeren van zijn bevindingen in een samenvatting -- heeft alleen zin wanneer de subagent iets doet wat de hoofdthread niet kan. Er zijn drie veel voorkomende anti-patronen waar je op moet letten.

Expertiseclaims

Subagents die expertise claimen helpen zelden. Prompts zoals "je bent een Python-expert" of "je bent een Kubernetes-specialist" voegen geen waarde toe omdat Claude al die kennis heeft. Er is niets wat een zogenaamde expert-subagent kan doen wat je hoofdthread niet direct kan doen.

Sequentiële Pipelines

Sequentiële subagent-pipelines creëren problemen. Stel je een drie-agent-flow voor: één om een bug te reproduceren, één om het op te sporen en één om het op te lossen. Pipelines werken wanneer taken echt onafhankelijk zijn. Ze falen wanneer elke stap afhangt van ontdekkingen uit de vorige stap -- en bugfixing doet dat bijna altijd. Informatie gaat verloren bij de overdracht tussen agents.

Test Runners

Test runner-subagents hebben de neiging informatie te verbergen die je nodig hebt. Wanneer tests mislukken, wil je de volledige output om problemen op te sporen. Een subagent die "tests mislukt" retourneert, dwingt je om extra debug-scripts te maken om details te krijgen die zichtbaar zouden zijn geweest in directe output. Testen hebben aangetoond dat het test runner-patroon slechter presteerde dan alle andere configuraties.

De Beslissingsregel

Wanneer je beslist of je een subagent wilt gebruiken, stel jezelf één vraag: doet het tussenwerk ertoe?

Als het antwoord nee is -- je hebt alleen het eindresultaat nodig -- delegeer het dan aan een subagent. Als het antwoord ja is -- je moet zien en reageren op wat er onderweg gebeurt -- houd het dan in je hoofdthread.

Gebruik subagents voor:

Onderzoek en exploratie
Code reviews
Taken die een aangepaste system prompt nodig hebben

Vermijd subagents voor:

"Expert"-persona's die geen echte mogelijkheid toevoegen
Multi-stap-pipelines waarbij elke stap van de vorige afhangt
Het uitvoeren van tests waarbij je volledige output nodig hebt voor debugging