Vorige week vroeg ik Claude Code om een complete feature te bouwen: een nieuw API-endpoint met Entity Framework Core migration, unit tests en integratie tests. Halverwege begon het zichzelf te herhalen. Het context window liep vol, het model werd voorzichtig, en uiteindelijk sloot het voortijdig af met “Ik denk dat dit de belangrijkste wijzigingen dekt” — terwijl de integratie tests nog ontbraken.

Dat is geen Claude-probleem. Dat is een single-agent-probleem.

De context window-muur

Elke AI-codeerassistent loopt tegen dezelfde limiet aan. Hoe langer een sessie draait, hoe meer context zich ophoopt. Token voor token raakt het werkgeheugen van het model vol. Op een gegeven moment merkt het model dat het de limiet nadert en begint het voortijdig af te ronden. Of erger — het verliest eerder gemaakte beslissingen uit het oog en spreekt zichzelf tegen.

Het engineering-team van Anthropic heeft dit direct gemeten. Bij langlopende codeertaken overschatten single agents hun voortgang en stoppen ze voordat het werk echt klaar is. Hoe langer de taak, hoe erger het probleem.

Voor .NET developers die aan echte features werken — geen speelgoedvoorbeelden — is dit een praktische beperking. Een goede feature branch heeft mogelijk wijzigingen nodig in je controller, servicelaag, repository, EF Core migration, unit tests en integratie tests. Dat is veel context om in één sessie vast te houden.

Drie agenten in plaats van één

Anthropic’s antwoord is een three-agent harness dat autonoom programmeren opsplitst in drie gespecialiseerde rollen:

De Planner ontleedt je verzoek in een gestructureerd plan. Hij begrijpt je architectuur, identificeert welke bestanden moeten veranderen en bepaalt de volgorde van operaties. Zie het als de tech lead die het implementatieplan schrijft voordat iemand het toetsenbord aanraakt.

De Generator schrijft code. Hij pakt het plan op en produceert output — bestandswijzigingen, nieuwe bestanden, configuratieveranderingen. Hij hoeft de volledige gespreksgeschiedenis niet te onthouden, want het plan geeft hem alles wat hij nodig heeft voor de huidige stap.

De Evaluator reviewt de output. Hij controleert of de gegenereerde code daadwerkelijk aan het plan voldoet, zoekt naar bugs, draait tests en geeft gestructureerde feedback. Als er iets niet klopt, gaat het werk terug naar de generator voor een nieuwe iteratie.

Het kernpunt: in plaats van één agent die alles in zijn hoofd moet houden, krijgt elke agent een schoon context window met gestructureerde artefacten van de vorige stap. Elke overdracht is een checkpoint. Context degradeert niet — het reset.

Waarom dit anders is dan subagents

Als je Claude Code’s bestaande subagent-functie hebt gebruikt (de Agent tool), denk je misschien dat dit bekend klinkt. Het is niet hetzelfde.

Subagents zijn kortlopende helpers. De hoofdagent start een subagent, geeft hem een specifieke taak (“zoek alle bestanden die IOrderRepository implementeren”), krijgt het resultaat terug en gaat verder. De hoofdagent houdt nog steeds alle context vast en neemt alle beslissingen.

Het three-agent harness is fundamenteel anders. Elke agent werkt onafhankelijk met zijn eigen context window. De planner wacht niet tot de generator klaar is — hij maakt een compleet plan en draagt het over. De evaluator hoeft de gespreksgeschiedenis niet te kennen — hij heeft alleen het plan en de output nodig.

Dit betekent dat het systeem uren kan draaien zonder context-degradatie. De context van de planner is schoon als hij plant. De context van de generator is schoon als hij genereert. De context van de evaluator is schoon als hij evalueert. Geen opgehoopte ruis.

Hoe dit eruitziet voor een .NET feature

Laat me dit concreet maken. Stel je moet een POST /api/orders endpoint toevoegen aan je ASP.NET Core applicatie. Zo verdelen de drie agenten het werk:

De Planner analyseert je solution-structuur en produceert zoiets als:

1. Maak OrderCreateDto in Models/
2. Maak OrderService met CreateAsync methode
3. Registreer OrderService in DI-container
4. Voeg CreateOrder actie toe aan OrdersController
5. Maak EF Core migration voor Orders-tabel
6. Schrijf unit tests voor OrderService
7. Schrijf integratie test voor POST /api/orders

Elke stap bevat de specifieke bestanden die moeten veranderen, de patronen om te volgen (gebaseerd op je bestaande code) en de acceptatiecriteria.

De Generator pakt stap 1 op en schrijft de DTO:

public class OrderCreateDto
{
    public required string CustomerId { get; init; }
    public required List<OrderLineDto> Lines { get; init; }
}

public class OrderLineDto
{
    public required string ProductId { get; init; }
    public required int Quantity { get; init; }
}

Dan stap 2, de service. Dan stap 3, de DI-registratie. Elke stap is een gefocust stuk werk met schone context.

De Evaluator controleert de output tegen het plan:

  • Volgt OrderCreateDto dezelfde patronen als andere DTO’s in het project?
  • Behandelt OrderService validatie op dezelfde manier als bestaande services?
  • Volgen de unit tests xUnit-conventies en de testpatronen in de solution?
  • Start de integratie test daadwerkelijk de testserver en roept het endpoint aan?

Als de evaluator een probleem vindt — bijvoorbeeld dat de service niet het Result<T> patroon gebruikt dat elke andere service gebruikt — stuurt hij gestructureerde feedback terug naar de generator. De generator krijgt een schone context met alleen het plan, de huidige code en de specifieke kritiek. Geen opgehoopte bagage van drie uur eerder werk.

De evaluator is de echte doorbraak

Je zou denken dat de planner het belangrijkste onderdeel is. Dat is hij niet. De evaluator is wat dit laat werken.

Anthropic’s Prithvi Rajasekaran zei het helder: “Het scheiden van de agent die het werk doet van de agent die het beoordeelt, blijkt een sterke hefboom.” Wanneer één agent zowel genereert als evalueert, is hij geneigd mild te zijn voor zichzelf. Het is dezelfde reden waarom we code reviews doen — een fris paar ogen vangt dingen die de auteur mist.

De evaluator kan je daadwerkelijke test suite draaien. Hij kan een live pagina navigeren met Playwright. Hij kan controleren of de gegenereerde code compileert. Hij leest niet alleen de output en gokt — hij verifieert.

Voor frontend-werk vond Anthropic dat iteratieve cycli tussen de generator en evaluator typisch 5 tot 15 verfijningen doorlopen. Voor een UI-component betekent dit dat de evaluator blijft terugduwen (“de spacing klopt niet”, “dit past niet bij het design system”, “de loading state ontbreekt”) totdat de output aan de criteria voldoet. Soms draaien deze cycli vier uur.

Dat is vier uur productieve iteratie die een enkele agent simpelweg niet kan volhouden.

Wat je vandaag al kunt doen

Het volledige three-agent harness is Anthropic’s interne framework. Je krijgt vandaag geen “three-agent mode” knop in Claude Code. Maar de patronen zijn beschikbaar, en je kunt ze nu al toepassen.

Gebruik subagents voor planning. Vraag Claude Code vóór een grote wijziging om een gedetailleerd plan te maken in een aparte agent. Laat hem je solution-structuur analyseren, alle bestanden identificeren die moeten veranderen en de stappen uitschrijven. Sla dat plan op in een bestand.

Gebruik de Agent tool om de solution-structuur te analyseren en een 
gedetailleerd implementatieplan te maken voor het toevoegen van een 
POST /api/orders endpoint. Neem elk bestand op dat moet veranderen, 
de volgorde van wijzigingen, en de patronen om te volgen gebaseerd 
op bestaande code. Sla het plan op in PLAN.md.

Gebruik aparte sessies voor implementatie. In plaats van één marathonsessie, splits het werk op in gefocuste sessies. Elke sessie krijgt het planbestand als context en implementeert één of twee stappen. Schone context, gefocust werk.

Gebruik Claude Code als evaluator. Start na de implementatie een nieuwe sessie en vraag Claude om de wijzigingen te reviewen tegen het plan:

Lees PLAN.md en review de wijzigingen in de huidige branch. Verifieer 
voor elke stap in het plan of de implementatie compleet is en de 
beschreven patronen volgt. Draai dotnet test en rapporteer eventuele 
fouten.

Dit is niet zo naadloos als een geïntegreerd three-agent systeem, maar het vangt het kernidee: gespecialiseerde rollen met schone context presteren beter dan één agent die alles probeert te doen.

Het grotere plaatje

Multi-agent development is niet alleen een performance-optimalisatie. Het verandert wat mogelijk is.

Een enkele agent kan een taak aan die in één context window past — ruwweg 30-60 minuten gefocust werk. Drie gespecialiseerde agenten met gestructureerde overdrachten kunnen coherent werk volhouden gedurende uren. Dat is het verschil tussen “help me deze methode te schrijven” en “bouw deze hele feature terwijl ik in een vergadering zit.”

Anthropic’s agentic coding trends report noemt dit als een van acht trends die softwareontwikkeling hervormen. De verschuiving is niet van “developer schrijft code” naar “AI schrijft code.” Het is van “AI helpt bij kleine taken” naar “AI handelt complete workflows af met menselijk toezicht op belangrijke momenten.”

Voor .NET developers is de praktische implicatie duidelijk: de features die je met AI-hulp bouwt, worden groter. De refactoring-sessies langer. De testdekking grondiger. Niet omdat je harder werkt, maar omdat AI-agenten beter worden in langdurig, coherent werk.

Probeer het patroon

Je hoeft niet te wachten op een officiële three-agent mode. Begin vandaag met het toepassen van het patroon:

  1. Plan in isolatie. Vraag Claude om te analyseren en te plannen voordat er code wordt geschreven. Sla het plan op.
  2. Implementeer in gefocuste sessies. Geef elke sessie het plan en een specifieke scope. Laat context niet onnodig ophopen.
  3. Review met frisse ogen. Start een nieuwe sessie om het werk te evalueren. Laat Claude de output vergelijken met het plan.

De volgende keer dat je een feature hebt die zes bestanden en drie projecten omvat, probeer deze aanpak in plaats van één lange sessie. Je merkt het verschil meteen — het laatste bestand krijgt dezelfde kwaliteit aandacht als het eerste.

Drie agenten, drie context windows, één coherente feature. Dat is de toekomst van AI-assisted development, en het is er al.