Hoe je 3 tot 8 Coding Agents Parallel Kunt Uitvoeren Zonder het Overzicht te Verliezen

Twee agents tegelijk uitvoeren kost je vijf minuten. Je opent twee terminals, geeft elk een taak en kijkt hoe de tekst voorbij rolt.

De problemen beginnen bij de vierde.

Je weet niet meer welke wacht op een review, welke klaar is, welke tien minuten geleden crashte terwijl je ergens anders naar keek. Je scrolt in de verkeerde terminal. Je start een taak opnieuw die al gedaan was. Na een uur doe je het werk van drie agents met de hand, alleen om je weg te vinden.

Het is geen probleem van rekenkracht. Het is een probleem van zichtbaarheid.

De echte bottleneck zit in je hoofd

Een agent die autonoom codeert, levert in bursts. Hij denkt 40 seconden na, schrijft, stopt, wacht op jouw goedkeuring. Tijdens die 40 seconden kun je een tweede agent volgen. Terwijl de tweede schrijft, keur jij de eerste goed.

Tot 3 agents kan je brein het bijhouden. Na 5 raak je de draad kwijt.

Anthropic publiceerde een veelzeggend getal in zijn documentatie: ongecontroleerde pogingen slagen ongeveer één keer in de drie. Het verschil tussen mensen die veel werk afleveren en de rest is niet het model. Het is de structuur die ze opzetten voordat ze beginnen.

Dus voordat je opschaalt, structureer je.

Regel één: één agent, één geïsoleerde werkruimte

De klassieke fout is drie agents op dezelfde kopie van de repo zetten. Ze lopen elkaar in de weg. De een bewerkt package.json, de ander ook, en je eindigt met een merge die je niet kunt ontwarren.

De oplossing is twee woorden: git worktree.

git worktree add ../project-auth feature/auth
git worktree add ../project-billing feature/billing
git worktree add ../project-export feature/export

Elke agent werkt in zijn eigen map, op zijn eigen branch, met zijn eigen bestanden. Nul botsingen. Je beoordeelt elke branch apart en merge wanneer het klaar is.

Dit is de basis van wat onderzoekers geïsoleerde delegatie noemen: een centrale manager verdeelt het werk, elke subtaken draait in zijn eigen hoek, en integratie gebeurt achteraf, met tests om te valideren.

Regel twee: geef nooit hetzelfde centrale bestand twee keer uit

Voordat je het werk verdeelt, zoek je de bestanden die meerdere functies moeten aanraken. De router. Het databaseschema. De API-routeconfiguratie.

Die bestanden krijgen precies één agent. De anderen wachten of werken eromheen.

Geef dezelfde routes.ts aan twee parallelle agents en je betaalt in mergeconflicten wat je dacht te winnen aan parallelisme. Die ruil verlies je elke keer.

Regel drie: één bord, geen tien terminals

Dit is waar de meeste mensen stoppen met multi-agent. Ze openen acht terminaltabs, verliezen de draad en kruipen terug naar een enkele agent.

Je hebt één overzicht nodig dat drie vragen in één oogopslag beantwoordt:

• Wie is er nu aan het coderen?
• Wie wacht op mijn review?
• Wie is klaar of gecrasht?

Zonder dat overzicht kost multi-agent je meer in mentale belasting dan het je in snelheid oplevert. Met dat overzicht kun je echt 6 of 8 werkstromen tegelijk beheren.

Dat is precies de kloof die AgentsRoom vult. Elke agent krijgt zijn eigen tegel, zijn status, zijn kleur. Een agent die wacht op jouw antwoord wordt rood en pingt je. Je stopt met scrollen in de verkeerde terminal, je kijkt naar het bord en je weet waar je heen moet.

Het ritme dat in de praktijk werkt

Hier is het ritme waarmee ik zou beginnen.

Begin met twee agents, op twee functies die geen bestanden delen. Wen aan de review-then-merge cyclus. Die cyclus, niet de code, wordt je echte taak.

Als die cyclus soepel aanvoelt, ga dan naar vier. Houd een strikte prioriteitenlijst van taken met grote impact aan, en leun zwaar op planmodus: je keurt het plan van de agent goed voordat hij een regel schrijft. Een plan dat vooraf is goedgekeurd, bespaart je later een pijnlijke review.

Het zoete punt ligt tussen 3 en 8 functies op dezelfde repo, met visueel toezicht. Daarboven, zelfs met een goed bord, wordt de review de bottleneck en verlies je het voordeel.

Wat je daadwerkelijk wint

Multi-agent is zinloos voor 95% van de kleine taken. Om een typefout te corrigeren of een knop toe te voegen, is een enkele agent voldoende, en het is sneller.

Waar het je week verandert, is bij groot werk. Je start drie onafhankelijke refactors op een avond, beoordeelt ze zodra ze binnenkomen, en de volgende ochtend heb je drie dagen werk klaar om te mergen.

Het geheim is niet het aantal agents. Het is altijd weten welke je nu nodig heeft. Los dat op, en de rest volgt.