Waarom AI iets anders bouwt dan jij bedoelde

"Copilot snapt me gewoon niet." We horen het bijna wekelijks. En bijna altijd is er iets anders aan de hand: het model snapt precies wat er stond. Het probleem is wat er niet stond.

Wij bouwen dagelijks apps met AI. Het gaat snel, het gaat vaak goed, en soms komt er iets uit dat niemand gevraagd heeft. Dat is geen pech. Dat is precies hoe deze technologie werkt. Even meekijken onder de motorkap.

Hoe werkt een AI model?

Stel je de autocorrectie op je telefoon voor. Je typt "ik ben onderweg naar het" en je toestel stelt "station" voor. Het weet niet waar je heen gaat. Het heeft alleen gezien dat na die woorden heel vaak "station" kwam.

Een AI-model doet precies hetzelfde, alleen dan duizenden keren beter en over hele alinea's. Het leest wat jij hebt getypt en stelt zichzelf één vraag: wat komt hier waarschijnlijk achteraan? Het kiest het meest passende antwoord, plakt dat erachter, en stelt zichzelf dezelfde vraag opnieuw. Woord voor woord, tot het antwoord af is.

Dat is het. Geen begrip, geen bedoeling, geen plan. Alleen heel goed gokken wat er volgt. En daar volgen drie dingen uit die verklaren waarom AI zich soms zo eigenwijs gedraagt:

Dat laatste verrast de meeste mensen. Je zou denken: hoe meer ik meegeef, hoe beter. Maar onderzoek laat zien dat modellen informatie midden in een lange tekst vaker missen, en dat de kwaliteit onbetrouwbaarder wordt naarmate je invoer langer wordt. Alles erin gooien is dus geen strategie.

Het gevolg van dit alles is simpel: alles wat jij niet vertelt, verzint het model erbij. Niet uit eigenwijsheid, maar omdat het nu eenmaal altijd een volgend woord moet kiezen. Als jij niet zegt wie de app gebruikt, kiest het iets wat plausibel klinkt. En dan kijk jij naar een scherm dat er prima uitziet, maar niet doet wat jij in je hoofd had.

Wat er écht gebeurt in het AI model

Deze is voor de techneuten onder ons. Sla dit blok gerust over als je alleen de praktijk wil. Maar als je wil snappen waarom context zo zwaar weegt: hier zit het antwoord. 

Je tekst wordt eerst geknipt in tokens: stukjes woord uit een vast vocabulaire. Een woord als "onboarding" wordt daarbij vaak in meerdere stukken geknipt, zoiets als "on" + "boarding". Hoeveel precies verschilt per model, en zelfs per voorafgaande spatie. Elk token krijgt een ID en wordt een vector: een rij getallen die z'n betekenis in een wiskundige ruimte plaatst.

Daarna gaat het hele rijtje door het attention-mechanisme. Simpel gezegd: elk token kijkt naar alle tokens die eraan voorafgaan en weegt welke daarvan relevant zijn voor z'n eigen betekenis. Daardoor weet het model dat "status" in jouw prompt over een onboardingtaak gaat, en niet over een LinkedIn-update.

Voor elk volgend token berekent het model dan een kansverdeling over zijn hele vocabulaire, zoals Microsoft het omschrijft, en daaruit wordt er één geselecteerd. Formeel is dat een voorwaardelijke kans:

P(volgende token | alles wat er tot nu toe staat)

Die verticale streep is het hele verhaal. Alles rechts daarvan is jouw context. Laat je die leeg, dan valt het model terug op wat statistisch het vaakst volgde in z'n trainingsdata. Het gemiddelde van het internet dus, niet jouw organisatie.

Waarom "genoeg context" niet hetzelfde is als "veel context"
Twee dingen werken tegen je. Temperature bepaalt hoe scherp of vlak die kansverdeling wordt uitgelezen. Op 0 kiest het model steeds het meest waarschijnlijke token; hoger sampelt het uit een bredere verdeling, soms creatiever en soms simpelweg minder betrouwbaar. Voor agents adviseert Microsoft 0 tot 0,3.

En attention schaalt kwadratisch: twee keer zoveel tokens betekent vier keer zoveel onderlinge vergelijkingen. Dat verklaart vooral waarom lange context duur en traag is. Het verklaart níét waarom modellen juist het midden van een lange tekst missen. Dat is een apart, positioneel verschijnsel. Onderzoek wijst daarvoor naar de causale maskering en de positionele encoding, die de aandacht structureel naar het begin en het eind van je invoer trekken. Relevante context wint het dus altijd van véél context.

Waarom onduidelijkheid altijd wordt ingevuld

Hier komt de verrassende verklaring. OpenAI publiceerde in 2025 onderzoek met een ongemakkelijke conclusie: modellen verzinnen dingen omdat hun training en beoordeling gokken belonen boven het toegeven van onzekerheid.

Denk aan een multiplechoicetoets. Wie niets invult scoort gegarandeerd nul. Wie gokt heeft een kans. Modellen zijn jarenlang beloond voor gokken. Dus bij twijfel vullen ze iets plausibels in, in plaats van te vragen wat je precies bedoelt.

En dit is meetbaar, geen onderbuikgevoel. Orchid, een benchmark voor codegeneratie (preprint, april 2026), vond dat ambiguïteit de prestaties van álle geteste modellen verslechtert, en dat modellen bij dezelfde vage eis regelmatig functioneel verschillende oplossingen bouwen. Twee keer hetzelfde vragen, twee keer een andere app.

Bij een app doet dit extra pijn

Vraag je om "een app om onboarding te beheren", dan moet het model zelf bedenken welke gegevens je bijhoudt, welke velden dat zijn, wie wat mag zien en wat er moet gebeuren.

Die keuzes landen meteen in de datastructuur. En daar bouwt de rest van de app op verder. Een verkeerde aanname aan het begin is dus de duurste fout die je kunt maken. Je merkt hem pas als je al drie schermen verder bent.

Het advies van Microsoft zelf bij het bouwen van apps in Copilot Studio en Copilot Cowork is hier exact op gericht: beschrijf de business-uitkomst, de gebruikers, de data en de acties die je nodig hebt. Vier dingen. Meer niet.

Ons recept: GCSE

Microsoft heeft er een lekker simpel ezelsbruggetje voor: GCSE. Wij gebruiken het dagelijks.

• G - Goal: Wat moet er concreet uitkomen?

• C - Context: Waarom, voor wie, in welke situatie?

• S- Source: Welk bestand, welke data, welk systeem?

• E- Expectations: Welke vorm, welke toon, hoeveel detail?

"Een vage vraag geeft een vaag antwoord", schrijft Microsoft er zelf bij. Microsoft behandelt de vier elementen als één geheel; in onze eigen ervaring is het doel het onmisbare deel, en scherpen context, bron en verwachtingen het resultaat verder aan.

Vijf voorbeelden uit onze eigen keuken

Genoeg theorie. Dit zijn het soort opdrachten waar wij wekelijks mee bezig zijn, steeds twee keer opgeschreven. Let vooral op wat er in de rechterkolom extra staat, en wat het model anders zelf had verzonnen. 

1. De onboarding-app
PowerApps | Dataverse

 Wat er anders misgaat: zonder rollen bouwt het model één scherm waar iedereen alles ziet. Dat ontdek je pas als de eerste leidinggevende de salarisschaal van een andere afdeling opent. 

2. De verlofaanvraag
Power Automate | Approvals

Wat er anders misgaat: het model verzint zelf een happy path. Het gokt op automatisch goedkeuren na een time-out, want dat patroon komt vaker voor. Randgevallen moet je benoemen, anders worden ze ingevuld. 

3. Het datamodel voor urenregistratie
Dataverse | Datamodel

 Wat er anders misgaat: dit is de duurste categorie. Een verkeerde relatie, zoals uren direct aan een project in plaats van aan een fase, zit na drie schermen zo diep in je app dat herbouwen sneller is dan repareren. 

4. Het management-rapport
Power BI

Wat er anders misgaat: "projectcijfers" levert een verzameling grafieken op die technisch klopt en zakelijk niets zegt. Benoem je publiek en je beslissing, en je krijgt een rapport in plaats van een cijferbrij.

5.  De pingpong-app
Code App | React

Wat er anders misgaat: dit voorbeeld komt van collega Jeremy. Hij liep precies tegen die bug aan: één punt aftrekken haalde er soms twee weg. AI genereert razendsnel scoreknoppen, maar hoe je je state modelleert bepaal jij. Zijn hele verhaal lees je in de blog: Where vibe coding shines for me and where it stopped.

Zie je het patroon? In elke rechterkolom staat hetzelfde soort informatie: wie, welke gegevens, welke acties, en wat er in de randgevallen moet gebeuren. Het verschil zit niet in de lengte. Het zit in de afwezigheid van gokruimte. 

Takeaways

Dit zijn de dingen die wij zelf anders zijn gaan doen sinds we dit doorhebben:

• Duidelijk > lang - Het gaat niet om een lange prompt. OpenAI adviseert voor redenerende modellen: geef een helder doel, harde randvoorwaarden en een expliciete afspraak over de output, maar schrijf niet elke tussenstap voor. Wees helder over je eisen, niet uitgebreid in je woorden.

• Data eerst, schermen later - Begin met je gegevens en relaties. Een fout in je datamodel kost je de hele app; een lelijk scherm fix je in één zin.

• Benoem de randgevallen - Wat als niemand reageert? Wat mag een leidinggevende niet zien? Alles wat je niet benoemt, wordt voor je ingevuld. Meestal met het vrolijkste scenario.

• Eén wijziging per verzoek - Kleine stappen verslaan de megaprompt. Je ziet meteen wat er verandert, en je kunt terug als het de verkeerde kant op gaat.

• Zeg wanneer het klaar is - "Klaar betekent: een coördinator voegt een medewerker toe en ziet automatisch de checklist verschijnen." Zonder die zin bepaalt het model zelf wanneer het goed genoeg is.

• Blijf zelf de reviewer - Gegenereerde code is nog steeds jouw code. Zoals Jeremy het formuleert: de echte regel zou moeten zijn dat je geen code uitlevert die je niet begrijpt.
  

Moraal van het verhaal

AI is geen collega die doorvraagt als iets onduidelijk is. Het is een systeem dat áltijd een antwoord produceert, ook als het je bedoeling niet kent.

Wat je terugkrijgt is dus vooral een spiegel van de helderheid van wat je meegaf. AI levert de snelheid. Jij levert de duidelijkheid. En die combinatie is verrassend krachtig.

Bronnen

• Microsoft Learn: LLM fundamentals (kansverdeling, non-determinisme)
• Microsoft Support: Get started writing prompts in Microsoft Copilot (GCSE)
• Microsoft Copilot Blog: Build apps in Copilot Cowork and Copilot Studio
• OpenAI: Why language models hallucinate (2025) · Reasoning best practices
• GitHub Blog: Spec-driven development with AI
• Liu e.a., TACL: Lost in the Middle · Chroma Research: Context Rot
• Wu e.a., ICML 2025: On the Emergence of Position Bias in Transformers
• Orchid: benchmark voor ambiguïteit in codegeneratie (arXiv preprint, 2026)
• Thinking Machines Lab: Defeating Nondeterminism in LLM Inference
• Jeremy Levoye, IT RBLS: Where vibe coding shines for me and where it stopped