Slimmer werken met Cursor: zo haal je er echt alles uit

Als je veel code schrijft, kan Cursor je echt lucht geven. Niet door alles uit handen te geven, maar door het samen te doen. Jij bepaalt de richting, Cursor helpt je met het uitvoerende werk.

Zie Cursor als een slimme maar onervaren collega. Iemand die razendsnel typt, nooit moe wordt, maar wel duidelijke uitleg nodig heeft. Hoe beter jij uitlegt wat je wilt, hoe beter de uitkomst.

Hier loop ik met je langs hoe je Cursor handig inzet bij grotere taken, testen, debuggen en het opruimen van je code. Met voorbeelden die je zo op je eigen project kunt toepassen. Zodat jij minder tijd kwijt bent aan gedoe en meer aan de stukken die je zelf leuk vindt.

Werken met YOLO-modus zonder stress

YOLO-modus klinkt alsof je je hele project uit handen geeft, maar zo hoeft het niet te zijn. Het is vooral een stand waarin Cursor zelf commando’s mag draaien om te checken of je code echt werkt. Denk aan tests draaien, builds starten en nieuwe bestanden of mappen aanmaken.

Je zet YOLO-modus aan in de instellingen en daarna kun je vrij precies aangeven wat Cursor wel en niet mag doen. In je prompt kun je bijvoorbeeld zeggen dat testcommando’s altijd oké zijn, net als simpele build-opdrachten en het aanmaken van nieuwe bestanden. Zo houd je controle, maar hoeft Cursor niet steeds om toestemming te vragen.

Een praktische manier om dit te gebruiken is Cursor zelf tsc laten draaien. Als er dan een buildfout opduikt, kan Cursor zelf op zoek naar de oorzaak, de code aanpassen en het opnieuw proberen. Jij hoeft dan niet elk foutje één voor één na te lopen, maar je kijkt mee of de richting nog klopt.

Laat YOLO-modus niet urenlang onbewaakt zijn gang gaan. Zie het als een automatische hulp die jij af en toe bijstuurt. Zodra je merkt dat het te veel aan het gokken is, grijp je in en stuur je het bij met een nieuwe, duidelijke opdracht.

Wil je het rustig opbouwen, begin dan met een paar veilige commando’s. Laat Cursor bijvoorbeeld alleen tests draaien en simpele typefouten fixen. Als dat goed gaat, kun je stap voor stap meer toestaan.

• Begin met alleen testcommando’s toestaan
• Voeg daarna buildcommando’s toe
• Sta pas later toe dat er nieuwe bestanden worden aangemaakt
• Controleer regelmatig de diffs voordat je iets merge’t

Complexe taken aanpakken met tests eerst

Voor kleine functies kan Cursor vaak in één keer iets bruikbaars neerzetten. Maar zodra het wat ingewikkelder wordt, merk je dat de eerste versie meestal niet helemaal klopt. Dan beland je snel in een rondje van code genereren, handmatig testen, terug naar Cursor en weer opnieuw.

Je maakt dat proces veel sterker door Cursor eerst tests te laten schrijven. Stel dat je een functie nodig hebt die een markdown-string omzet naar HTML. In plaats van alleen die functie te vragen, zeg je erbij: schrijf eerst tests, dan de code, draai de tests en verbeter de code tot alle tests slagen.

Cursor maakt dan zelf een testbestand aan, kijkt wat er in je package.json staat en kiest een passend testcommando. Daarna schrijft het de implementatie, draait de tests en gaat net zo lang door tot alles groen is. Jij kijkt mee of de tests logisch zijn en vult zelf nog een paar extra gevallen aan die voor jouw project belangrijk zijn.

Zo voelt je werk minder als eindeloos fouten zoeken en meer als kwaliteit bewaken. Cursor doet het vuile werk, jij bepaalt wat er getest wordt en wat het gewenste gedrag is. Zeker bij functies met veel randgevallen scheelt dat een hoop tijd.

Je kunt dit patroon eigenlijk op bijna elke grotere wijziging toepassen. Nieuwe API-endpoints, ingewikkelde berekeningen, data-transformaties, noem maar op. Hoe meer je Cursor dwingt om via tests te werken, hoe minder verrassingen je later tegenkomt.

1. Beschrijf eerst in gewone taal wat de functie moet doen
2. Laat Cursor daar tests bij schrijven
3. Check de tests en vul zelf ontbrekende gevallen aan
4. Laat Cursor de implementatie schrijven en de tests draaien
5. Herhaal tot alle tests groen zijn en de code leesbaar is

Bouwen op bestaande tests en je code robuuster maken

Als je al een set tests hebt, kun je Cursor daar mooi op laten voortbouwen. In plaats van zelf nieuwe scenario’s te verzinnen, laat je Cursor extra gevallen toevoegen. Daarna laat je het de code aanpassen tot alles weer slaagt.

Stel dat je een converter of compiler hebt die soms crasht op bepaalde invoer. Je haalt de mislukte gevallen uit je logs en plakt die in Cursor. Vervolgens vraag je: maak voor deze invoer een test die nu faalt, pas de code aan en herhaal tot alle nieuwe tests slagen.

Als je dat elke paar dagen doet, bouw je langzaam een steeds sterkere testset op rond echte problemen. Je code wordt daar minder breekbaar van, zonder dat jij alles met de hand hoeft uit te zoeken. Vooral bij projecten die al wat ouder zijn, helpt dit om stap voor stap betrouwbaarder te worden.

Let er wel op dat Cursor niet altijd snapt wat voor jou inhoudelijk belangrijk is. Soms schrijft het een test die technisch klopt, maar niet past bij hoe jij de functie bedoeld had. Neem dus de tijd om nieuwe tests even door te lezen en zo nodig bij te sturen.

Je kunt Cursor ook vragen om bestaande tests op te schonen. Bijvoorbeeld door dubbele scenario’s samen te voegen of namen duidelijker te maken. Dat maakt het later weer makkelijker om zelf te begrijpen wat er getest wordt.

Visueel aanpassen van AI-code met je eigen ontwerpregels

AI kan prima een component genereren dat netjes door alle tests komt. Dat betekent alleen niet dat het er ook uitziet zoals jij wilt. Vaak klopt de logica, maar stoort er visueel net iets, zoals spacing of uitlijning.

Met een visuele laag bovenop Cursor kun je dat een stuk soepeler maken. In combinatie met een tool als Fusion, die direct in je codebase werkt, kun je een component laten genereren, de tests laten draaien en daarna het ontwerp op het scherm aanpassen. Je sleept bijvoorbeeld kaarten wat verder uit elkaar en de onderliggende code wordt automatisch bijgewerkt.

Het fijne is dat zo’n visuele laag je bestaande ontwerpregels kent. Als jij vaste spacings, kleuren en componenten hebt, gebruikt het die in plaats van willekeurige CSS. Je hoeft dan niet meer in de code te rommelen om een marge van 12 naar 16 pixels te zetten, maar je kiest gewoon een stap uit je eigen ontwerpsysteem.

Dat scheelt vooral tijd bij het laatste stukje finetunen. Je laat Cursor de basis neerzetten en de logica kloppend maken. Daarna richt jij je op hoe het er voor de gebruiker uit moet zien, zonder dat je elke kleine visuele wijziging met de hand in de code hoeft te typen.

Merk je dat Cursor steeds dezelfde visuele fout maakt, leg dat dan vast in je ontwerpregels of componenten. Hoe meer je standaardiseert, hoe makkelijker Cursor zich daaraan kan houden. Je maakt het jezelf dan op de lange termijn een stuk makkelijker.

TypeScript-fouten en pre-PR checks laten fixen

Je kent het vast: je hebt lekker doorgecodeerd, alles lijkt te werken, en dan draait je build en vliegt je terminal vol met TypeScript- en lintfouten. Meestal zijn het kleine dingen, maar het kost tijd en energie om alles na te lopen. Zeker als je project groot is.

Met Cursor kun je dat opruimwerk grotendeels uitbesteden. Je kunt simpelweg zeggen: ik heb buildfouten, draai het buildcommando, fix alle fouten en herhaal tot de build slaagt. Cursor leest de foutmeldingen, past de code aan en probeert het opnieuw.

Handig is om in je project een snel commando te hebben dat je altijd draait voordat je een pull request maakt. Noem het bijvoorbeeld pre-PR en laat het dingen doen als tsc, Prettier en ESLint. Daarna vraag je Cursor om dat commando te draaien, alle meldingen op te lossen en nog een keer te draaien tot alles schoon is.

Bij grotere projecten scheelt dat echt veel tijd. Je hoeft niet elke vergeten import of typefout zelf op te sporen. Wel is het slim om de diffs even door te lopen, zodat je zeker weet dat Cursor geen rare aannames heeft gedaan in gevoelige stukken code.

Je kunt Cursor ook vragen om een korte uitleg bij een fout te geven. Bijvoorbeeld: leg in simpele taal uit waarom deze TypeScript-fout ontstaat en wat de veiligste fix is. Dat helpt je om zelf beter te begrijpen wat er misging, in plaats van alleen de fout weg te poetsen.

Moeilijke bugs aanpakken met logs en iteratief verbeteren

Voor lastige bugs is alleen naar de code kijken vaak niet genoeg, ook niet voor Cursor. Dan helpt het om meer zicht te krijgen op wat er tijdens het draaien gebeurt. Daar kun je Cursor goed bij inzetten.

Je kunt bijvoorbeeld vragen: voeg logregels toe op de belangrijke plekken, zodat we beter zien wat er misgaat, ik draai de code en geef je daarna de logs terug. Cursor voegt dan logregels toe op logische punten in de code. Jij draait het programma, kopieert de loguitvoer en plakt die weer terug in Cursor.

Daarna kun je vragen: op basis van deze logs, wat denk je dat de oorzaak is en hoe lossen we dit op. Cursor gebruikt dan de echte uitvoer om gerichter te zoeken, in plaats van alleen te gokken op basis van de broncode. Dat werkt vooral goed bij fouten die alleen onder bepaalde omstandigheden optreden.

Vaak heb je een paar rondes nodig. Nog wat extra logs, andere variabelen loggen, nog een keer draaien. Zie Cursor als een junior ontwikkelaar die snel logregels kan plaatsen en helpen met interpreteren, terwijl jij beslist welke fix logisch is.

Als je merkt dat dezelfde foutsoort vaker terugkomt, kun je Cursor vragen om daar een aparte testset voor te maken. Zo voorkom je dat je later weer in dezelfde valkuil stapt. Je bouwt dan langzaam een soort vangnet op rond de zwakke plekken van je code.

Sneller werken met Command K, Command I en de terminal

Cursor heeft een paar sneltoetsen die je leven echt makkelijker maken als je ze eenmaal gewend bent. Met Command K kun je snel een stukje geselecteerde code laten aanpassen. Je selecteert bijvoorbeeld een component en zegt: maak alle lettertypes kleiner behalve de hoofdtekst, en Cursor past alleen dat blok aan.

Command I opent de agent met de geselecteerde code in de context. Dat is handig als je een gesprek wilt voeren over een specifiek stuk. Bijvoorbeeld: leg uit wat hier gebeurt en maak het simpeler, of herstructureer dit zodat het beter testbaar is.

Het verschil is dat Command K vooral is voor directe, gerichte aanpassingen. Command I gebruik je meer voor uitleg, grotere wijzigingen of als je samen wilt nadenken over een andere aanpak. Als je dat eenmaal in je vingers hebt, schakel je veel sneller tussen lezen, begrijpen en aanpassen.

In de terminal is Cursor ook handig. Je kunt gewoon typen wat je wilt, zoals: laat mijn vijf meest recente git branches zien. Cursor vertaalt dat naar de juiste commando’s, zodat jij niet elk zeldzaam git-commando hoeft te onthouden.

Let ook op hoe de autocomplete werkt. Cursor laat grijze suggesties zien en met tab kun je die overnemen. Soms springt tab naar de volgende suggestie in plaats van alles direct in te vullen, dat voelt in het begin wat onwennig, maar als je het eenmaal doorhebt, kun je heel snel door je code heen navigeren en stukken laten aanvullen.

Commitberichten, bug finder en je eigen skills scherp houden

Cursor kan je ook helpen met de dingen waar je vaak geen zin in hebt, zoals nette commitberichten schrijven. In het source control-scherm kun je op een toverstaf-icoontje klikken en Cursor een voorstel laten doen. Meestal heb je dan in ieder geval een goede basis die je zelf nog even bijwerkt.

Daarnaast is er een bug finder die je kunt starten via Command Shift P. Die kijkt naar het verschil tussen jouw branch en de hoofdbranch en probeert mogelijke bugs te spotten. Denk aan randgevallen die je snel over het hoofd ziet, zoals een nulwaarde die je niet afvangt of een vergeten check.

Zie die bug finder niet als een garantie dat alles goed is. Het is meer een extra paar ogen dat je helpt om net die ene rare fout eruit te vissen voordat je code live gaat. Zeker als je moe bent of al lang naar hetzelfde stuk code kijkt, is dat prettig.

Veel mensen zijn bang dat ze hun skills kwijt raken als ze zo veel met AI werken. Dat hoeft niet, zolang jij de regie houdt. Laat Cursor het repetitieve werk doen, maar lees de code die het schrijft, check de tests en blijf zelf nadenken over de structuur.

Je kunt Cursor ook gebruiken om jezelf dingen uit te laten leggen. Vraag bijvoorbeeld: leg uit waarom deze aanpak beter schaalbaar is dan de vorige, of laat drie alternatieve oplossingen zien en benoem de voor- en nadelen. Zo blijf je zelf leren, terwijl je toch sneller werkt.

Als je merkt dat je te veel op Cursor leunt, draai het dan om. Schrijf eerst zelf een oplossing en vraag daarna: review deze code, waar kan het beter. Dan gebruik je Cursor als reviewer en niet als iemand die alles voor je bedenkt.