Hoe ik meerdere Claude Code-agents parallel laat draaien
Drie agents. Één repo. Nul conflicten.
Die zin had zes maanden geleden absurd geklonken. Ik had Claude Code al een tijdje op persoonlijke projecten gedraaid, en elke keer dat ik een tweede agent wilde opstarten voor een andere feature, liep ik tegen dezelfde muur — Git-conflicten, vuile werkdirectories, agents die elkaars wijzigingen overschreven. De workaround was pijnlijk: stash, switch branches, hoop dat niets breekt, herhaal.
Toen bracht Anthropic ingebouwde Git work tree-ondersteuning voor Claude Code. En eerlijk gezegd? Het veranderde fundamenteel hoe ik software bouw met AI-agents.
Dit ene feature zette mijn workflow om van "één agent die dingen sequentieel doet" naar "drie agents die tegelijkertijd aan drie verschillende features werken, elk in hun eigen geïsoleerde sandbox, en die netjes samenvoegen als ze klaar zijn." De productiviteitssprong was onmiddellijk en voelbaar — ik merkte het op de eerste dag.
Maar hier is wat niemand je vertelt over work trees in Claude Code: het standaardgedrag heeft een subtiel addertje dat je commits rechtstreeks naar main kan sturen terwijl jij denkt dat ze naar een feature-branch gaan. Ik ontdekte dit om 01:00 uur op een dinsdag. Laat me je van dat paniekmoment besparen.
Waarom je single-agent workflow je tegenhoudt
Een scenario dat waarschijnlijk bekend klinkt. Je bouwt een feature — zeg, authenticatie toevoegen aan een API. Je hebt Claude Code die aan de auth-middleware werkt. Halverwege realiseer je je dat je ook het databaseschema moet updaten. En terwijl je toch bezig bent, is er een bug in de frontend die een gebruiker vanmorgen rapporteerde.
Wat doe je? Je wacht. Je maakt eerst de auth-middleware af, commit die, dan het schema, dan de bugfix. Alles gebeurt sequentieel omdat Git je alleen één branch tegelijk kan uitchecken in één werkdirectory.
Ik werkte zo maanden lang. Het voelde normaal omdat het de manier is waarop elke developer heeft gewerkt sinds Git werd uitgevonden.
Git work trees lossen dit op infrastructuurniveau op.
Git Work Trees — de feature die je hebt genegeerd
Een Git work tree is een aparte werkdirectory die is gekoppeld aan hetzelfde Git-repository. Stel het je voor als meerdere uitgecheckte versies van je repo die allemaal tegelijk bestaan — elk op een andere branch, elk met zijn eigen bestandssysteem, elk volkomen onwetend van de andere.
Het zijn niet aparte klonen. Dat is het kritische deel. Ze delen dezelfde .git-directory, wat betekent dat ze alle branches, commits en objectopslag delen. Maar elke work tree heeft zijn eigen index en HEAD, dus ze kunnen volledig onafhankelijk werken.
De gotcha bij work trees die me bijna een productie-push stuurde
Voordat ik je de stapsgewijze setup doorloop, moet je dit begrijpen: wanneer Claude Code automatisch een work tree aanmaakt via zijn ingebouwde werk tree-functie, wordt de branch automatisch ingesteld op dezelfde als de primaire map, tenzij je expliciet een nieuwe branch opgeeft.
Dit betekent dat als je primaire map op main zit en je een work tree aanmaakt zonder een branch op te geven, je agent gaat committen naar main. Direct. Zonder de pull request-bescherming die je dacht te hebben.
De fix is simpel als je het eenmaal weet: geef altijd een nieuwe branchnaam op bij het aanmaken van een work tree.
git worktree add .claude/worktrees/feature-auth -b feature/auth
git worktree add .claude/worktrees/fix-login -b fix/login-validation
git worktree add .claude/worktrees/update-tests -b chore/update-tests
Die -b-vlag maakt een nieuwe branch aan en checkt die uit in de work tree. Nu heeft elke agent zijn eigen branch en kunnen ze nooit direct naar main pushen.
De complete setup: van nul naar drie parallelle agents
Stap 1: Configureer je work tree-directory
Claude Code gebruikt standaard .claude/worktrees/ als de work tree-map. Je kunt dit aanpassen in de Claude Code-instellingen, maar de standaard werkt goed. Zorg ervoor dat de directory bestaat:
mkdir -p .claude/worktrees
echo ".claude/worktrees/" >> .gitignore
Stap 2: Maak work trees aan voor elke taak
git worktree add .claude/worktrees/feature-auth -b feature/auth
git worktree add .claude/worktrees/fix-login -b fix/login-validation
git worktree add .claude/worktrees/update-tests -b chore/update-tests
Elk van deze aanmaken vergt minder dan een seconde. Je hebt nu drie werkdirectories, elk op een andere branch, allemaal klaar voor een agent.
Stap 3: Voer agents parallel uit
Dit is waar de magie gebeurt. Ik start meerdere Claude Code-sessies of sub-agents, elk gericht op een andere work tree.
Elke agent werkt volledig onafhankelijk. Ze kunnen bestanden lezen, bestanden schrijven, tests uitvoeren, commits maken — allemaal zonder te weten dat de andere agents bestaan.
Stap 4: Bekijk en push elke branch
Als de agents klaar zijn:
cd .claude/worktrees/feature-auth
git log --oneline -5
git diff HEAD~1
git push -u origin feature/auth
Stap 5: Maak pull requests aan
gh pr create --title "Add authentication middleware" --body "Implemented JWT auth..."
Nu heb ik drie aparte PRs, elk met gefocuste wijzigingen, schone diffs en geen kruisbesmetting.
Stap 6: Samenvoegen en opruimen
git checkout main
git pull
git worktree remove .claude/worktrees/feature-auth
git worktree remove .claude/worktrees/fix-login
git worktree remove .claude/worktrees/update-tests
Sub-agents: de volgende laag van parallelisatie
Work trees lossen het isolatieprobleem op. Sub-agents lossen het orkestatieprobleem op.
Hier is hoe het werkt. Je start een "orchestrator" Claude Code-sessie — de hoofd-agent die het grote plaatje begrijpt. Je vertelt de orchestrator welke features je wilt bouwen. De orchestrator analyseert de taken en bepaalt welke parallel kunnen lopen.
Vervolgens spawnt de orchestrator sub-agents, elk toegewezen aan een specifieke work tree met een specifieke taak. De orchestrator coördineert. De sub-agents voeren uit. De orchestrator bekijkt de output van elke sub-agent en voegt de resultaten samen.
Ik gebruik dit patroon voor complexe features waarbij meerdere lagen van de stack tegelijkertijd moeten worden bijgewerkt.
CLAUDE.md in elke work tree
Elke work tree erft de CLAUDE.md uit de hoofdrepository. Maar je kunt ook work tree-specifieke instructies toevoegen door een CLAUDE.md te maken in de work tree-map zelf.
Ik gebruik dit om agents context te geven over hun specifieke taak:
# Work Tree: Feature Auth
## Taak
Implementeer JWT-authenticatie voor de API
## Scope
Werk alleen aan auth-middleware en routes. Raak niet aan:
- Frontend-componenten
- Databasemigraties (aparte agent bezig)
- Tests (aparte agent bezig)
## Vereisten
- Gebruik bestaand JWT-hulpprogramma in /utils/jwt.js
- Volg bestaande foutafhandelingspatronen
Dit lijkt klein, maar het maakt een enorme verschil in outputkwaliteit. Een agent met duidelijke grenzen produceert beter gefocuste code dan een agent die vrij speelt in de hele repo.
De resultaten na drie maanden
De productiviteitscijfers zijn moeilijk precies te kwantificeren, maar hier is wat ik duidelijk kan meten:
Tijd-tot-eerste-commit per feature: Gedaald met ongeveer 60% voor taken die ik goed kan paralleliseren.
Git-geschiedenis kwaliteit: Significant verbeterd. Elke branch heeft nu gefocuste commits die één ding per keer aanpakken.
Codebeoordelingstijd: Gedaald met 40%. Kleinere, gefocuste PRs zijn sneller te beoordelen dan grote klodders die meerdere dingen tegelijk aanraken.
Bugs geïntroduceerd tijdens feature-ontwikkeling: Gedaald. Agents die scope-geïsoleerd opereren, hebben minder kans om onbedoelde neveneffecten te introduceren.
De toekomst van AI-ondersteunde parallelle ontwikkeling
Ik ben er echt van overtuigd dat op work trees gebaseerde parallelisatie een fundamentele workflow gaat worden voor AI-ondersteund coderen. Het patroon is natuurlijk. AI-agents werken het beste wanneer ze gefocuste, goed-afgebakende taken krijgen. Work trees bieden de isolatie die die agents nodig hebben.
Hier is mijn uitdaging voor jou: de volgende keer dat je aan een project werkt met Claude Code, identificeer twee taken die volledig onafhankelijk zijn. Maak twee work trees. Laat beide tegelijkertijd lopen.
Dat eerste moment — kijken hoe twee features parallel materialiseren terwijl jij je koffie drinkt — is het moment waarop de workflow klikt. En als het eenmaal klikt, ga je nooit meer terug.
