Cursor Automations: een praktijkgids voor altijd-actieve code-agents

De echte bottleneck in softwareontwikkeling is niet langer code schrijven, want vrijwel elke developer in een team van welke grootte dan ook heeft nu minstens één agent die helpt met shippin. Code-agents zitten inmiddels in dagelijkse workflows ingebakken, en implementatie is niet meer het traagste deel van het systeem.

Cursor Automations is gebouwd om dat gat te dichten. In plaats van een agent steeds opnieuw te promoten, definieer je wanneer hij moet handelen. Er gaat een trigger af, instructies sturen wat hij doet, en hij draait zelfstandig. Er gaat een pull request open en het wordt gereviewd. Er komt een bugrapport binnen in Slack en het wordt afgehandeld. Een schema draait en er wordt een rapport gegenereerd.

In deze tutorial laat ik je zien hoe je Cursor-automations end-to-end opzet. Je bouwt twee automations: een PR-review en een geplande testcoverage-monitor. Onderweg leg ik uit hoe je instructies structureert en tools koppelt en MCP zodat de automations zich gedragen zoals we verwachten.

Eén opmerking voordat je begint. Automations is nog in ontwikkeling, en het dashboard op cursor.com/automations evolueert. Als een menulabel of knop is verschoven tegen de tijd dat je dit leest, blijft de onderliggende logica hetzelfde.

Wat zijn Cursor Automations?

Cursor-automations is een systeem om de cloud-agents van Cursor automatisch te laten draaien, getriggerd door events in je developmenttools of door een schema dat je definieert.

In de Agent-modus van Cursor, zoals behandeld in onze cursus Software Development with Cursor, start je elke sessie door een chat te openen en een prompt te typen, en draait de agent op je lokale machine zolang je erbij blijft.

Bij automations komt het startsignaal ergens anders uit je stack vandaan, en doet de agent zijn werk in een cloud-sandbox zonder dat jij het hoeft te monitoren.

Automations bevatten triggerevents die ik hieronder in de tabel heb samengevat, maar je kunt ook custom triggers instellen met webhooks. Een automation kan meer dan één trigger hebben en draait wanneer een van die triggers afgaat.

Elk van die triggertypen vervangt een moment op je dag waarop je anders iets had moeten opmerken, naar Cursor Agent-modus had moeten schakelen en om hulp vragen. 

De pull request-trigger is waarschijnlijk degene die je als eerste bouwt. Zo ziet de lifecycle van één PR eruit vóór en nádat je een automation toevoegt die je repository in de gaten houdt.

Wat er in die tweede kolom verandert, is niet de snelheid van een individuele stap, maar het feit dat jouw aandacht niet langer de beperkende factor is voor het hele proces.

Hoe Cursor Automations onder de motorkap werkt

Elke automation volgt onder de motorkap dezelfde pipeline. Wanneer de door jou gedefinieerde trigger afgaat, start Cursor een schone cloud-sandbox, kloont je repository erin en lanceert een agent die je instructies volgt met de geconfigureerde tools, MCP-verbindingen en het model. Die repository hoeft niet op GitHub te staan: repositories die gehost worden op Cursor Origin, Cursors eigen Git-forge, werken ook met cloud-agents en automations.

De agent verifieert zijn output voordat hij afrondt, en post het resultaat vervolgens waar je het hebt geconfigureerd, of dat nu een PR-comment, een Slack-bericht, een Linear-ticket is, of door een nieuwe pull request te openen.

Twee eigenschappen vormen elke automation die je bouwt:

• De sandbox draait volledig in Cursors cloud, niet op je laptop. Hij blijft draaien ook als jouw machine uitstaat.
• Elke run draait geïsoleerd. Meerdere automations kunnen parallel draaien zonder elkaar te storen. Cursor heeft ook aangegeven intern honderden automations per uur te draaien.

Er is ook een geheugen-tool, zoals in de preview hieronder, waarmee je automation state kan bewaren tussen runs. Dat wordt later belangrijk als we de geplande coveragemonitor bouwen.

Ik kom hierop terug wanneer je de geplande coveragemonitor bouwt.

Cursor Automations versus Agent-modus

Als je Cursor al regelmatig gebruikt, is de kernvraag wanneer je automations inzet in plaats van Agent-modus. Ik zou Automations niet gebruiken voor eenmalige taken. Ze zijn gemaakt voor werk dat zich herhaalt of afhangt van externe events.

Een vergelijking van de verschillen helpt als de keuze niet meteen duidelijk is:

Ik denk er zo over: als een taak begint met “wanneer” of “elke keer als”, dan hoort die in Automations.

Bijvoorbeeld: “Elke keer als er een PR wordt geopend, of wanneer er een bugrapport in #support binnenkomt, maak een Linear-ticket aan.” De trigger is terugkerend en voorspelbaar.

Als het begint met “nu moet ik deze module refactoren”, dan hoort het in Agent-modus. Jij bepaalt wanneer “nu” is.

Wil je Cursor eerst verkennen voordat je in automations duikt? Onze complete gids voor Cursor 2.0 leidt je door de Agents-interface, Composer en de multi-agent-workflow met een volledig Python-project.

Toegang tot het Automations-dashboard

Het Cursor-automations-dashboard staat op cursor.com/automations. Log in met je Cursor-account en je komt op het hoofddashboard zoals hieronder te zien is:

Laten we uiteenzetten wat we op het dashboard zien.

Samenvattingstegels of statusindicator bovenaan

De tegels geven een health-snapshot van alles wat je hebt gedraaid. Ze bevatten:

• Totaal aantal automations (hoeveel je er hebt geconfigureerd) 
• Geslaagd (runs afgerond, met een succesratio)
• Mislukt (runs die zijn gecrasht of geerrored)
• Run-geschiedenis (toont bij klikken je runvolume over tijd)

Het promptinvoerveld

Het invoerveld is de snelste manier om een nieuwe automation te maken zonder het volledige configuratieformulier te openen. We beschrijven de taak en Cursor genereert de automation-structuur.

Als je net begint, raad ik aan hier te starten. Bedenk wat je wilt automatiseren en schrijf dan een gestructureerde set instructies die de agent elke keer volgt wanneer de trigger afgaat. 

Zodra je op de pijl klikt, gebruikt Cursor die instructies om de automation voor je te genereren, waarbij naam, triggers en vereiste tools worden ingevuld.

Ik zou deze instructies niet behandelen als een normale prompt, maar als een specificatie die de agent elke keer draait. Ik kom hierop terug wanneer ik je later laat zien hoe je je eerste automation bouwt.

De wisselknop mijn / team en + nieuwe automation-knop

De toggle filtert tussen jouw automations en team-automations. 

De + New-knop opent een configuratiepagina om een nieuwe automation te configureren:

De + New Automation-knop is het langere alternatief voor het inline-invoerveld als je de trigger, instructies en toolverbindingen handmatig vanaf nul wilt configureren.

Je lijst met bestaande automations

De tabel toont alle automations die we hebben gemaakt, inclusief de gebruikte tools en de run-geschiedenis.

Klikken op een item opent de instellingenpagina en run-geschiedenis:

Sectie met voorgestelde templates

Onder de lijst met eerdere automations staat een grid met templatekaarten. Templates bieden kant-en-klare automations die je kunt aanpassen in plaats van from scratch te beginnen.

Cursor-automation-templates zijn de snelste manier om op dag één een automation te starten. Als je je eerste automation bouwt, raad ik aan te checken of er een template is die past bij wat je wilt automatiseren en daarvan uit te gaan.

De templates geven je ook een idee van hoe goede instructies eruitzien, en welke tool- of MCP-verbindingen je nodig hebt.

Account- en kostoverwegingen

Cursor-automations draaien op de cloudinfrastructuur van Cursor, wat cloud-agenttoegang vereist, inbegrepen in betaalde plannen. Elke run verbruikt credits op basis van modelgebruik en uitvoeringstijd.

Automations ondersteunen drie zichtbaarheidstiers volgens het permissiemodel:

• Privé: Alleen jij kunt het zien, en het wordt op jouw account gefactureerd.
• Zichtbaar voor team: Anderen kunnen je automations en run-geschiedenis bekijken, maar de facturatie blijft bij jou.
• Eigendom van team. De automation wordt gefactureerd op de gedeelde pool van het team en beheerd door teamadmins.

Het juiste tier kiezen is belangrijk, want het bepaalt van wiens credits de automation gebruikmaakt bij elke run. Houd experimenten privé totdat je de output vertrouwt. Zodra een automation onderdeel wordt van de workflow van je team, kun je hem naar een teamtier verplaatsen.

De belangrijkste faalmodus is een automation te breed en te vroeg laten draaien. Als hij op elke push in een drukke repo triggert, kan het gebruik snel oplopen zonder dat je het merkt. Begin smal, laat het een paar dagen lopen, bekijk hoe vaak het afgaat en beslis dan of je wilt uitbreiden of opschalen.

Je eerste Cursor-automation bouwen: geautomatiseerde PR-codereview

PR-codereview is de juiste eerste automation omdat de feedbackloop kort is en de gevolgen van een mislukte run laag zijn. Als de agent een nuttige comment plaatst, zien we dat meteen op de PR. Als het ernaast zit, negeren we het, en er wordt niets geshipt.

Ik begeleid je bij het bouwen van je eerste automation in vijf stappen:

1. Je GitHub-repository koppelen
2. De GitHub-triggers instellen
3. De agentinstructies schrijven (met een heldere structuur en wat te vermijden)
4. De GitHub Pull Request-commenttool toevoegen
5. De automation deployen

Stap 1: Je GitHub-repository koppelen

Voordat de agent een pull request kan reviewen, heeft hij toegang nodig tot een repository. Cursor krijgt toegang via een native GitHub App-integratie. Zonder die verbinding kan de automation-agent je code niet zien, PR-diffs niet lezen of feedback geven, dus werkt er weinig.

Als je dit nog niet hebt gedaan:

1. Installeer de Cursor GitHub App op je GitHub-account of -organisatie en geef toegang tot de repositories die je door automations wilt laten bewaken.
2. Verbind je GitHub-account in het dashboard onder het tabblad Integrations. 

Zodra je verbinding actief is, zijn je repositories beschikbaar wanneer je de automation-trigger configureert.

Stap 2: Je triggers instellen

Vanaf het automations-dashboard:

1. Klik op + New Automation om een automation te maken.
2. Geef de automation een naam. Je kunt hem PR Code Review – Open & Push – Comment Only noemen
3. Klik onder het gedeelte triggers op Add trigger en selecteer GitHub. Kies zowel PR opened als PR pushed als triggerevents.
4. Selecteer de doelrepository.

Als je stap 1 hebt overgeslagen of dit de eerste keer is dat je GitHub koppelt aan Cursor-automations, wordt je gevraagd te authenticeren. 

In de preview hieronder laat ik zien hoe je het configureert en de doelrepository selecteert zodra autorisatie is voltooid:

Let op: We kunnen meerdere triggerevents bundelen in één automation wanneer de instructies niet veranderen afhankelijk van welk event afging. Maar als de diepte of het doel van de review verandert per event, kies dan voor aparte automations.

De automation weet nu wanneer hij moet draaien. De volgende stap is hem vertellen wat hij moet doen.

Stap 3: Effectieve automation-instructies schrijven

De instructies zijn de grootste hefboom voor het leveren van nuttige output. De agent gebruikt ze om te leren wat “goed” is. Vage instructies zorgen voor inconsistente resultaten.

Voordat we de instructie schrijven, moeten we begrijpen wat we definiëren. We geven geen eenmalige prompt. We stellen een gedrag in dat de agent elke keer volgt wanneer de trigger afgaat. De kwaliteit van de automation hangt af van hoe duidelijk we dat gedrag specificeren.

Dit is de structuur die ik aanbeveel:

• Definieer de rol: Dit bepaalt perspectief en toon. Bijvoorbeeld: “Je bent een securityreviewer voor pull requests.”
• Definieer het doel: Wees duidelijk over hoe succes eruitziet. Bijvoorbeeld: “Detecteer en leg echte kwetsbaarheden helder uit.”
• Definieer de scope: Maak duidelijk waarop de agent zich moet richten. Bijvoorbeeld: “Review alleen toegevoegde of aangepaste code.”
• Schets de workflow: Geef een duidelijke aanpak. Bijvoorbeeld: “Inspecteer wijzigingen, traceer inputs en verifieer bescherming.”
• Stel uitsluitingen in: Zeg expliciet wat je wilt negeren om ruis te verminderen.
• Definieer gedrag en output. Hoe het moet handelen en hoe de resultaten eruit moeten zien.
• Stel grenzen: Wat het nooit mag doen.

Schrijf automation-instructies zoals je een runbook zou schrijven: specifiek, geordend, met duidelijke acceptatiecriteria en expliciete grenzen.

Voorbeeld van een goede instructie

Dit is de instructie die ik voor deze PR-codereview-automation gebruikte. Je kunt hem kopiëren naar je instructieveld, maar pas hem aan voor jouw usecase:

You are a code reviewer for pull requests triggered on PR open and push. Focus on identifying real issues that could introduce bugs, security vulnerabilities, or maintainability problems if merged. Review only added or modified code, and use surrounding context only when required to validate impact.

Check for:
- Logic errors such as incorrect conditions, edge cases, null handling, or wrong return values
- Security issues including injection, XSS, auth flaws, unsafe deserialization, or hardcoded secrets
- Contract changes such as modified APIs, response shapes, or schemas without corresponding updates
- Missing error handling or tests introduced by the change

Ignore style, formatting, naming preferences, and any pre-existing issues not introduced by this PR. Report only concrete findings with evidence from the diff, and post inline comments directly on changed lines. If no issues are found, respond: “Automated review complete: no issues found in this diff.” Do not approve, merge, push, or open PRs.Mogelijk gemaakt door

Hier staat de instructie in het invoerveld voor instructies:

Deze prompt is vereenvoudigd, maar volgt nog steeds een duidelijke en specifieke structuur. 

Voorbeeld van een slechte instructie

Vermijd vage instructies zoals:

Review this PR and give feedback on any issues you notice.Mogelijk gemaakt door

Zonder structuur, beperkingen en prioriteiten moet de agent raden wat “issues” betekenen, wat leidt tot generieke, oppervlakkige feedback in plaats van betrouwbare output.

Stap 4: Tools toevoegen

Open het tools-paneel in de automation-editor. Voor deze automation gaan we naar het GitHub-gedeelte en selecteren we de tool Comment on Pull Request. We zorgen dat PR-approval is uitgeschakeld, zoals in de preview hieronder, zodat de automation alleen kan reageren en niet kan goedkeuren.

Met de tool Comment on Pull Request kan de agent bevindingen terugplaatsen op de PR. Er is geen aparte verbinding nodig, omdat deze wordt aangedreven door dezelfde Cursor GitHub App die je in stap 1 hebt geautoriseerd.

Als we output naar andere services wilden sturen (zoals posten naar Slack), zouden we de bijbehorende tool selecteren of een MCP-verbinding toevoegen. Voor deze automation is de commenttool voldoende.

Stap 5: Je eerste run deployen en monitoren

Zodra triggers, instructies en tools zijn ingesteld, klikken we op Create om de automation op te slaan. Daarmee opent de instellingenpagina van de automation, zoals je hieronder ziet:

Omdat we de automation hebben gedeployed, moeten we een run triggeren en bekijken wat de agent produceert.

Open een draft-pull request in je gekoppelde repository. Dit triggert de PR opened-trigger, en binnen enkele seconden zou er een nieuwe entry in de Run-geschiedenis moeten verschijnen, zoals je hieronder ziet:

Open die run en check drie dingen:

• Uitvoeringstijd: hoe lang de run duurt. Dit verschilt per diff-grootte, model en instructiecomplexiteit.
• Toolcalls: welke files en tools zijn gebruikt? Als de agent ongerelateerde files leest, herzie je instructies.
• Output: wat er is teruggepost naar GitHub. Vergelijk dit met je instructies.

Hieronder staat een overzicht van de run van mijn automation. Je ziet dat hij zes minuten draaide, wat acties nam en de PR-review postte met de tool PostReviewCommentOnPr:

Hieronder staat een voorbeeldcomment die de agent op mijn PR plaatste:

Soms kan de output ernaast zitten, en als dat gebeurt, ligt het probleem meestal in de instructies. We passen de instructie aan die het gewenste gedrag aanstuurt, pushen een nieuwe commit om een nieuwe run te triggeren en beoordelen het resultaat.

Voor deze vroege runs beginnen we simpel om het risico laag te houden. In dit geval beperken we de automation tot alleen comments, zodat we veilig kunnen bevestigen hoe hij zich gedraagt. Zodra de output consistent is, zetten we hem in echt gebruik en koppelen we vervolgens andere tools naast GitHub om zijn mogelijkheden uit te breiden.

Meer tools koppelen met MCP

De PR-review-automation die we zojuist hebben gebouwd, draait op GitHub. Hij leest de diff en plaatst comments bij de pull request met de GitHub Comment on Pull Request-tool. Maar als we willen dat de agent meer doet dan code reviewen, moeten we andere tools koppelen. Daar is Model Context Protocol (MCP) voor.

MCP is een standaardinterface waarmee agents externe tools kunnen gebruiken zonder custom integraties. Zonder MCP zou elke tool zijn eigen setup en onderhoud vereisen. 

Met MCP kan de agent, zodra we een ondersteunde tool in het toolspaneel van de automation koppelen, die via dezelfde interface gebruiken.

MCP laat dezelfde automation meer doen en actie ondernemen in andere tools. Je PR-review-automation plaatst al comments op GitHub. Voeg Slack toe en hij kan updates in een kanaal posten. Voeg Linear toe en hij kan tickets aanmaken. Voeg Datadog toe en hij kan logs ophalen. Elke verbinding breidt uit wat de automation kan zonder de kernlogica te wijzigen.

Cursor-automations bevatten een ingebouwde set MCP-integraties zoals Slack, Linear, ClickUp, Datadog, Notion en meer. Omdat MCP een open standaard is, kunnen we elke compatibele tool op dezelfde manier koppelen.

Je vindt MCP onder Tools -> MCP server op de instellingenpagina van de automation. Klik op de knop + New Connection om te browsen, installeer en koppel vervolgens de tool die je nodig hebt.

Hier is een preview die laat zien hoe je ze toevoegt:

In de volgende sectie laat ik zien hoe je een Slack MCP-verbinding toevoegt aan de PR-codereview-automation.

Een Slack MCP-verbinding toevoegen

GitHub zorgt ervoor dat de automation onze code leest en becommentarieert. Slack zorgt ervoor dat hij met het team praat.

Klik vanuit het toolspaneel op Add Tool or MCP, selecteer MCP Server en kies vervolgens +New Connection. Zoek in het paneel dat opent naar Slack en selecteer de Slack MCP-server. 

Slack is vaak al geïnstalleerd, maar zo niet, installeer het en volg de OAuth-flow om je werkruimte te autoriseren. Zodra verbonden, verschijnt het in je toolspaneel, zoals ik in het overzicht hieronder laat zien:

We kiezen tijdens de verbinding geen doelkanaal. De MCP geeft de automation-agent werkruimteniveau-toegang tot alle publieke kanalen. We bepalen precies waar hij post door het kanaal in de instructies te noemen, bijvoorbeeld: "Stuur een Slack-bericht naar #pr-alerts als er een critical issue is gevonden."

Let op: Slack MCP werkt alleen met publieke kanalen, en het doelkanaal moet de Cursor-bot hebben uitgenodigd voordat de automation kan posten. Na de OAuth-flow zou er een Cursor-bot in je Slack-werkruimte moeten verschijnen. Ga naar het kanaal en voer /invite @Cursor uit om hem toe te voegen.

Als je de @Cursor bot niet ziet, is de autorisatie mogelijk mislukt. Ga naar dashboard ->  integrations, klik op Manage naast Slack en doorloop de OAuth opnieuw.

Wil je dieper in MCP duiken? Onze FastMCP 2.0-tutorial laat zien hoe je vanaf nul een custom MCP-server bouwt en integreert in Cursor.

Triggers en tools combineren

Met de Slack MCP verbonden kunnen we de PR-codereview-automation uitbreiden. We behouden dezelfde GitHub PR-triggers en de GitHub comment on PR-tool. Maar nu kan de agent ook kritieke bevindingen naar #pr-alerts posten via de Slack MCP.

Voeg dit blok toe aan het einde van de instructies die we in stap 3 schreven bij het bouwen van de eerste automation:

Additionally:  
If you find any issue at severity high or critical, send a Slack message to #pr-alerts containing: the PR title, the author, a one-sentence description of the most severe finding, the severity label, and a link to the PR. If no high or critical issues are found, do not post to Slack at all.Mogelijk gemaakt door

Die laatste regel is belangrijker dan hij lijkt. Zonder die regel kan #pr-alerts zich snel vullen met “all clear”-meldingen en zijn waarde verliezen. Voor mij is aangeven wanneer de agent niet moet handelen net zo belangrijk als wanneer hij dat wel moet.

Hieronder zie je de outputs van een testrun van een PR in mijn repository.

Een weergave van een comment die de automation-agent plaatste bij het openen van de PR in mijn GitHub (via de GitHub PR-commenttool):

Een weergave van de Slack-notificatie die de automation-agent naar mijn #pr-alerts Slack-kanaal stuurde voor dezelfde run via de Slack MCP-verbinding:

Op dit punt heb je een werkende automation die elke PR reviewt, comments op GitHub plaatst en kritieke issues naar Slack opschaalt. Dat is het kernpatroon. 

In de volgende sectie bouwen we een tweede automation volgens dezelfde flow: een trigger, instructies en de tools die de agent nodig heeft om de output te produceren.

Een tweede automation bouwen: geplande testcoveragemonitor

De PR-codereview-automation die we hebben gebouwd, reageert op GitHub-events. Geplande automations werken anders. We definiëren wanneer de agent moet draaien, en hij voert dat op dat tijdstip uit, ongeacht wat er in de repo is gebeurd.

De automation die we hier bouwen, draait elke dag om 9.00 uur, bekijkt code die de afgelopen 24 uur naar de main-branch is gemerged, identificeert gebieden met onvoldoende testcoverage en post een samenvatting naar #repo-coverage op Slack.

Een cron-trigger en tool instellen

Vanaf het automations-dashboard:

• Klik op + New om een nieuwe automation te maken.
• Noem hem Daily Coverage Check – Main Branch.

De trigger configureren

• Selecteer onder Triggers Scheduled.
• Kies Every... > Day en stel de tijd in op 9:00 AM.
• Als je een ander formaat nodig hebt, zoals alleen weekdagen, gebruik dan Custom (cron)
• Omdat geplande triggers geen repository afleiden, selecteer je de doelrepository en branch (main).

De tool Send to Slack toevoegen

Hier introduceer ik de tool Send to Slack die beschikbaar is in de automation-instellingen. Deze verschilt van de eerder gebruikte Slack MCP. We gebruiken hem om berichten naar een specifiek kanaal te sturen, terwijl de Slack MCP toegang op werkruimteniveau biedt en de agent naar elk kanaal laat posten dat in de instructies is gedefinieerd.

Om de tool Send to Slack toe te voegen, selecteer je hem in het toolsgedeelte en specificeer je het doelkanaal voor de output van de automation. Zo zou het eruit moeten zien:

De instructies voor een geplande taak schrijven

In de PR-review-automation reageert de agent op een pull request en post feedback. Bij geplande automations is er geen inkomende input. De agent start de taak zelfstandig, dus we moeten duidelijk zijn over waar te beginnen, wat te checken en wat te posten.

De geheugen-tool is hier belangrijk. De coverage-vergelijking werkt alleen als de agent de cijfers van gisteren kent. We moeten aangeven welke key hij moet lezen, wat te vergelijken en wat op het einde op te slaan. Als we dat onduidelijk laten, kunnen resultaten tussen runs variëren.

Dit is de instructieset die ik gebruikte:

You are a daily test coverage monitor for this repository. Run every day at 9 AM on the main branch.
Identify PRs merged to main in the last 24 hours.For modified files, check if changed code paths have test coverage.Run tests with coverage:  pytest --cov=src --cov-report=json.Parse the report and record the overall coverage and per-file coverage for modified files.Read yesterday's coverage from memory (daily_coverage_latest: If none exists, post a green status and skip comparison.Compare coverage: If it drops by >1%, post a warning to #repo-coverage Slack Channel with today's value, yesterday's value, delta, and affected files. Otherwise, post a green status with today’s value and delta.Save today’s coverage to memory (daily_coverage_latest).Mogelijk gemaakt door

Hieronder laat ik je de outputs zien van mijn geplande automation om 9.00 uur.

Hier is het overzicht van de automation. In mijn geval bleef de coverage boven de drempel, dus postte hij alleen een groene status in het Slack-kanaal:

Hier is het Slack-bericht. Dit is de eerste testcoverage-run, dus ik verwachtte niet veel. Je ziet ook dat de run in het geheugen is opgeslagen als baseline voor de volgende vergelijking:

Als ik naar de run hierboven kijk, vallen twee delen van de instructies op. 

Ten eerste definieert hij zowel het waarschuwingspad als het groene pad. Het groene pad is vereist. Als we alleen definiëren wat er gebeurt wanneer er iets mis is, blijft de automation stil wanneer alles in orde is. In een monitoringkanaal voelt die stilte als een failure. De groene status bevestigt dat de run is voltooid.

Ten tweede zijn de geheugenlees- en -schrijfopdrachten expliciet. De agent heeft een geheugen-tool, maar zal die niet betrouwbaar gebruiken voor vergelijkingen tenzij hij daartoe wordt geïnstrueerd. Als we dit impliciet laten, kunnen resultaten per run verschillen. We moeten precies specificeren welke key gelezen wordt, wat te vergelijken en wat op te slaan.

In de afbeelding hieronder zie je dat de agent mijn automation heeft opgeslagen:

In de volgende sectie behandel ik veelgemaakte fouten en best practices om meer uit je automations te halen.

Cursor Automations: veelgemaakte valkuilen en best practices

De meeste problemen met automations komen voort uit een kleine set voorspelbare fouten. Ze zijn eenvoudig te voorkomen als je ze kent, maar kostbaar om te debuggen als je dat niet doet.

Veelgemaakte fouten om te vermijden

• Vage instructies: Dit is een veelvoorkomende faalmodus. Alles als “review de code”, “check op issues” of “vat wijzigingen samen” dwingt de agent te raden wat je bedoelt, wat leidt tot inconsistente output. Als een zin een werkwoord heeft zonder duidelijke objecten of voorwaarden, herschrijf hem dan vóór deployment.
• Te brede scope:. Combineer geen securitychecks, stijlchecks, performancechecks en testcoverage in één automation. Dit maakt failures lastiger te debuggen. Smalle automations zijn beter te begrijpen. 
• Een calibratiefase overslaan: Zet instellingen zoals auto-approve of auto-merge niet vroeg aan. Maak vroege runs op zijn minst comment-only. Deze runs onthullen edgecases in je codebase. Zie deze fase als validatie vóór productie.
• Slack-kanaalconfiguratie: Slack-triggers werken alleen op publieke kanalen, dus als een Slack-automation niets lijkt te doen, controleer dan de zichtbaarheid van je kanaal en zorg dat de @Cursor-bot in dat kanaal is uitgenodigd.

Best practices voor betrouwbare automations

• Eén taak per automation: Elke automation moet één duidelijk gedefinieerde taak doen. Dit maakt failures makkelijker te isoleren en fixes eenvoudiger toe te passen.
• Begin vanuit een schone staat: Commit je working tree voordat een agent wijzigingen maakt, zodat je altijd een duidelijke diff hebt om mee te vergelijken.
• Zie de eerste runs als calibratie: Verwacht in het begin wat ruis, bekijk de outputs, pas instructies aan en run opnieuw tot het gedrag stabiliseert.
• Gebruik duidelijke, beschrijvende namen: Namen als PR Code Review – Open & Push – Comment Only zijn nuttiger dan generieke labels als je ze later weer bekijkt.
• Bekijk de run-geschiedenis vroeg en vaak: In de eerste weken bouwt dit intuïtie op voor wat normaal gedrag is, waardoor issues later makkelijker te spotten zijn.

Tot slot

Cursor Automations verplaatst agentisch coderen van een interactieve workflow naar een event-gedreven systeem. In Cursor Agent-modus openen we een chat en promoten we de agent om code te reviewen, functies te refactoren of issues te onderzoeken. In automations starten we het werk niet direct zelf. Triggers zoals een pull request, een Slack-bericht of een schema starten de agent automatisch, en die rondt de taak zelfstandig af. De belangrijkste verschuiving is dat routinewerk van een handmatige wachtrij naar een systeem gaat dat op de achtergrond draait.

In dit stuk heb ik je laten zien hoe je twee automations bouwt: een PR-codereview en een geplande coveragemonitor. Ze zijn bewust eenvoudig, maar geven je het juiste startpunt omdat ze laten zien hoe het systeem zich gedraagt zonder extra complexiteit. Zodra je vertrouwd bent, kun je geavanceerde workflows implementeren.

Het kernidee is: begin met één smalle automation, schrijf instructies als een runbook, draai hem in een laagrisicomodus en breid pas uit als hij betrouwbaar werkt. De waarde komt minder uit hoeveel automations je bouwt en meer uit hoe consistent elke automation is.

Om voort te bouwen op wat we in dit stuk hebben behandeld, zijn dit onze aanbevolen vervolgstappen:

• Verdiep je begrip van de Agent-modus en de bredere Cursor-workflow met onze cursus Software Development with Cursor.
• Bekijk wat er nieuw is in Cursor 3.0.