TL;DR
- Wat: Cursor 3.2 introduceert multi-root workspaces — één AI-agentsessie kan nu over meerdere mappen en repo's heen werken.
- Waarom relevant: Als je bedrijf software laat bouwen of zelf ontwikkelt, wordt het aanpassen van samenhangende systemen (frontend, backend, koppelingen) een stuk minder omslachtig.
- Wat je ermee kunt: Bespreek met je ontwikkelteam of jullie projectstructuur geschikt is om als multi-root workspace in te richten, zodat wijzigingen over meerdere codebases heen in één sessie kunnen.
Op 24 april 2026 bracht Cursor versie 3.2 uit, met daarin een feature die mij meteen opviel: multi-root workspaces. Eén AI-agentsessie die tegelijkertijd in meerdere mappen en repo's kan werken. Ik vind dat een interessante stap, vooral als ik denk aan de manier waarop veel bedrijven hun software hebben opgeknipt in losse onderdelen.
Wat zijn multi-root workspaces precies?
Een 'workspace' is in de context van een code-editor simpelweg de verzameling bestanden en mappen die je open hebt staan. Normaal gesproken werk je in één map — bijvoorbeeld je webshop-code óf je API-code, maar niet allebei tegelijk.
Met multi-root workspaces kun je meerdere mappen combineren in één werkruimte. Cursor's AI-agent ziet dan alle mappen als één geheel. Dat betekent: als je een aanpassing doet in een gedeelde bibliotheek, kan de agent meteen doorpakken naar de frontend die die bibliotheek gebruikt, zonder dat je handmatig hoeft te schakelen.
Concreet werkt het via een .code-workspace-bestand waarin je al je mappaden opsomt. Cursor indexeert vervolgens alles en past zelfs per map de juiste regels toe — elke repository kan zijn eigen .cursor/rules-bestand behouden.
Waarom is dat handig voor bedrijven?
Veel Nederlandse bedrijven — ook in het MKB — werken inmiddels met meerdere softwaresystemen die aan elkaar gekoppeld zijn. Denk aan een webshop die praat met een voorraadsysteem, een betaalmodule en misschien een apart klantportaal. In de softwareontwikkeling achter die systemen is het gebruikelijk dat elk onderdeel in een eigen repository leeft.
Dat geeft overzicht, maar het heeft ook een nadeel: als je een wijziging wilt doorvoeren die meerdere systemen raakt — bijvoorbeeld een nieuw veld toevoegen dat van de database via de API tot in de webshop moet verschijnen — dan moet een ontwikkelaar (of AI-agent) constant heen en weer schakelen tussen die losse codebases.
Stel dat je als ondernemer een aanpassing laat maken aan je bestelproces. Dat raakt misschien de frontend (wat de klant ziet), de backend (waar de bestelling verwerkt wordt) en een gedeelde bibliotheek (die beide systemen gebruiken voor validatieregels). Voorheen moest een AI-agent voor elk onderdeel apart worden aangestuurd. Nu kan dat in één sessie.
Wat zit er nog meer in Cursor 3.2?
De multi-root workspace was niet de enige toevoeging. Cursor 3.2 bracht ook twee andere features die in hetzelfde straatje passen:
Multitask met parallelle subagents
Met het commando /multitask kun je een grotere taak opsplitsen in kleinere deeltaken die tegelijkertijd worden uitgevoerd door aparte subagents. In plaats van dat de AI alles achter elkaar doet, werken meerdere agents parallel. Wat mij hier opvalt is dat dit precies aansluit bij hoe grotere ontwikkelteams al werken — taken verdelen en parallel oppakken — maar dan geautomatiseerd.
Verbeterde worktrees
Worktrees maken het mogelijk om op verschillende branches (versies van je code) tegelijk te werken, geïsoleerd van elkaar. Je kunt een branch op de achtergrond laten draaien en met één klik naar de voorgrond halen. Handig als je meerdere features tegelijk in ontwikkeling hebt.
Wat betekent dit voor de manier waarop software wordt gebouwd?
Ik vind het eerlijk gezegd fascinerend hoe snel de tooling rond AI-gestuurde softwareontwikkeling volwassen wordt. Een half jaar geleden was het al bijzonder dat een AI-agent code kon schrijven en aanpassen. Nu praten we over agents die meerdere codebases overzien, taken parallel uitvoeren en tussen branches schakelen.
Voor ondernemers die software laten bouwen — of dat nu maatwerk is of een intern team dat aan een SaaS-product werkt — heeft dit een concreet gevolg: de drempel om samenhangende wijzigingen door te voeren over meerdere systemen wordt lager. Waar een ontwikkelaar voorheen mentaal moest schakelen tussen contexten, houdt de AI-agent nu alles in één overzicht.
Dat wil niet zeggen dat je je ontwikkelaar kunt vervangen door een knop. De complexiteit van goed softwareontwerp verdwijnt niet — iemand moet nog steeds nadenken over architectuur, beveiliging en testbaarheid. Maar het routinewerk van "dit veld moet op drie plekken worden aangepast" wordt wel een stuk sneller afgehandeld.
Een kanttekening
Op het Cursor Community Forum is te zien dat multi-root workspaces al langer een veelgevraagde feature was, en dat er in eerdere versies nog problemen waren met padherkenning en contextbegrip in multi-root setups. Het is dus verstandig om even te testen hoe stabiel dit in de praktijk werkt voor jouw specifieke projectstructuur, vooral als je complexe of diep geneste repository-structuren hebt.
Een stap richting samenhangende AI-assistentie
Voor mij is dit vooral een signaal dat AI-tooling zich steeds meer aanpast aan hoe software er in de echte wereld uitziet: niet als één nette map met bestanden, maar als een verzameling systemen die met elkaar moeten samenwerken. Het feit dat een AI-agent nu die complexiteit kan overzien in plaats van er door gehinderd te worden, vind ik een betekenisvolle verschuiving. Niet spectaculair misschien, maar wel precies het soort verbetering dat in de dagelijkse praktijk verschil maakt.