Claude en Cursor gebruiken: checklist in 10 stappen

Claude en Cursor gebruiken werkt het best als je de rollen splitst: Claude maakt het plan, Cursor bouwt het in je projectmap. Zo ziet de AI al je bestanden en niet één los stukje code uit een chat. Hieronder leg ik uit waarom die volgorde werkt, waar het misloopt en hoe zo'n project er in de praktijk uitziet.

Waarom code kopiëren uit je chat niet blijft werken

De meeste mensen starten zo: vraag stellen, code plakken, hopen dat het werkt. Dat werkt voor een klein script. Zodra je project meerdere bestanden heeft, raak je de draad kwijt.

De chat kent maar het stuk dat jij plakt. Hij weet niet welke functies al bestaan, hoe je bestanden heten of wat je gisteren hebt aangepast. Je krijgt dan code die op zichzelf klopt maar niet in je project past.

Cursor lost dat op door in de hele map te werken. Dat is het hele verschil, en het is geen magie. Het is context.

Hoe gebruik je Claude voor het plan?

Begin niet in Cursor. Begin met een gesprek in Claude, zonder code.

Wat hoort er in je plan?

Laat Claude drie dingen uitwerken:

• Wat moet de tool doen, in functies die je apart kan testen.
• Voor wie is ze: jij, je team of klanten? Dat bepaalt hoe netjes ze moet zijn.
• Met welke data: wat komt erin, wat komt eruit, waar wordt het bewaard?

Vraag daarna om een volgorde in kleine stappen. Dat plan is later je routekaart. Schrap eerlijk wat niet nodig is voor een eerste werkende versie. Dat werkt beter dan een plan met twintig functies waarvan er vijf lukken.

Wat doet Cursor anders dan een chat?

Cursor is een code-editor met AI erin. Je opent je projectmap, geeft het plan mee en de AI werkt met je echte bestanden.

Eén ding om te weten: Cursor kan bestanden aanpassen terwijl je kijkt. Daarom lees je elke wijziging voor je goedkeurt. Cursor maakt tijdens agent-sessies ook checkpoints, waarmee je eerdere codestanden kan terugzetten als de agent de verkeerde kant op gaat. Git blijft wel je betrouwbaarste vangnet: commit na elke werkende stap.

Geef Cursor vaste regels

Cursor ondersteunt een bestand AGENTS.md. Dat is een eenvoudig markdown-bestand met instructies voor de agent, dat je in de hoofdmap van je project zet. Zet er je vaste afspraken in. Een voorbeeld:

• Wijzig alleen wat in de opdracht staat.
• Verwijder geen bestaande functies zonder te vragen.
• Zet nooit keys of wachtwoorden in de code.

Je typt die regels dan één keer in plaats van bij elke opdracht.

Waarom één functie per keer?

Vraag je "bouw de hele app", dan krijg je een berg wijzigingen die je niet meer kan beoordelen. Zit er een fout in, dan weet je niet waar.

Vraag je één functie, dan kan je hem meteen in je browser testen. Fouten vang je zo voor ze zich opstapelen. Is een wijziging groot en onleesbaar, zet dan het laatste checkpoint terug en vraag een kleiner stuk. Een breed, moeilijk te reviewen resultaat? Ga terug naar het checkpoint en vraag een kleinere eenheid werk.

Hoe hou je API keys en wachtwoorden veilig?

Dit is de regel die ik altijd herhaal: API keys en wachtwoorden horen nooit in een chat. Een gedeelde key kan je niet terughalen. Je moet hem vervangen.

Wat je wel doet:

1. Bewaar geheimen in een .env-bestand en zet dat in .gitignore, zodat het niet in je versiebeheer belandt.
2. Voeg het ook toe aan .cursorignore. Met .cursorignore blokkeer je de toegang van de agent tot bepaalde bestanden.
3. Beschouw dat als een extra slot, geen garantie. Het lezen van bestanden en zoeken in code vraagt standaard geen toestemming, terminalopdrachten die gevoelige data kunnen blootleggen wel. Lees dus ook de opdrachten die Cursor wil uitvoeren.
4. Zet auto-reload niet blind aan. Met auto-reload kunnen wijzigingen van de agent worden uitgevoerd voor je ze hebt kunnen nakijken.

Wat kost Cursor?

Er is een gratis Hobby-plan. Dat geeft een beperkt aantal agent-aanvragen en Tab-aanvullingen, zonder kredietkaart. Het betaalde Pro-plan staat op $20 per maand. Prijzen en limieten veranderen geregeld, dus bekijk de actuele cijfers op cursor.com. Voor een eerste project start je gewoon gratis en kijk je of de limiet je hindert.

Voorbeeld: een offertecalculator voor een bakkerij

Stel dat je een bakkerij hebt en een kleine tool wilt waarmee klanten een richtprijs voor een taartbestelling zien.

Plan met Claude: een formulier met aantal personen en smaak, een prijsberekening, en een mailtje naar jou met de aanvraag. Eerste versie: enkel het formulier en de berekening. Mail komt later.

Bouwen in Cursor: je maakt een map, zet het plan erin en opent die. Eerste opdracht: "Bouw alleen het formulier uit stap 1." Je test het, commit, en vraagt dan de prijsberekening. Pas bij stap drie komt de mail, met de mailkey in .env.

Elke stap is klein genoeg om te lezen en te testen. Dat is de hele truc.

Welke fouten zie je het vaakst?

• Geen plan: je start in Cursor met één vage zin en bouwt halve oplossingen op elkaar.
• Te grote opdrachten: je kan het resultaat niet meer beoordelen.
• Blind goedkeuren: een wijziging die buiten je opdracht valt, gaat toch door.
• Geen commits: na een foute sessie kan je nergens naartoe terug.
• Keys in de code of chat: de dure fout, en de makkelijkst te vermijden.

Wanneer bouw je dit beter niet zelf?

Voor een interne tool of een prototype is dit een goede manier. Gaat het om betalingen, klantgegevens of een systeem waar je bedrijf elke dag op draait, dan is mee laten kijken zinvol. Denk aan een CRM op maat of een proces dat je met AI automations wil koppelen aan je andere tools. Twijfel je of je het zelf kan bouwen? Stuur me een bericht via contact, dan kijken we er vrijblijvend samen naar.