Zonneplan's Pro Tips for LLM-driven development

Appearance

Van YOLO naar Pro: Software engineering met LLM's in 5 minuten ​

💬 Is Cursor nieuw voor je?

Lees dan eerst de Cursor introductie. Deze YOLO naar Pro guide gaat er vanuit dat je al een beetje weet hoe Cursor werkt.

Herken je dit? ​

Je start een LLM, typt wat in (“schrijf een API voor me!”), krijgt een bak code terug en... tja, het werkt nét niet. Je probeert nog wat prompts, raakt gefrustreerd, en denkt: “Laat maar, ik doe het zelf wel.” Klinkt bekend?

In deze 5-minuten guide leer je de belangrijkste tricks voor software engineering met LLM's.

Wat werkt niet? (YOLO-style) ​

  • Prompten zonder plan (“ik zie wel wat eruit komt”)
  • Geen context geven (“de LLM weet vast wel wat ik bedoel”)
  • Resultaat klakkeloos overnemen (“zal wel goed zijn toch?”)
  • Geen iteratie, geen feedback (“volgende prompt dan maar”)

Eerst even dit: Waarom geen Cursor guide? ​

Cursor is een geweldige IDE, maar het is niet de enige. Cursor, Roo Code, Windsurf, Aider (en waarschijnlijk Jetbrains AI, daar heb ik geen ervaring mee) zijn gebouwd op dezelfde basisprincipes. Om de basisprincipes van LLM-driven development te leren focussen we ons dus niet op de editor, maar op de werkwijze.

💬 In deze guide gebruiken we Cursor.

Maar de basisprincipes gelden voor alle LLM-driven development tools.

🏛️ Principe 1: Agents all the way down ​

Cursor is een agentic IDE. Dat betekent simpel gezegd dat Cursor zelfstandig acties uitvoert die jij als mens ook zou doen. We noemen dit een Agent. Bijvoorbeeld het opzoeken van documentatie, het uitvoeren van commands in de terminal, en dergelijke.

Dit is een belangrijk aspect van Agents omdat het jou werk uit handen neemt. De acties die de Agent uitvoert hoef je niet meer zelf te doen.

Je hoeft de Agent niet precies te vertellen hoe deze te werk moet gaan.

🔎 Voorbeeld: Cursor zoekt API docs

Prompt
"Draw a flowchart of how the nordpool trading, public market data and sso api's are related"

Cursor zoekt hier zelfstandig in de codebase naar relevante informatie over de gevraagde APIs. Je ziet dat Cursor zoekopdrachten uitvoert om precies de juiste context te vinden, zonder dat jij handmatig hoeft te zoeken of Cursor expliciet vertelt waar te zoeken.

Dit hebben Agents nodig om goed te werken:

  1. Benoem welke tools de agent kan gebruiken

    Dit doet Cursor voor je en hoef je zelf niet te doen.

    • Bijvoorbeeld read_file, edit_file, terminal en MCP servers

  2. Geef de Agent een rol

    Je bepaalt hiermee waar de Agent waarde aan hecht en wat de Agent kan doen.
    Dit zorgt voor betere uitkomsten -> "Jack of all trades, master of none"

    Kies in Cursor een van de voorgeprogrammeerde rollen:

    • 🤖 Agent mode: Developer die zelfstandig taken uitvoert. Kan schrijven en tools gebruiken.
    • 💬 Ask mode: Read-only mode om de codebase te verkennen, ook nuttig om documentatie te schrijven.

    Je kunt ook zelf custom agents maken.

  3. Geef de Agent minimale parate kennis

    De Agent is een nieuwe collega met veel kennis die je werkwijze moet weten. Dit is je project-specifieke system prompt die bij iedere agent sessie ingeladen wordt. Maak een Cursor Rule aan met rule type "Always" met daarin de parate kennis.

    • Bijvoorbeeld: welke tech stack gebruik je, hoe de tests uit te voeren, etc.

Parate kennis van deze repository:

markdown
In deze codebase wordt een handleiding voor LLM-driven development geschreven.

## Schrijfstijl

De inhoud van de handleiding wordt geschreven in het Nederlands. De tone of voice wordt beschreven in [02-tone-of-voice.md](02-tone-of-voice.md).

## Tech stack

- markdown
- vitepress

## Knowledge

When you need to find information about a specific package, api or service it might be in the "knowledge/" folder so check the files in that directory if you need specific information like SDK specification.

  1. Geef de Agent een knowledge base

    Laat de Agents geen aannames (hallucinaties) doen over SDK's, API's en database structuren. De Agent zal de knowledge base raadplegen als hij informatie niet paraat heeft.

    • Verzamel relevante documentatie in de knowledge/ map zodat de Agent documentatie kan raadplegen
🔎 Voorbeeld: knowledge base van deze site
knowledge/
├── 01-project.md
├── 02-structuur-en-tone-of-voice.md
├── mermaid/
│   └── mindmap.md
└── vitepress/
    ├── vitepress-plugin-mermaid.md
    └── vitepress.md
  1. Geef een duidelijke opdracht
    • Wees specifiek: beschrijf je verwachting, dan kan de Agent daaraan voldoen.

Voorbeelden van duidelijke opdrachten

❌ "Write tests for this function"
✅ "Write tests to confirm that this function returns an empty array for [edge case X]"

❌ "Store this data in Redis"
✅ "The contract cache and province code cache is currently kept in memory. Now we want to offload this to Redis. Redis is already started on the local machine and is available on port 6388 (on production it will be at 6379)."

❌ "Add a health controller that returns 200 'ok' on /health"
✅ "Add a health controller to powerbook-forecast, make it consistent with to the other apps like powerbook-actuals"

Voor meer info over goede prompting, bekijk de prompting 101.

🏛️ Principe 2: Context is king - de knowledge/ folder ​

We willen allemaal dat onze LLM's magisch goede code schrijven, toch? Maar laten we eerlijk zijn: zelfs als ervaren developer ben je constant dingen aan het opzoeken. Documentatie, specifieke implementaties, de details van die ene library... Het is onderdeel van de job. Wat als je LLM diezelfde research-skills proactief kon inzetten voor jouw project? Dát is waar de knowledge/ folder het verschil maakt.

Zie de knowledge/ folder als de knowledge base, niet alleen voor jou, maar nu ook voor je AI-tool. Jij stopt er de essentiële info in die je anders zelf zou opzoeken:

  • Details over de gebruikte frameworks en libraries.
  • Specifieke API-endpoints en hun request/response structuren (alsof je LLM de Postman-collectie al kent).
  • Belangrijke architecturale beslissingen en diagrammen (als markdown, zodat het leesbaar is).
  • Voorbeelden van hoe bepaalde custom componenten gebruikt moeten worden (de "best practices" van jouw project).

Waarom is dit een gamechanger? Omdat een goed geïnformeerde LLM, net als een goed geïnformeerde developer, minder hoeft te gokken en sneller tot de juiste oplossing komt. Door relevante informatie in de knowledge/ folder te plaatsen, kan je AI-assistent deze proactief raadplegen, net zoals jij documentatie zou checken. Het resultaat: betere code, minder fouten, en een ontwikkelproces dat voelt alsof je een slimme, zelfstandige collega hebt die meezoekt en meedenkt. Weg met hallucinaties!

De knowledge/ folder van deze repo op moment van schrijven:

knowledge
├── 01-project.md
├── 02-structuur-en-tone-of-voice.md
├── cursor
│   ├── @-chat.md
│   ├── @-code.md
│   ├── ...
│   ├── rules-for-ai.md
│   └── what-is-cursor.md
├── mermaid
│   └── mindmap.md
├── roo-code
│   └── features
│       └── checkpoints.md
└── vitepress
    ├── vitepress-plugin-mermaid.md
    └── vitepress.md

Deep dive in de knowledge/ folder

Wil je meer weten over hoe je de knowledge/ folder optimaal kunt benutten? Lees dan de pagina over de knowledge folder.

🏛️ Principe 3: Beschrijf je verwachting ​

Waarom is die kristalheldere verwachting zo cruciaal? Simpel: een LLM, hoe geavanceerd ook, is geen gedachtenlezer. Het is een extreem krachtige 'tekstaanvulmachine'. Jouw prompt is de brandstof én de routekaart. Hoe preciezer jij je verwachting (de opdracht, de context, de constraints, de gewenste stijl) beschrijft, hoe meer de LLM je daar aan je verwachtingen kan voldoen.

Geef je vage instructies ("bouw ff een dingetje voor data"), dan krijg je iets onverwachts. Je moet dan veel bijsturen.

Geef je een scherpe briefing? Dan is de kans op een voltreffer gigantisch groter.

Wees specifiek:

Ik heb een Python script nodig dat CSV-bestanden uit map X leest. 
Het moet kolom Y filteren op waarde Z. 
Sla het resultaat als JSON op in map A. 
Houd rekening met edge case B en gebruik de `pandas` library.

Je stuurt de LLM direct de goede kant op.

Een scherpe prompt heeft twee hoofdvoordelen:

  1. Verkleint de zoekruimte: De LLM hoeft minder te 'gokken' wat je precies bedoelt. Het beperkt het aantal mogelijke 'goede' antwoorden tot datgene wat jij voor ogen hebt.
  2. Stuurt de 'creativiteit' en output: Je leidt de LLM naar nuttige, relevante resultaten die passen binnen jouw project. Wil je een specifieke library gebruiken? Zeg het! Moet de code commentaar bevatten? Vraag erom!

Dit bespaart je kostbare tijd:

  • Minder iteraties: Minder "net niet" resultaten betekent dat je sneller bij je doel bent.
  • Meer controle: Jij bepaalt de richting, niet de willekeur van de Agent. Jij bent de regisseur, de Agent is je uitvoerder.

Kortom: investeer die paar extra seconden of minuten in het glashelder formuleren van je verwachting. Het is de snelste weg naar code waar je écht wat aan hebt, en het bespaart je een hoop trial-and-error en frustratie. Je geeft de Agent de handvatten om te excelleren, precies zoals jij dat wilt! Dit is de kern van effectief samenwerken met een Agent: duidelijke communicatie leidt tot voorspelbare en waardevolle resultaten.

Voorbeelden van duidelijke opdrachten

❌ "Write tests for this function"
✅ "Write tests to confirm that this function returns an empty array for [edge case X]"

❌ "Store this data in Redis"
✅ "The contract cache and province code cache is currently kept in memory. Now we want to offload this to Redis. Redis is already started on the local machine and is available on port 6388 (on production it will be at 6379)."

❌ "Add a health controller that returns 200 'ok' on /health"
✅ "Add a health controller to powerbook-forecast, make it consistent with to the other apps like powerbook-actuals"

Voor meer info over goede prompting, bekijk de prompting 101.

🏛️ Principe 4: Kill your darlings ​

Soms kiest je Agent een pad dat nergens toe leidt, ook al leek je prompt nog zo helder. Frustrerend? Zeker. Maar dit is precies waar het 'kill your darlings'-principe om de hoek komt kijken. In plaats van eindeloos te proberen een verkeerd ingeslagen weg te corrigeren, is het vaak veel effectiever om rigoureus te zijn.

Terug naar Start (of een Checkpoint)

Cursor biedt 'checkpoints'. Dit zijn snapshots van zowel je code als je conversatie op een bepaald punt. Merkt je dat de Agent de plank volledig misslaat? Geen probleem! Herstel gewoon een eerder checkpoint. Dit is hét moment om je oorspronkelijke prompt kritisch te bekijken. Als de Agent een onverwachte route neemt, heb je waarschijnlijk je verwachtingen niet scherp genoeg geformuleerd. Een aangepaste, duidelijkere prompt vanaf een schoon startpunt (het checkpoint) is dan de sleutel.

De Valstrik van Door-corrigeren

Waarom niet gewoon de Agent blijven corrigeren in dezelfde chat? Het lijkt misschien de snelste weg, maar er schuilt een addertje onder het gras. Elke keer dat je de Agent corrigeert en het gesprek voortzet, wordt de volledige chatgeschiedenis meegenomen in het context window van de Agent. Hoe langer en complexer die geschiedenis wordt (zeker met veel correcties en zijpaden), hoe groter de kans dat de Agent 'in de war' raakt. Dit kan leiden tot:

  • Hallucinaties: De Agent begint onzin te verkopen of dingen te verzinnen.
  • Verlies van focus: De Agent 'vergeet' de oorspronkelijke opdracht.
  • Inefficiëntie: Je bent meer tijd kwijt met bijsturen dan met daadwerkelijk vooruitgang boeken.

Kortom: wees niet bang om een interactie die de verkeerde kant opgaat resoluut af te kappen. Teruggaan naar een checkpoint, of de chat deels/geheel verwijderen en opnieuw beginnen met een scherpere, beter geformuleerde prompt, is vaak de snelste weg naar een goed resultaat. Het voelt misschien als een stap terug, maar het is de slimste manier om je Agent op koers te houden en frustratie te voorkomen.

Deep dive in checkpoints

Wil je meer weten over het gebruik van checkpoints? Lees dan de checkpoints guide.

Nu ben je Pro. Wat nu? ​

Nu begint het pas!

Volgende stappen: Lees Je codebase klaarmaken voor agentic setup om je project optimaal in te richten voor Agents. Of bekijk de roadmap voor meer advanced technieken.