Eén Claude Code sessie is krachtig. Het leest je code, begrijpt de context en schrijft werkende oplossingen. Maar er is iets dat ik wekenlang niet probeerde: meerdere sessies tegelijk draaien.

Toen ik het eenmaal deed, veranderde mijn workflow fundamenteel. Dit is wat ik leerde.

Waarom parallelle sessies werken

Elke Claude Code sessie draait in zijn eigen terminal. Het heeft zijn eigen context, zijn eigen gespreksgeschiedenis en zijn eigen focus. Sessies weten niet van elkaars bestaan — en dat is precies het punt.

Zie het als twee developers in je team. De één bouwt het API-endpoint terwijl de ander aan het frontend-component werkt. Daar hoeven ze niet samen voor te zitten. Ze moeten alleen uit elkaars bestanden blijven.

Hetzelfde geldt voor Claude Code sessies. Zolang ze aan verschillende delen van je codebase werken, draaien ze volledig onafhankelijk.

Scenario 1: API + Frontend

Je bouwt een nieuwe feature in je .NET solution. De backend heeft een nieuw endpoint nodig in je Web API project. De frontend heeft een nieuw Blazor-component nodig dat dit endpoint aanroept.

Terminal 1:

“Voeg een nieuw endpoint toe aan OrdersController dat de bestelgeschiedenis van een klant teruggeeft. Inclusief paginering. Volg de patronen in de bestaande controllers.”

Terminal 2:

“Maak een nieuw Blazor-component OrderHistory.razor dat een gepagineerde lijst van bestellingen toont. Gebruik dezelfde styling als het bestaande CustomerDetails-component.”

Beide sessies werken tegelijkertijd. De API-sessie schrijft controller-code, voegt een service-methode toe, werkt het repository bij. De frontend-sessie bouwt het component, voegt de service-aanroep toe, schrijft de HTML.

Als beide klaar zijn, integreer je. Het Blazor-component verwacht al het response-formaat dat de API teruggeeft, omdat beide sessies je bestaande patronen volgden.

Scenario 2: Feature + Tests

Dit is mijn favoriete patroon. Eén sessie implementeert een feature. Een andere schrijft tests voor bestaande code die nog geen coverage heeft.

Terminal 1:

“Implementeer de e-mailnotificatie-feature volgens de spec in docs/email-notifications.md.”

Terminal 2:

“Schrijf unit tests voor de OrderService class. Dek alle publieke methoden, inclusief edge cases voor null-invoer en lege collecties.”

De test-sessie hoeft niet te wachten tot de feature klaar is. Die werkt aan code die al bestaat. En als de feature-sessie klaar is, kun je meteen een nieuwe sessie starten die tests schrijft voor de zojuist geschreven code.

Scenario 3: Meerdere bugfixes

De sprint review is morgen. Er staan drie ongerelateerde bugs in de backlog. Elk raakt andere bestanden in andere projecten.

Drie terminals. Drie bugs. Allemaal tegelijk.

Terminal 1: "Fix #142 — het datumfilter op de rapportenpagina negeert de tijdzone"
Terminal 2: "Fix #156 — CSV-export faalt wanneer de productnaam puntkomma's bevat"
Terminal 3: "Fix #161 — e-mailvalidatie accepteert adressen zonder domein"

Tien minuten later heb je drie branches met drie fixes. Elk klaar voor review.

Git worktrees: de sleutel om conflicten te voorkomen

Hier wordt het praktisch. Als je twee Claude Code sessies draait in dezelfde directory op dezelfde branch, gaan ze gegarandeerd in elkaars vaarwater zitten. De ene sessie bewerkt een bestand, de andere bewerkt hetzelfde bestand, en je eindigt met een puinhoop.

De oplossing: git worktrees.

Een git worktree laat je meerdere branches van dezelfde repository uitchecken in aparte mappen — zonder het hele repo opnieuw te clonen. Elke map heeft zijn eigen working tree, maar ze delen dezelfde .git geschiedenis.

# Maak worktrees aan voor parallel werk
git worktree add ../mijn-project-api feature/bestelgeschiedenis-api
git worktree add ../mijn-project-frontend feature/bestelgeschiedenis-frontend

Nu heb je drie mappen:

  • mijn-project/ — je hoofdkopie
  • mijn-project-api/ — uitgecheckt op feature/bestelgeschiedenis-api
  • mijn-project-frontend/ — uitgecheckt op feature/bestelgeschiedenis-frontend

Start een Claude Code sessie in elke map. Ze werken op aparte branches, in aparte mappen. Geen conflicten mogelijk.

Als je klaar bent, ruim je op:

git worktree remove ../mijn-project-api
git worktree remove ../mijn-project-frontend

Praktische setup

Je hebt geen fancy tooling nodig. Meerdere terminal-tabs werken prima. Maar als je dit regelmatig doet, maakt een terminal multiplexer zoals tmux het makkelijker te beheren.

Een simpele tmux-setup:

# Start een nieuwe tmux sessie
tmux new-session -s werk

# Splits in panelen (Ctrl+B, dan %)
# Of maak nieuwe windows (Ctrl+B, dan C)

Mijn typische layout is drie panelen naast elkaar. Elk met Claude Code in een andere worktree. Ik kan alle drie tegelijk zien werken en wissel van focus met Ctrl+B en een pijltjestoets.

Maar eerlijk gezegd — drie losse terminal-tabs werken net zo goed. Laat de tooling je niet weerhouden om de aanpak te proberen.

Wanneer parallelle sessies problemen veroorzaken

Laten we eerlijk zijn over de valkuilen.

Dezelfde bestanden. Als twee sessies hetzelfde bestand moeten bewerken, draai ze dan niet parallel. De ene overschrijft de wijzigingen van de andere. Zelfs met worktrees en aparte branches krijg je later merge-conflicten.

Gedeelde state. Als je sessies afhankelijk zijn van een gedeelde database of een draaiende service, kunnen ze interfereren. De ene sessie dropt een tabel, de andere verwacht dat die er is. Gebruik aparte database-instanties of draai tests in isolatie.

Te veel tegelijk. Drie parallelle sessies is beheersbaar. Vijf wordt chaotisch. Je moet nog steeds de output van elke sessie reviewen, en dat kost mentale bandbreedte. Ik draai zelden meer dan drie.

Complexe afhankelijkheden. Als feature B afhankelijk is van de code die sessie A aan het schrijven is, kun je ze niet paralleliseren. Begin met A, maak die af, en start dan B met de nieuwe code beschikbaar.

Kostenoverweging

Laten we het over geld hebben. Elke Claude Code sessie doet zijn eigen API-aanroepen. Drie sessies parallel draaien betekent ruwweg drie keer het tokenverbruik voor die periode.

Voor mij klopt de rekensom. Als drie parallelle sessies me een uur sequentieel werk besparen, is dat uur developer-tijd veel meer waard dan de extra API-kosten. Maar dit hangt af van je abonnement en gebruikspatroon.

Mijn advies: begin met twee sessies. Raak vertrouwd met de workflow. Check je usage-dashboard na een week en besluit of de kosten opwegen tegen de tijdsbesparing. Voor de meeste taken is dat absoluut het geval.

Probeer het zelf

De volgende keer dat je twee ongerelateerde taken hebt — misschien een feature en wat test-coverage, of twee onafhankelijke bugs — probeer dit:

# Maak een worktree aan voor de tweede taak
git worktree add ../mijn-project-taak2 feature/taak-2

# Terminal 1: in je hoofdmap
claude

# Terminal 2: in de worktree
cd ../mijn-project-taak2
claude

Geef elke sessie een duidelijke, gerichte instructie. Kijk hoe ze parallel werken. Review de resultaten.

Je zult merken dat het knelpunt nooit de snelheid van Claude Code was — het was het feit dat je taken één voor één invoerde.