Je werkt aan een nieuw API-endpoint. Claude Code schrijft de controller, de servicelaag, de DTOs. Nu heb je tests nodig. En een code review. En XML-documentatie voor de publieke methoden. Dat zijn drie verschillende taken, elk met een andere mindset.

Wat als je ze niet een voor een hoeft te doen?

Wat zijn sub-agents?

Als je Claude Code een taak geeft, werkt het als een enkele agent. Het leest bestanden, bewerkt code, voert commando’s uit — allemaal in een gesprek met een set instructies. Dat werkt prima voor de meeste dingen.

Maar Claude Code kan ook sub-agents aanmaken: gerichte child-agents die elk een specifiek deel van het werk oppakken. Jij bepaalt wat elke sub-agent doet, waar het toegang toe heeft, en wat het moet opleveren. De parent-agent coordineert.

Zie het als een senior developer die werk delegeert aan specialisten. “Jij schrijft de tests. Jij reviewt de code. Jij werkt de documentatie bij.” Elke specialist focust op een ding en doet dat goed.

De Task tool

Sub-agents draaien op de Task tool in Claude Code. Als Claude de Task tool gebruikt, spawnt het een nieuwe agent met een eigen context window en een specifieke prompt die jij definieert. De sub-agent doet zijn werk en geeft het resultaat terug aan de parent.

Je hoeft niets te installeren. De Task tool zit ingebouwd in Claude Code. Wat het krachtig maakt is hoe je het instrueert — en dat begint in je CLAUDE.md.

Dit is het basispatroon. In je CLAUDE.md beschrijf je de sub-agents die Claude moet gebruiken:

## Sub-agents

Gebruik bij .NET-code deze gespecialiseerde agents via de Task tool:

### Testschrijver
Spawn een sub-agent met deze prompt:
"Je bent een .NET test-specialist. Gegeven een klasse, schrijf uitgebreide xUnit tests
met FluentAssertions. Dek het happy path, edge cases en foutscenario's.
Gebruik het Arrange-Act-Assert patroon. Mock dependencies met NSubstitute."

### Code Reviewer
Spawn een sub-agent met deze prompt:
"Je bent een .NET code reviewer. Review het gegeven bestand op: beveiligingsproblemen,
performance-issues, naleving van SOLID-principes, null safety, async/await correctheid.
Geef een gestructureerde lijst met bevindingen en ernst-niveaus."

### Documentatie-agent
Spawn een sub-agent met deze prompt:
"Je bent een .NET documentatie-specialist. Genereer XML-documentatie-comments
voor alle publieke types en members. Volg Microsoft's documentatierichtlijnen.
Wees bondig maar volledig."

Als Claude een situatie tegenkomt waar een van deze agents nuttig is, spawnt het die automatisch. Je hoeft niet om elke agent apart te vragen.

Voorbeeld 1: De testschrijver

Stel, je hebt net een PaymentService gebouwd met drie publieke methoden. Je zegt tegen Claude:

“Schrijf tests voor PaymentService.”

Met de sub-agent-configuratie hierboven spawnt Claude een testschrijver-agent. Die agent krijgt het PaymentService.cs-bestand, leest de dependencies, en produceert een volledige testklasse:

public class PaymentServiceTests
{
    private readonly IPaymentGateway _gateway;
    private readonly IOrderRepository _orderRepository;
    private readonly PaymentService _sut;

    public PaymentServiceTests()
    {
        _gateway = Substitute.For<IPaymentGateway>();
        _orderRepository = Substitute.For<IOrderRepository>();
        _sut = new PaymentService(_gateway, _orderRepository);
    }

    [Fact]
    public async Task ProcessPayment_ValidOrder_ReturnsSuccess()
    {
        // Arrange
        var order = new Order { Id = 1, Amount = 99.99m, Status = OrderStatus.Pending };
        _orderRepository.GetByIdAsync(1).Returns(order);
        _gateway.ChargeAsync(Arg.Any<PaymentRequest>()).Returns(new PaymentResult { Success = true });

        // Act
        var result = await _sut.ProcessPaymentAsync(1);

        // Assert
        result.Should().NotBeNull();
        result.Success.Should().BeTrue();
    }

    [Fact]
    public async Task ProcessPayment_OrderNotFound_ThrowsNotFoundException()
    {
        _orderRepository.GetByIdAsync(99).Returns((Order?)null);

        var act = () => _sut.ProcessPaymentAsync(99);

        await act.Should().ThrowAsync<NotFoundException>();
    }
}

De sub-agent focust uitsluitend op testen. Het probeert niet de service te refactoren of verbeteringen voor te stellen. Het schrijft tests — dat is zijn taak.

Voorbeeld 2: De code reviewer

Nu wil je een tweede paar ogen op diezelfde PaymentService. Claude spawnt de code reviewer-agent, die gestructureerde feedback teruggeeft:

## Code Review: PaymentService.cs

**HOOG** - Geen CancellationToken-ondersteuning op async-methoden.
ProcessPaymentAsync en RefundAsync moeten CancellationToken accepteren.

**MIDDEL** - Decimal-vergelijking zonder tolerantie in CalculateDiscount.
Overweeg een kleine epsilon voor financiele berekeningen.

**LAAG** - Overweeg het magische getal 3 (max retry count) te extraheren naar een constante.

**OK** - Null-checks op constructor-parameters ✓
**OK** - Async/await-patroon correct gebruikt ✓
**OK** - Geen duidelijke SQL-injectie of beveiligingsproblemen ✓

De reviewer fixt de code niet. Het identificeert problemen. Jij bepaalt waar je actie op onderneemt. Als je wilt, kun je tegen Claude zeggen: “Fix de HOGE en MIDDEL issues” — en de parent-agent pakt het op.

Voorbeeld 3: De documentatie-agent

De documentatie-agent handelt het vervelende-maar-noodzakelijke werk van XML-docs af:

/// <summary>
/// Verwerkt een betaling voor de opgegeven bestelling.
/// </summary>
/// <param name="orderId">De unieke identifier van de bestelling waarvoor betaald wordt.</param>
/// <returns>Een <see cref="PaymentResult"/> dat de uitkomst van de betaling aangeeft.</returns>
/// <exception cref="NotFoundException">Wordt gegooid als er geen bestelling bestaat met het opgegeven ID.</exception>
/// <exception cref="PaymentException">Wordt gegooid als de payment gateway de transactie afwijst.</exception>
public async Task<PaymentResult> ProcessPaymentAsync(int orderId)

Het leest de implementatie, begrijpt de exceptions, en schrijft documentatie die daadwerkelijk bij de code past. Geen boilerplate — echte documentatie.

Agents parallel draaien

Hier wordt het interessant. Je kunt tegen Claude zeggen:

“Voor elke service in de Services-map: draai de testschrijver en code reviewer parallel.”

Claude spawnt meerdere sub-agents tegelijk. De testschrijver werkt aan PaymentService terwijl de reviewer aan OrderService werkt. Dan wisselen ze. De parent-agent verzamelt alle resultaten en presenteert ze aan jou.

Voor een solution met tien services kan dit je serieus veel tijd besparen. In plaats van sequentieel testen schrijven, reviewen, documenteren — gebeurt alles tegelijk.

Wanneer sub-agents zinvol zijn

Sub-agents blinken uit als:

  • De taak duidelijk opsplitsbaar is. Testen en reviewen zijn onafhankelijke activiteiten. Ze hebben elkaars output niet nodig.
  • Je consistente patronen hebt. Als elke service dezelfde structuur volgt, dekt een prompt ze allemaal.
  • Het werk repetitief is. Tests schrijven voor 15 services is saai handwerk. Delegeren aan een sub-agent is efficient.

Sub-agents zijn overkill als:

  • De taak klein is. Als je tests schrijft voor een methode, vraag het gewoon direct aan Claude. Een sub-agent spawnen voegt overhead toe.
  • De taken sterk verweven zijn. Als de test afhangt van de review-bevindingen, heeft parallel draaien geen zin.
  • Je aan het verkennen bent. Als je nog niet weet wat je wilt, is een enkel gesprek met Claude flexibeler dan een gestructureerde agent-pipeline.

Beperkingen om te weten

Sub-agents hebben geisoleerde context. De testschrijver weet niet wat de reviewer gevonden heeft. De documentatie-agent ziet de testoutput niet. Elke sub-agent begint blanco met alleen de bestanden en prompt die je meegeeft.

Er is geen gedeelde state tussen agents. Als de reviewer een bug vindt en de testschrijver moet daar rekening mee houden, dan moet je dat handmatig coordineren via de parent-agent.

Sub-agents verbruiken tokens. Elk krijgt een eigen context window. Vijf agents parallel draaien op een grote codebase kost aanzienlijk meer tokens dan een enkele agent die alles sequentieel doet. Houd je verbruik in de gaten.

En tot slot: sub-agents zijn zo goed als hun prompts. Een vage prompt als “review deze code” geeft vage resultaten. Hoe specifieker je bent over frameworks, patronen en verwachtingen, hoe beter de output.

Begin met een agent

Bouw geen vloot sub-agents op dag een. Begin met een. De testschrijver is een goede eerste keuze — het is de meest mechanische taak, en de output is direct verifieerbaar met dotnet test.

Voeg het toe aan je CLAUDE.md. Probeer het op een paar services. Stel de prompt bij tot de tests passen bij de stijl van je team. Voeg dan de reviewer toe. Dan de documentatie-agent.

Het doel is niet om je eigen oordeel te vervangen. Het is om je capaciteit te vermenigvuldigen — door specialisten het werk te laten doen dat een patroon volgt, zodat jij je kunt focussen op het werk dat dat niet doet.