Subagenten effectief inzetten

You know how to create sub agents and design them well. Je weet hoe je sub-agents maakt en ze goed ontwerpt. Now, let's cover when they actually help and when they get in the way. Nu bekijken we wanneer ze echt helpen en wanneer ze in de weg zitten. Simply put, the difference comes down to whether the intermediate work matters to your main thread. Simpel gezegd: het verschil hangt af van of het tussenliggende werk er toe doet voor je hoofdthread. When exploration is separate from execution, sub agents shine. Wanneer exploratie los staat van uitvoering, presteren sub-agents uitstekend. When each step depends on what the previous step discovered, well, information gets lost in the handoff process. Wanneer elke stap afhankelijk is van wat de vorige stap ontdekte, gaat er informatie verloren in het overdrachtsproces. Sub agents excel at research tasks where you just need an answer, not the journey. Sub-agents blinken uit bij onderzoekstaken waarbij je alleen een antwoord nodig hebt, niet het proces. Consider investigating how authentication works in an unfamiliar code base. Denk aan het onderzoeken van hoe authenticatie werkt in een onbekende codebase. Well, the main thread might need to know where is the JWT validated, but doesn't need to see every file that was searched. De hoofdthread hoeft alleen te weten waar de JWT wordt gevalideerd, niet elk doorzocht bestand te zien. A research sub agent can read dozens of files, trace through function calls, and explore different code paths. Een onderzoeks-sub-agent kan tientallen bestanden lezen, function calls traceren en verschillende code paths verkennen. All that exploration stays in the sub agent's context. Al die exploratie blijft in de context van de sub-agent. Your main thread receives JWT validation happens in middleware/auth.js at line 42, called from the Express router and route/api.js, or something like that. Je hoofdthread ontvangt: JWT-validatie gebeurt in middleware/auth.js op regel 42, aangeroepen vanuit de Express router en route/api.js, of iets in die richting. Claude reviews work more effectively when the code is presented as being authored by someone else. Claude beoordeelt werk effectiever wanneer de code wordt gepresenteerd als geschreven door iemand anders. If you build a feature over many turns with your main thread, asking the main thread to then review it often doesn't give the best feedback. Als je een feature bouwt over meerdere beurten met je hoofdthread, levert de hoofdthread vragen om review daarna vaak niet de beste feedback op. Claude was involved in creating it, so it has trouble seeing it with fresh eyes. Claude was betrokken bij het maken ervan, dus het is moeilijk om het met frisse ogen te zien. A reviewer sub agent sees the changes in a separate context. Een reviewer sub-agent ziet de wijzigingen in een aparte context. It runs get diff, reads the modified files, and applies its specialized review criteria without the history of how the code was written. Het voert git diff uit, leest de gewijzigde bestanden en past zijn gespecialiseerde reviewcriteria toe zonder de geschiedenis van hoe de code is geschreven. And this separation also lets you encode project-specific review standards in the sub agent system prompt, ensuring consistent review criteria across the team. En door deze scheiding kun je projectspecifieke reviewstandaarden vastleggen in de system prompt van de sub-agent, wat consistente reviewcriteria in het hele team garandeert. Claude Code's default system prompt emphasizes concise, code-focused response. De standaard system prompt van Claude Code legt de nadruk op beknopte, op code gerichte antwoorden. And this works great for coding, but not for everything. En dat werkt prima voor programmeren, maar niet voor alles. So, one is a copywriting sub-agent with instructions about tone, audience, and style. Dus, een copywriting sub-agent met instructies over toon, doelgroep en stijl. This will produce better marketing text than the main thread would. Dit levert betere marketingteksten op dan de hoofdthread zou doen. Claude Code's default prompt tends towards concise, technical writing, which really isn't what you want for a landing page or email campaign, unless you want to put your customers to sleep. De standaard prompt van Claude Code neigt naar beknopt, technisch schrijven, wat niet is wat je wil voor een landingspagina of e-mailcampagne, tenzij je je klanten in slaap wilt sussen. A copywriting sub-agent can have completely different instructions about voice and structure. Een copywriting sub-agent kan volledig andere instructies hebben over stem en structuur. A styling sub-agent that at mentions your design system files will apply consistent CSS patterns. Een styling sub-agent die je design system-bestanden noemt, past consistente CSS-patronen toe. When the sub-agent runs, those files load into the context automatically, so it knows your color variables, spacing conventions, and component patterns before it even starts writing any CSS. Wanneer de sub-agent draait, worden die bestanden automatisch in de context geladen, zodat hij je kleurvariabelen, spacingconventies en componentpatronen kent voordat hij ook maar begint met het schrijven van CSS. Sub-agents that claim expertise rarely help. Sub-agents die expertise claimen, helpen zelden. Prompts like, "You are a Python expert." or "You are a Kubernetes specialist." add no value because Claude already has that knowledge. Prompts als "Je bent een Python-expert" of "Je bent een Kubernetes-specialist" voegen geen waarde toe, want Claude heeft die kennis al. The overhead of launching a sub-agent, losing visibility into its work, and compressing its findings into a summary only makes sense when the sub-agent does something that the main thread can't. De overhead van het starten van een sub-agent, het verlies van zicht op zijn werk en het samenvatten van zijn bevindingen is alleen zinvol als de sub-agent iets doet wat de hoofdthread niet kan. Like applying a custom system prompt or keeping exploratory work isolated. Zoals het toepassen van een custom system prompt of het geïsoleerd houden van exploratief werk. Sequential sub-agent pipelines create problems. Sequentiële sub-agent pipelines veroorzaken problemen. Consider a three-agent flow. Denk aan een drie-agenten flow. One to reproduce a bug, one to debug it, and one to fix it. Een om een bug te reproduceren, een om hem te debuggen en een om hem te repareren. Pipelines work when tasks are truly independent. Pipelines werken wanneer taken echt onafhankelijk zijn. They fail when each step depends on discoveries from the previous step. Ze falen wanneer elke stap afhankelijk is van ontdekkingen uit de vorige stap. Test runner sub-agents tend to hide information you need. Test runner sub-agents verbergen informatie die je nodig hebt. When tests fail, you want the full output to diagnose issues. Wanneer tests falen, wil je de volledige output om problemen te diagnosticeren. A sub-agent that returns a test failed forces you to create additional debug scripts to get details that would have been visible in direct output. Een sub-agent die alleen "test mislukt" teruggeeft, dwingt je extra debugscripts te maken voor details die in directe output zichtbaar zouden zijn geweest. Testing has showed that the test runner pattern performed worse among all configurations. Tests toonden aan dat het test runner-patroon het slechtst presteerde van alle configuraties. Across the series, we covered how sub-agents work as isolated threads that return summaries. In de serie bespraken we hoe sub-agents werken als geïsoleerde threads die samenvattingen teruggeven. How to create them with the /agents command, and how to design them with structured outputs and specific descriptions. Hoe je ze maakt met het /agents command, en hoe je ze ontwerpt met gestructureerde outputs en specifieke beschrijvingen. Use them for research, reviews, and tasks needing custom system prompts. Gebruik ze voor onderzoek, reviews en taken waarvoor aangepaste system prompts nodig zijn. But, avoid them for expert claims, multi-step pipelines, and test runners. Maar vermijd ze voor expertiseclaims, meerstappige pipelines en test runners. The key question, does the intermediate work matter? De sleutelvraag: doet het tussenliggende werk ertoe? If not, then delegate it. Zo niet, delegeer het dan.