TL;DR
- Wat: AI-codetool Cursor is direct te gebruiken vanuit Jira: wijs een ticket toe aan Cursor of tag @Cursor in een comment, en een cloud-agent maakt een merge-ready pull request.
- Waarom relevant: Softwareontwikkeling wordt steeds meer een taak die je kunt delegeren aan AI — ook als je een klein development-team hebt.
- Wat je ermee kunt: Bespreek met je ontwikkelteam of en hoe AI-agents een plek kunnen krijgen in jullie ontwikkelworkflow.
Ik viel deze week over een aankondiging van Cursor, de AI-code-editor die de laatste maanden steeds vaker opduikt in tech-kringen. Het bedrijf meldde dat hun AI-agent nu direct vanuit Jira te gebruiken is — het projectmanagementtool dat veel ontwikkelteams dagelijks gebruiken. Dat klinkt misschien als een technisch detail, maar ik denk dat het voor ondernemers met een development-team iets groters signaleert.
Wat is er precies aangekondigd?
Cursor heeft een integratie met Jira gelanceerd waarmee je hun AI-agent op twee manieren kunt inzetten. De eerste: je wijst een Jira-ticket direct toe aan Cursor, zoals je dat normaal aan een ontwikkelaar zou doen. De tweede: je tagt @Cursor in een comment op een ticket met specifieke instructies.
In beide gevallen pakt een zogeheten cloud agent — een AI-systeem dat autonoom op een eigen virtuele machine draait — het werk op. Die agent leest de titel, beschrijving en comments van het ticket, bekijkt de repository-instellingen van je team, en gaat aan de slag. Het eindresultaat: een pull request (een codevoorstel dat klaar is om samengevoegd te worden met de bestaande codebase) die je team kan reviewen.
Volgens de documentatie van Cursor kun je de agent vragen om bugs te fixen, features toe te voegen, tests bij te werken, of een taak te onderzoeken. Je kunt in het comment zelfs aangeven in welke repository en op welke branch de agent moet werken.
Waarom dit meer is dan een technische update
Wat mij hier opvalt, is de verschuiving in hoe je over softwareontwikkeling kunt nadenken. Tot voor kort was een AI-codetool iets dat een individuele ontwikkelaar gebruikte — als slimme assistent in de editor. Nu wordt die AI een "teamlid" in je projectmanagementtool.
Stel dat je als ondernemer een klein ontwikkelteam hebt van drie of vier mensen. Jullie werken met Jira om taken te verdelen. Een deel van die taken is relatief voorspelbaar: een bugfix hier, een testcase daar, een kleine aanpassing aan een bestaande feature. Als een AI-agent dat soort werk kan oppakken — inclusief het opleveren van een codevoorstel dat je team alleen nog hoeft te reviewen — dan verandert dat de capaciteitsplanning.
Ik wil hier eerlijk zijn: ik heb dit zelf niet in de praktijk getest. Maar het idee dat je een Jira-ticket kunt toewijzen aan een AI die vervolgens zelfstandig code schrijft, tests draait en een pull request aflevert, vind ik eerlijk gezegd bijzonder.
Hoe ver is Cursor hiermee?
Dit is niet het eerste platform waarop Cursor's cloud agents actief zijn. Het bedrijf had eerder al integraties met GitHub en Slack aangekondigd, waarbij je via een @Cursor-mention in een Slack-kanaal of een GitHub-issue een agent kon starten. De Jira-integratie past in een breder patroon: Cursor positioneert zijn agents als "always-on" medewerkers die reageren op events in verschillende ontwikkeltools.
Een opvallend cijfer dat ik tegenkwam: volgens meerdere bronnen wordt zo'n 30 tot 35 procent van Cursor's eigen interne pull requests volledig door AI-agents gemaakt. Dat is een aanzienlijk deel. Het zegt iets over het vertrouwen dat het bedrijf in zijn eigen product heeft — al moet je daar wel bij aantekenen dat een AI-tool die door ontwikkelaars is gebouwd, waarschijnlijk beter presteert op de eigen codebase dan op een willekeurig ander project.
Wat kan de agent concreet?
Op basis van de beschikbare documentatie kan de cloud agent:
- De codebase clonen en dependencies installeren
- Code schrijven op basis van de taakomschrijving
- Tests draaien
- Merge-conflicten oplossen
- Een merge-ready pull request opleveren
- Voortgang terugkoppelen via comments op het Jira-ticket
Dat klinkt indrukwekkend, maar de gebruikelijke kanttekening geldt: de kwaliteit van de output hangt sterk af van hoe goed de taakomschrijving is en hoe gestructureerd de bestaande codebase eruitziet.
Wat betekent dit voor een ondernemer met een development-team?
Kun je je voorstellen wat dit betekent als je een team aanstuurt dat continu een backlog vol relatief eenvoudige taken heeft? Denk aan het schrijven van unit tests, het fixen van bekende bugs, of het doorvoeren van kleine UI-aanpassingen.
Ik denk dat de waarde hier niet zit in het vervangen van ontwikkelaars, maar in het verschuiven van hun werk. Als routinetaken door een agent opgepakt worden — onder supervisie, want iemand moet die pull request nog steeds reviewen — dan kan je team zich richten op complexer werk. Architectuurbeslissingen, klantgesprekken, strategische keuzes over de productroadmap.
Een paar praktische overwegingen
Voor je hier enthousiast mee aan de slag gaat, zijn er een paar dingen om over na te denken:
- Code-review blijft essentieel. Een AI-agent levert een voorstel op. Je team moet dat voorstel kritisch bekijken voordat het in productie gaat. Dat kost ook tijd.
- Taakomschrijving wordt belangrijker. Als een mens een vaag ticket krijgt, stelt die vragen. Een AI-agent interpreteert en gaat aan de slag. Hoe beter je beschrijft wat je wilt, hoe bruikbaarder het resultaat.
- Beveiliging en toegang. De agent heeft toegang nodig tot je codebase. Dat vraagt om een bewuste keuze over welke repositories je openstelt en hoe je dat beveiligt.
- Kosten. Cursor's cloud agents zijn onderdeel van hun betaalde plannen. Het is verstandig om te berekenen of de tijdwinst opweegt tegen de abonnementskosten voor jouw specifieke situatie.
Een stille verschuiving in softwareontwikkeling
Wat mij betreft is dit het soort ontwikkeling dat niet met een knal komt, maar dat je over zes maanden terugkijkend pas echt opvalt. De grens tussen projectmanagement en uitvoering wordt dunner. Een ticket toewijzen aan een AI-agent voelt nu nog nieuw, maar ik vermoed dat het snel normaal wordt — net zoals we gewend zijn geraakt aan automatische tests en continuous integration.
Voor mij is dit vooral een signaal dat AI-tools zich steeds dieper nestelen in bestaande werkprocessen. Niet als losstaand experiment, maar als onderdeel van de tools die teams al dagelijks gebruiken. En dat maakt het, wat mij betreft, relevanter dan menig standalone AI-demo.