Er is een patroon dat ik steeds vaker zie. Een developer opent zijn AI-agent, typt iets als "bouw me een checkout-flow met kortingscodes en belastinglogica", ziet de code in seconden verschijnen en denkt: "Klaar. Dat is wat ik vroeg."
Dat is het niet.
Wat ze typten was een wens. Wat ze nodig hadden was een specificatie. En die twee dingen liggen een wereld van elkaar verwijderd — een kloof die geen enkel model, hoe capabel ook, zelfstandig kan overbruggen.
De illusie van communicatie
Wanneer je een prompt aan een AI-agent geeft, heb je het gevoel dat je gecommuniceerd hebt. Je gebruikte woorden, de agent reageerde met code, en die code werkt. Die feedbackloop is zo snel en zo bevredigend dat hij een fundamenteel probleem maskeert: de agent heeft je niet begrepen. Hij heeft je voorspeld.
Dat is een verschil. Begrijpen vereist context, beperkingen en het vermogen om de juiste verduidelijkende vragen te stellen. Voorspellen is een statistische interpolatie tussen alles wat het model ooit heeft gezien. Wanneer jouw prompt ambigu is — en dat zijn de meeste prompts — vult het model de gaten in met aannames. Zelfverzekerde, syntactisch correcte, unit-geteste aannames die absoluut niets te maken hebben met jouw feitelijke business-requirements.
Je checkout-flow handelt de btw nu af zoals de meeste webshops dat doen. Niet zoals die van jou dat zou moeten doen.
Garbage in, garbage out — maar dan sneller
Er is een oud principe in software: garbage in, garbage out. Vage requirements produceren slechte software. Dat gold toen requirements naar een junior developer gingen. Het geldt nu ook wanneer ze naar een AI-agent gaan.
Het verschil is snelheid. Een junior developer stelt misschien een verduidelijkende vraag. Ze lopen vast op iets en komen terug bij je. De wrijving is vervelend, maar het is ook een signaal — een symptoom van ontbrekende informatie dat bovenborrelt voordat het een bug wordt.
Een AI-agent loopt niet vast. Hij neemt een beslissing en gaat verder. Hij bouwt de hele feature op een aanname die jij nooit hebt gevalideerd, en dat doet hij in de tijd dat jij je koffie bijvult. Tegen de tijd dat je kijkt naar wat er is gegenereerd, zit je al vijf beslissingen diep in de verkeerde richting.
AI maakt je slechte requirements niet beter. Het voert ze sneller uit.
Wat een spec eigenlijk is
Een specificatie is geen muur van formele documentatie. Dat hoeft ook niet. Maar hij moet wel vragen beantwoorden die jouw prompt vrijwel zeker open heeft gelaten:
| Wat de prompt zegt | Wat de spec moet beantwoorden |
|---|---|
| "kortingscodes" | Welke soorten? Percentage, vast bedrag, gratis verzending? Stapelbaar? Verloopdatums? |
| "belastinglogica" | Welke landen? Inclusief of exclusief btw? BTW, GST, of beide? |
| "gebruikersauthenticatie" | Sessies of tokens? Wat gebeurt er als een sessie verloopt tijdens de checkout? |
| "stuur een bevestigingsmail" | Wat triggert hem? Wat als de mail mislukt? Retry-logica? |
Elk van die hiaten is een beslissing. Als jij die beslissing niet neemt, doet het model dat. En het doet dat stilzwijgend, zonder het te markeren als een beslissing.
De snelheidsval
Hier wordt het verraderlijk. Omdat de AI snel iets opleverde, heb je het gevoel dat je voorloopt. De snelheid is echt — regels code verschijnen, tests slagen, de feature lijkt compleet. Dat gevoel is de val.
Je hebt geen tijd bespaard. Je hebt het geleend. De schuld ligt in elke aanname die het model heeft gemaakt die jij nog niet hebt beoordeeld. Je betaalt het terug wanneer de product manager vraagt waarom de btw niet correct wordt berekend voor Belgische klanten. Of wanneer een kortingscode stapelt met een actieprijs op een manier waardoor elk artikel gratis is. Of wanneer een betaling stilletjes mislukt omdat een edge case die niemand heeft gespecificeerd verkeerd is afgehandeld.
Dit is niet hypothetisch. Dit is wat er gebeurt wanneer de prompt de spec wordt.
Gebruik de agent om de spec te schrijven
Hier zit de ironie: AI-agents zijn eigenlijk best goed in het blootleggen van wat je nog niet hebt bedacht — als je hen dat vraagt.
Prompt niet voor code. Prompt voor vragen.
"Ik wil een checkout-flow bouwen met kortingscodes en belastinglogica. Voordat je één regel code schrijft, geef me een lijst van alle aannames die je zou moeten maken en alle beslissingen die ik nog niet heb gespecificeerd."
De output zal ongemakkelijk zijn. Het wordt een lijst van dingen waar je nog niet over had nagedacht. Dat ongemak is precies de bedoeling. Je verliest geen tijd — je haalt de wrijving naar voren die anders als productiebugs zou opduiken.
Pas wanneer je die vragen hebt beantwoord, prompt je voor code. Op dat punt geef je de agent geen wens. Je geeft hem een spec.
Tot slot
De prompt is het begin van een gesprek, niet het einde ervan. Hem behandelen als een volledige instructieset is hoe je eindigt met code die perfect draait en precies het verkeerde doet.
Blijf de auteur van je requirements. Neem de beslissingen die jij moet nemen. En laat de snelheid van oplevering je er niet van overtuigen dat duidelijkheid optioneel is.
De agent is snel. Zorg dat hij het juiste bouwt.