Het internet staat vol met prompt engineering tips. Gebruik specifieke taal. Geef voorbeelden. Stel de rol in. Chain je prompts.
Dat helpt allemaal. Maar het is niet waar de echte hefboom zit.
Dit vertelt niemand je: de developers die prompts van 50 woorden schrijven en betere resultaten krijgen dan jij met 500 woorden? Die zijn niet beter in prompting. Ze hebben beter gestructureerde projecten.
Waarom structuur prompting verslaat
Als je codebase gedocumenteerde conventies heeft, strikte types en gefocuste domeinen, dan heeft de AI geen roman-lengte prompt nodig. Hij leest je architectuur en leidt de rest af.
"Voeg een CRUD endpoint toe voor facturen" is dan genoeg. Want je .claude/ docs leggen de patronen uit. Je types beperken de vormen. En je domeinstructuur laat zien waar de code hoort.
Vergelijk dat met het alternatief. Een prompt van 500 woorden die het framework specificeert, de ORM, de naamconventies, de mappenstructuur, het error handling patroon, de testaanpak. Terwijl dat allemaal een keer in een document had kunnen staan. In plaats van herhaald in elke prompt.
De hefboom-rangorde
Van meeste naar minste impact:
- Architectuurdocumentatie: AI leest je conventies en volgt ze. Grootste hefboom die er is.
- Type-definities: Pydantic schemas en TypeScript types beperken wat AI kan genereren. Minder foute antwoorden mogelijk.
- Domeinstructuur: gefocuste mappen zorgen dat AI de juiste context ziet. Geen ruis van niet-gerelateerde code.
- Bestaande voorbeelden: een werkend endpoint in hetzelfde domein is meer waard dan welke prompt ook. AI doet aan pattern matching.
- De prompt zelf: op dit punt maakt het nauwelijks uit. "Voeg het delete endpoint toe" is genoeg.
De meeste developers steken al hun energie in #5 en negeren #1 tot en met #4. Vandaar de inconsistente resultaten.
Laat zien, vertel niet
De beste "prompt" is een werkend voorbeeld. In plaats van uit te leggen hoe je endpoints eruit moeten zien:
# In plaats van een prompt van 200 woorden, zeg gewoon:
"Voeg een PATCH endpoint toe voor tasks
volgens hetzelfde patroon als het create endpoint hierboven."AI leest het bestaande endpoint. Kopieert het patroon: de error handling, het response formaat, de service call structuur, de statuscodes. Alles klopt. Omdat het matcht tegen een echt voorbeeld. Niet tegen geinterpreteerde instructies.
Pattern matching verslaat uitleggen. Altijd.
Wanneer prompts er wel toe doen
Soms doet de prompt er wel toe:
- Nieuwe domeinen: als er geen bestaand voorbeeld is, moet je explicieter zijn over het patroon.
- Onverwachte vereisten: "Dit endpoint moet zowel de rol van de gebruiker ALS het workspace-lidmaatschap checken." Business rules die niet vastliggen in types.
- Edge cases: "Handel het geval af waarin de due date in het verleden ligt maar aangemaakt is voor de timezone-migratie."
Maar ook dan is de prompt korter. Omdat de architectuur al het andere afhandelt.
Het compound effect
Dit gebeurt er als je investeert in structuur in plaats van prompts:
| Week | Prompt-lengte | Resultaatkwaliteit |
|---|---|---|
| Week 1 (geen docs) | 400-600 woorden | Hit or miss |
| Week 2 (met .claude/ docs) | 100-200 woorden | Meestal goed |
| Maand 1 (docs + types + domeinen) | 50-100 woorden | Consistent goed |
| Maand 3 (volledig systeem) | 20-50 woorden | Bijna altijd goed |
Je prompts worden steeds korter. Omdat je codebase steeds beter communiceert. De architectuur spreekt voor je.