Stel je voor: vrijdagmiddag, vier uur, je vraagt je AI-collega om vijf bugs uit het backlog op te lossen. Niet één voor één. Tegelijk. Maandagochtend ligt het werk in vijf afzonderlijke branches, klaar om door jou bekeken te worden. Dat is sinds 24 april geen demo-truc meer, maar een feature in Cursor 3.2. Voor het eerst kan een dev-team echt parallel coderen met agents. Het probleem is niet wat ze maken. Het probleem is wat jij ermee doet zodra ze klaar zijn.
Wat doet Cursor 3.2 nu precies?
Cursor heeft drie dingen tegelijk uitgebracht. Apart hadden ze elk een nieuwsbericht verdiend, samen vormen ze een ander dev-werk dan je gewend bent.
De eerste is /multitask. Tot vorige week was de Cursor-flow simpel: typen, wachten, lezen, typen, wachten. Met /multitask start Cursor meerdere subagents die jouw vijf prompts gelijktijdig oppakken. Heb je vier berichten al in de wachtrij staan? Eén commando en ze schakelen halverwege over naar parallel. Je kijkt niet meer naar één agent die werkt, je kijkt naar een dashboard waar er vijf bezig zijn.
De tweede is Worktrees in het Agents Window. Onder de motorkap gebruikt Cursor Git worktrees, een feature die al sinds 2015 in Git zit maar door bijna niemand werd gebruikt. Elke agent krijgt zijn eigen geïsoleerde checkout op een aparte branch. Ze stappen niet meer op elkaars voeten, want ze zitten letterlijk in andere mappen. Je klikt een agent open, je ziet zijn werk in een eigen branch, je test, je merget of je gooit hem weg.
Dit is alsof je vijf junior-developers in dezelfde kamer hebt zitten, elk met een eigen laptop en een eigen kopie van het project. Ze schreeuwen niet door elkaar, ze kunnen elkaars werk niet overschrijven, en jij loopt op het einde van de dag langs vijf bureaus om te zien wat er gemaakt is. Dat scenario was vroeger niet schaalbaar. Met worktrees wel.
De derde is Multi-root Workspaces. Eén agent-sessie kan nu in één keer werken aan frontend, backend en shared-libraries. Als je een microservices-architectuur hebt, of een monorepo over drie services verspreid: één prompt, gecoördineerde wijzigingen op alle plekken. Geen "switch nu naar de andere repo" meer.
Drie features. Eén nieuwe rol voor jou.
Wacht even, hoe verschilt dit van Claude Code?
Claude Code kan parallel agents draaien sinds vorig jaar, via /worktree en /best-of-n in de terminal. Dus is dit nieuws? Ja, en niet vooral omdat de techniek nieuw is.
Het verschil zit in waar de feature woont. Claude Code is een terminal-tool. Je tikt commando's, je ziet logs lopen, je beheert worktrees met de hand. Voor een senior-developer die graag in een TMUX-multiplexer werkt: prima. Voor de gemiddelde developer in een NL-bedrijf, die in VS Code of Cursor werkt en geen zin heeft in command-line yoga: niet bereikbaar.
Cursor 3.2 zet diezelfde technologie in een UI. Tiled layout, één klik om een agent naar de voorgrond te halen, drag-and-drop tussen panelen. De drempel zakt van "ik moet eerst een uur leren wat een worktree is" naar "ik klik op multitask en het werkt". Dat is het verschil tussen een demo voor early adopters en een feature die op maandagochtend in een NL-scrumteam wordt uitgeprobeerd.
En als je beide tools gebruikt, en dat is steeds vaker het geval bij NL-bedrijven die Claude Opus 4.7 en GPT-5.5 door elkaar inzetten: hetzelfde mentale model werkt nu overal. Eén branch per agent, jij regisseert.
Waar gaat dit fout?
Eerlijk: parallel agents klinkt mooi totdat je het uitprobeert. De auteur van een Cursor-review schreef vorige week wat de meeste mensen denken maar niet hardop zeggen: "Cursor hasn't fully answered all of this in public yet." En hij heeft gelijk. Drie problemen vallen meteen op.
Probleem één: file-conflicten. Als agent A en agent B allebei src/api/users.ts aanpassen, wat dan? Cursor zegt: ze zitten in aparte worktrees, dus geen conflict tijdens het werk. Maar bij merge-tijd is het jouw probleem. Vijf parallel-agents kunnen vijf merge-conflicten opleveren. Plotseling ben je een halve dag bezig met conflicten oplossen, in plaats van met code reviewen.
Probleem twee: dependency-management. Cursor zegt het zelf in de docs: "We do not recommend symlinking dependencies into the worktree." In gewone taal: elke worktree krijgt een eigen node_modules of .venv. Heb je een Node-project met 1.500 packages? Dan staat dat vijf keer op je schijf zodra je vijf agents draait. Cursor adviseert snelle package managers zoals bun, pnpm of uv om dit draaglijk te houden. Verstandig advies, maar een NL-team dat nog op npm install draait merkt opeens dat de MacBook na drie multitasks vraagt om een grotere SSD.
Probleem drie: cognitieve overhead. Eén agent volgen kost concentratie. Vijf agents tegelijk? Dat is geen tijdwinst, dat is een nieuwe vaardigheid. De review-belasting verschuift, schrijft het Axentia-blog terecht: "You'd type a request, watch it work, wait, type the next one." Die wachttijd was geen verloren tijd. Het was de tijd waarin je nadacht over wat de agent deed. Met vijf parallel werkende agents heb je die buffer niet meer.
Hoe regisseer je vijf agents tegelijk?
Hier wordt het werk anders. De rol verschuift van "code schrijven" naar "regie voeren". En regie is een vaardigheid waar de meeste developers nog geen training in hebben.
In de praktijk werkt het ongeveer zo. Je begint met een korte planning, een soort sprint-plan in het klein. Welke vijf taken zijn echt onafhankelijk? Een nieuwe API-endpoint, een refactor van een testbestand, een verouderde dependency upgraden, een typing-fout opschonen, een feature-flag verwijderen. Dat zijn vijf goede multitask-kandidaten. Allemaal in dezelfde controller? Dan moet je sequentieel werken, anders krijg je merge-hel.
Daarna stuur je /multitask met je vijf prompts. Cursor splitst ze over async subagents. Tijdens hun werk doe jij iets anders: een PR reviewen van een collega, een planning maken, koffie. Niet alle vijf agents tegelijk volgen, dat lukt niet. Vertrouw op de afronding.
Op het moment dat een agent klaar is, klik je hem open. Je test in zijn worktree, je leest de diff, je beslist: mergen, herwerken, weggooien. Voor de eerste paar weken is dit langzamer dan oude flow. Daarna sneller. Veel sneller.
Eén tip die nergens in de docs prominent staat maar die de meeste vroege Cursor-gebruikers leren: zet cursor.worktreeMaxCount op een redelijk getal en cursor.worktreeCleanupIntervalHours aan. Anders sta je over twee weken met dertig vergeten worktrees op je schijf en weet je niet meer welke welke was. Cursor heeft de feature, maar standaard staat hij er niet bovenop.
Wat dit betekent voor een NL-dev-team van vijf
Even concreet rekenen. Cursor Pro kost $20 per gebruiker per maand, ongeveer €22 inclusief Nederlandse BTW. Voor een dev-team van vijf personen praat je over €110 per maand, of €1.320 per jaar. Met Cursor Business op $40 per gebruiker zit je rond €264 per maand voor hetzelfde team. Niets vergeleken met een enkel ontwikkelaarsuur. Het kosten-argument is niet de blocker.
De blocker is anders. Een dev-team dat morgen /multitask aanzet zonder afspraken eindigt vrijdag met onduidelijke branches, dubbel uitgevoerde taken en een product-owner die niet weet wat klaar is. Je hebt iemand nodig die zegt: "Vandaag werken we via multitask aan deze vijf onafhankelijke tickets, niet meer." Iemand die vooraf bepaalt welke taken parallel kunnen, niet tijdens.
In NL-bedrijven is dat traditioneel een tech-lead of senior-developer. Voor een freelance-developer of een tweemansbureau is dat een nieuwe rol die je je oplegt: planner-eerst, schrijver-daarna. Voor consultancies die voor klanten bouwen, bijvoorbeeld de bureaus die ik dagelijks zie bij Digital Impact, is het de vraag of je de winst aan de klant doorberekent of in je marge stopt. Beide zijn legitieme antwoorden.
Wat je niet kunt doen, is doen alsof er niets verandert. Een team dat Cursor 3.2 inschakelt en gewoon doorwerkt zoals voorheen, gebruikt vijf procent van de feature en levert dezelfde output als vorige week. Dat is geld weggooien.
En dan die ene NL-realiteit waar geen Amerikaans review over schrijft: niet elke developer in je team wíl regisseur worden. De ene wil graag bouwen, niet aansturen. Wie de regie-rol oppakt en wie blijft programmeren is een teamgesprek waar je niet omheen kunt. Sommige bedrijven gaan dat gesprek wel hebben, andere doen alsof het er niet is. De eerste groep krijgt waar voor zijn $40 per maand.
Dit staat op de agenda komende weken
Drie dingen die ik in de gaten houd. Ten eerste: de eerste echte horror-stories over merge-conflicten en verloren werk. Die komen, ik weet alleen nog niet wanneer. Ten tweede: of Cursor ook het merge-probleem zelf gaat oplossen, bijvoorbeeld met automatische conflict-detectie tussen worktrees vooraf. Ten derde: hoe Anthropic gaat reageren met Claude Code, nu Cursor de UX een trap voor is. De multi-agent toolings-race is nog lang niet voorbij.
Voor nu: probeer /multitask deze week op vijf onafhankelijke tickets. Zet worktreeMaxCount op 10. En vraag jezelf eerlijk af welke rol jij over een halfjaar nog hebt: schrijver, of regisseur.
