TL;DR
- Wat: Vanuit Notion kun je nu direct taken toewijzen aan Cursor, die als cloud-agent code schrijft en een pull request opent.
- Waarom relevant: Projectbeheer en softwareontwikkeling groeien naar elkaar toe — ook als je zelf geen developer bent, verandert dit hoe je team werkt.
- Wat je ermee kunt: Bekijk of jouw ontwikkelworkflow baat heeft bij het koppelen van projectmanagement aan geautomatiseerde code-agents.
Ik stuitte op een aankondiging van Cursor die me even deed stilstaan. Je kunt nu vanuit Notion — de tool die heel veel teams gebruiken voor projectbeheer en documentatie — direct een AI-agent aan het werk zetten om code te schrijven en een pull request te openen. Geen tabblad wisselen, geen taak handmatig doorspelen. Gewoon: @cursor in een Notion-taak, en de agent gaat aan de slag.
Wat is er precies aangekondigd?
Cursor, de AI-aangedreven code-editor, heeft een integratie met Notion gelanceerd. Het idee is simpel: je schrijft een specificatie of taak in Notion, tagt @cursor, en een cloud-agent begint op de achtergrond te werken. Die agent draait op dezelfde modellen en infrastructuur als de Cursor-desktopapplicatie — het is dus geen uitgeklede versie.
Het resultaat? Een pull request (PR) — zeg maar een voorstel voor een codewijziging — die je hele team kan bekijken en beoordelen. De voortgang kun je volgen in Notion zelf, en als de agent klaar is, vind je de link naar de PR terug bij de taak.
Dit is gebouwd op de Cursor SDK, een toolkit die eind april 2026 in publieke bèta ging. Die SDK maakt het mogelijk om Cursor's AI-agents niet alleen in de editor te gebruiken, maar ook programmatisch in te zetten — in scripts, CI-systemen, dashboards, of dus: vanuit een tool als Notion.
Hoe past dit in het grotere plaatje?
Wat mij hier opvalt, is dat dit niet op zichzelf staat. Notion lanceerde in mei 2026 versie 3.5 van hun ontwikkelaarsplatform, met onder andere een External Agents API. Die API maakt het mogelijk om externe AI-agents — Cursor, maar ook Claude Code, Codex en Decagon — rechtstreeks vanuit Notion aan te sturen.
Dat betekent dat Notion zichzelf steeds meer positioneert als een soort commandocentrum. Niet alleen voor documentatie en projectplanning, maar ook als plek van waaruit werk daadwerkelijk wordt uitgevoerd door AI-agents. Ik vind dat een interessante verschuiving. Notion was altijd de plek waar je beschreef wat er moest gebeuren. Nu wordt het ook de plek waar je het laat gebeuren.
Voor de technische kant: de Cursor SDK ondersteunt inmiddels zogenaamde nested subagents. Dat houdt in dat een agent andere agents kan aansturen. Een review-agent kan bijvoorbeeld een test-schrijvende agent inschakelen, die op zijn beurt weer verder delegeert. Dat klinkt abstract, maar het principe is vergelijkbaar met hoe je in een bedrijf een projectleider hebt die deeltaken uitzet bij specialisten.
Wat betekent dit voor een ondernemer?
Laat ik eerlijk zijn: als je geen softwarebedrijf runt, is dit niet iets waar je morgen mee aan de slag gaat. Maar ik denk wel dat het belangrijk is om te begrijpen wat hier gebeurt, om twee redenen.
De afstand tussen idee en uitvoering wordt kleiner
Stel dat je als ondernemer een interne tool wilt laten bouwen — een dashboard, een koppeling tussen systemen, een kleine webapplicatie. Traditioneel schrijf je een briefing, stuur je die naar een developer, en wacht je. Met dit soort integraties wordt het denkbaar dat je een gedetailleerde specificatie in Notion zet, een AI-agent de eerste versie laat maken, en je developer alleen nog hoeft te reviewen en bij te sturen.
Ik zeg bewust "denkbaar" — we zijn er nog niet. De kwaliteit van wat zo'n agent oplevert hangt af van hoe goed je specificatie is, hoe complex de taak is, en of er bestaande code is waar de agent mee moet werken. Maar de richting is helder.
Projectmanagement en uitvoering smelten samen
Wat mij betreft is dit het grotere signaal: de scheiding tussen "plannen" en "doen" vervaagt. Tools als Notion waren altijd de planningskant. Tools als Cursor waren de uitvoeringskant. Nu praten ze rechtstreeks met elkaar, zonder dat een mens ertussen hoeft te zitten als tussenpersoon.
Voor MKB-bedrijven met een klein development-team kan dat betekenen dat je met dezelfde mensen meer gedaan krijgt. Niet omdat ze harder werken, maar omdat routinematig werk — een bugfix naar aanleiding van een taak, een eerste opzet van een feature — door een agent wordt opgepakt.
Waar zit de nuance?
Ik wil hier wel een kanttekening bij plaatsen. De Cursor SDK is nog in publieke bèta. Dat betekent dat er nog dingen veranderen, dat er grenzen zijn aan wat de agents aankunnen, en dat je als team moet investeren in het goed opzetten van zo'n workflow.
Daarnaast is er de vraag van vertrouwen: wil je een AI-agent zelfstandig pull requests laten openen in je codebase? Voor veel teams zal het antwoord zijn: alleen als er een mens meekijkt. En dat is precies hoe het nu is opgezet — de agent opent een PR, maar een teamlid reviewt en keurt goed. Dat vind ik een verstandige keuze.
Er is ook een auto-review-systeem in de SDK waarmee je kunt instellen welke acties een agent wel en niet zelfstandig mag uitvoeren. Je kunt bijvoorbeeld toestaan dat de agent bestanden leest, maar blokkeren dat hij productiedata aanraakt. Vergelijk het met een stagiair die je duidelijke kaders meegeeft.
Een stille verschuiving
Wat mij het meest raakt aan deze ontwikkeling is hoe geruisloos het gaat. Er is geen groot evenement, geen keynote met applaus. Het is een integratie, een SDK-update, een tweet. Maar de implicatie is dat de manier waarop software wordt gebouwd aan het veranderen is — en dat die verandering steeds dichter bij de dagelijkse tools van niet-technische teamleden komt.
Voor mij is dit vooral een signaal dat AI-agents niet langer iets zijn dat alleen developers raakt. Ze kruipen langzaam de workflows in van productmanagers, projectleiders en — uiteindelijk — ondernemers die gewoon willen dat er iets gebouwd wordt.