30 aug 2025·8 min
Een eenvoudig mentaal model van hoe AI denkt bij het bouwen van apps
Een helder mentaal model van hoe AI code en beslissingen genereert in apps—tokens, context, tools en tests—plus limieten en praktische promptingtips.
Een helder mentaal model van hoe AI code en beslissingen genereert in apps—tokens, context, tools en tests—plus limieten en praktische promptingtips.
Als mensen zeggen “AI denkt”, bedoelen ze meestal iets als: het begrijpt je vraag, redeneert erover en besluit een antwoord. Voor moderne tekstgebaseerde AI (LLMs) is een nuttiger mentaal model eenvoudiger: het model voorspelt welk stuk tekst erna moet komen.
Dat klinkt misschien teleurstellend—totdat je ziet hoe ver dat "volgende tekst" kan reiken. Als het model genoeg patronen heeft geleerd tijdens training, kan het voorspellen van het volgende woord (en het volgende, en het volgende) verklaringen, plannen, code, samenvattingen en zelfs gestructureerde data produceren die je app kan gebruiken.
Je hoeft de onderliggende wiskunde niet te leren om goede AI‑features te bouwen. Wat je wel nodig hebt is een praktische manier om gedrag te voorspellen:
Dit artikel is dat soort model: geen hype, geen diep technisch paper—gewoon de concepten die je helpen betrouwbare productervaringen te ontwerpen.
Vanaf het perspectief van een app‑bouwer is het “denken” van het model de tekst die het genereert als reactie op de input die jij geeft (je prompt, gebruikersberichten, systeemregels en opgehaalde inhoud). Het model controleert standaard geen feiten, surft niet op het web en “weet” niet wat er in je database staat tenzij je die informatie meestuurt.
Stel verwachtingen dienovereenkomstig: LLMs zijn ongelooflijk handig voor opstellen, transformeren en classificeren van tekst, en voor het produceren van code‑achtige output. Ze zijn geen magische waarheidstoetsers.
We breken het mentale model in een paar delen:
Met deze ideeën kun je prompts, UI en veiligheidsmaatregelen ontwerpen die AI‑features consistent en betrouwbaar laten voelen.
Als mensen zeggen dat een AI “denkt”, is het makkelijk om te bedenken dat het redeneert zoals een mens. Een bruikbaarder mentaal model is eenvoudiger: het doet extreem snelle autocomplete—stukje voor stukje.
Een token is een tekstblokje waar het model mee werkt. Soms is het een heel woord (“apple”), soms een deel van een woord (“app” + “le”), soms interpunctie en soms zelfs witruimte. De precieze opsplitsing hangt van de tokenizer van het model af, maar de takeaway is: het model verwerkt tekst niet als nette zinnen—het verwerkt tokens.
De kernlus van het model is:
Dat is het. Elke alinea, opsomming en “redeneringsketen” die je ziet is opgebouwd door deze next‑token‑predictie herhaaldelijk uit te voeren.
Omdat het model enorme hoeveelheden tekst tijdens training heeft gezien, leert het patronen zoals hoe uitleg gewoonlijk verloopt, hoe een beleefde e‑mail klinkt of hoe een bugfix meestal beschreven wordt. Als je een vraag stelt, genereert het een antwoord dat past bij de patronen die het geleerd heeft en bij de context die je gaf.
Dit is waarom het zeker en samenhangend kan klinken, zelfs als het fout is: het optimaliseert voor welke tekst erna moet komen—niet voor het controleren van de werkelijkheid.
Code is niet speciaal voor het model. JavaScript, SQL, JSON en foutmeldingen zijn allemaal slechts reeksen tokens. Het model kan bruikbare code produceren omdat het veelvoorkomende codepatronen heeft geleerd, niet omdat het je app echt "begrijpt" zoals een engineer dat zou doen.
Als mensen vragen “waar komt dat antwoord vandaan?”, is het meest nuttige mentale model: het heeft patronen geleerd uit een enorm aantal voorbeelden, en recombineert die patronen nu om te voorspellen welke tekst erna moet komen.
Tijdens training ziet het model veel tekstfragmenten (boeken, artikelen, code, documentatie, Q&A's en meer). Het oefent herhaaldelijk een eenvoudige taak: gegeven wat tekst, voorspel het volgende token. Als het fout zit, verschuift de training de interne parameters net genoeg zodat die voorspelling de volgende keer iets waarschijnlijker wordt.
Na verloop van tijd stapelen die verschuivingen zich op. Het model begint relaties te coderen zoals:
Omdat het statistische regelmatigheden leert—niet één vast script—kan het patronen op nieuwe manieren combineren. Als het veel voorbeelden heeft gezien van “een concept uitleggen” en veel voorbeelden van “jouw app‑scenario”, kan het die vaak samenvoegen tot een op maat gemaakt antwoord.
Daarom kan een LLM een aannemelijke onboardingmail schrijven voor een niche‑product, of een generieke API‑integratie uitleg aanpassen aan een specifiek stack. Het haalt niet één opgeslagen alinea op; het genereert een nieuwe reeks die past bij de geleerde patronen.
Zelfs als sommige trainingsdata een specifiek feit bevatte (bijv. een prijsplan of intern beleid), moet je niet aannemen dat het model dat betrouwbaar kan “opzoeken”. Training werkt niet als het indexeren van een kennisbank die je later kunt queryen. Het lijkt meer op compressie: veel voorbeelden worden gedistilleerd in gewichten die toekomstige voorspellingen beïnvloeden.
Dat betekent dat het model zeker kan klinken over details die het raadt op basis van wat gewoonlijk in vergelijkbare contexten voorkomt.
Patroonleren is krachtig voor het produceren van vloeiende, relevante tekst, maar vloeiendheid is niet hetzelfde als waarheid. Het model kan:
Voor app‑bouwers is de belangrijkste conclusie: antwoorden van een LLM komen meestal uit geleerde patronen, niet uit geverifieerde feiten. Als correctheid telt, moet je de output grondvesten in je eigen data en checks (daarover later meer).
Als een LLM een antwoord schrijft, haalt het niet één “juiste zin” uit een database. Bij elke stap voorspelt het een range aan mogelijke volgende tokens, elk met een kans.
Als het model altijd het enkele meest waarschijnlijke volgende token zou kiezen, zou de uitvoer zeer consistent zijn—maar ook repetitief en soms ongemakkelijk rigide. De meeste systemen sampleen in plaats daarvan uit de kansen, wat gecontroleerde willekeur introduceert.
Twee veelgebruikte instellingen bepalen hoe gevarieerd de uitvoer aanvoelt:
Als je een app bouwt, gaan deze knoppen minder over “creatief zijn” in artistieke zin en meer over kiezen tussen:
Omdat het model optimaliseert voor plausibele tekst, kan het stellig klinkende uitspraken doen—zelfs wanneer de onderliggende bewering onjuist of incompleet is. Tonale zekerheid is geen bewijs. Daarom hebben apps vaak grounding (zoals retrieval) of verificatiestappen nodig voor feitelijke taken.
Vraag een LLM: “Schrijf een JavaScript‑functie die duplicaten uit een array verwijdert.” Je kunt een van deze krijgen, allemaal geldig:
// Option A: concise
const unique = (arr) => [...new Set(arr)];
// Option B: explicit
function unique(arr) {
return arr.filter((x, i) => arr.indexOf(x) === i);
}
Verschillende sampling keuzes leiden tot verschillende stijlen (concis vs expliciet), verschillende afwegingen (snelheid, leesbaarheid) en zelfs verschillend randgedrag—zonder dat het model “van gedachten verandert”. Het kiest simpelweg tussen meerdere hoog‑waarschijnlijke continuaties.
Als mensen zeggen dat een AI zich je gesprek “herinnert”, heeft het eigenlijk context: de tekst die het nu kan zien—je laatste bericht, systeeminstructies en welk deel van de eerdere chat nog in het venster past.
Het contextvenster is een vaste limiet op hoeveel tekst het model tegelijk kan overwegen. Zodra de conversatie lang genoeg wordt, vallen oudere delen buiten dat venster en verdwijnen ze effectief uit zicht.
Daarom zie je soms gedrag als:
Als je berichten in een thread blijft stapelen, concurreer je om beperkte ruimte. Belangrijke constraints worden naar achteren gedrukt door recente uitwisselingen. Zonder samenvatting moet het model afleiden wat belangrijk is uit wat nog zichtbaar is—dus het kan zelfverzekerd klinken terwijl het stiekem belangrijke details mist.
Een praktische oplossing is om periodiek samen te vatten: herhaal het doel, beslissingen en constraints in een compact blok en ga daarna verder. In apps wordt dit vaak geïmplementeerd als een automatische “conversatiesamenvatting” die in de prompt wordt geïnjecteerd.
Modellen volgen instructies die dicht bij de output staan beter. Dus als je regels hebt die strikt gevolgd moeten worden (formaat, toon, randgevallen), zet ze dan aan het einde van de prompt—precies voordat je zegt “Produceer nu het antwoord.”
Als je een app bouwt, behandel dit als interfaceontwerp: bepaal wat in context moet blijven (vereisten, gebruikersvoorkeuren, schema) en zorg dat het altijd is opgenomen—of door chatgeschiedenis te trimmen of door een compacte samenvatting toe te voegen.
Voor meer over het structureren van prompts, zie /blog/prompting-as-interface-design.
LLMs zijn heel goed in het produceren van tekst die lijkt op wat je van een bekwame ontwikkelaar zou verwachten. Maar “het klinkt goed” is niet hetzelfde als “het klopt”. Het model voorspelt waarschijnlijke volgende tokens, niet of de uitvoer werkt met jouw codebase, dependencies of de echte wereld.
Als het model een fix, refactor of nieuwe functie voorstelt, is het nog steeds alleen maar tekst. Het voert je app niet uit, importeert geen pakketten, roept je API niet aan of compileert je project niet—tenzij je het expliciet koppelt aan een tool die dat kan (bijv. een testrunner, linter of buildstap).
Dat is het belangrijkste contrast:
Als AI fouten maakt, faalt het vaak op voorspelbare manieren:
Deze fouten zijn moeilijk op te merken omdat de uitleg eromheen doorgaans coherent is.
Behandel AI‑output als een snelle conceptuele bijdrage van een teammate die het project niet lokaal heeft gedraaid. Het vertrouwen moet sterk toenemen nadat je:
Als de tests falen, ga ervan uit dat het modelantwoord slechts een beginpunt is—geen definitieve oplossing.
Een taalmodel is goed in voorstellen die kunnen werken—maar op zichzelf produceert het nog steeds alleen tekst. Tools laten een AI‑gestuurde app die voorstellen omzetten in geverifieerde acties: code uitvoeren, een database queryen, documentatie ophalen of een externe API aanroepen.
In app‑workflows zien tools er meestal zo uit:
Het belangrijke verschil is dat het model niet langer doet alsof het het resultaat weet—het kan controleren.
Een bruikbaar mentaal model is:
Zo verminder je giswerk. Als de linter unused imports meldt, past het model de code aan. Als unit tests falen, iterereert het totdat ze slagen (of het verklaart waarom het niet kan).
eslint/ruff/prettier om stijl te bevestigen en issues op te sporen.Tools kunnen krachtig—en gevaarlijk—zijn. Volg het least‑privilege‑principe:
Tools maken het model niet “slimmer”, maar ze maken de AI in je app meer gegrond—omdat het kan verifiëren in plaats van alleen te narreren.
Een taalmodel is goed in schrijven, samenvatten en redeneren over tekst die het kan “zien”. Maar het kent niet automatisch je laatste productwijzigingen, bedrijfsbeleid of de accountgegevens van een specifieke klant. Retrieval‑Augmented Generation (RAG) is een eenvoudige oplossing: haal eerst de meest relevante feiten op, en laat het model dan schrijven op basis van die feiten.
Zie RAG als “open‑boek AI”. In plaats van het model uit het geheugen te laten antwoorden, laat je je app snel een paar relevante passages ophalen uit betrouwbare bronnen en voeg je die toe aan de prompt. Het model genereert dan een antwoord dat is gegrond in het meegegeven materiaal.
RAG is vaak de standaard keuze wanneer correctheid afhangt van informatie buiten het model:
Als de waarde van je app afhangt van “het juiste antwoord voor ons bedrijf”, is RAG meestal betrouwbaarder dan hopen dat het model het raadt.
RAG is zo goed als wat het ophaalt. Als de zoekstap verouderde, irrelevante of onvolledige passages teruggeeft, kan het model zelfverzekerd een fout antwoord produceren—nu “gegrond” in de verkeerde bron. In de praktijk verbetert het finetunen van retrieval‑kwaliteit (chunking, metadata, actualiteit en ranking) vaak de nauwkeurigheid meer dan prompt‑tweaks.
Een “agent” is gewoon een LLM die in een lus draait: het maakt een plan, voert een stap uit, kijkt naar wat er gebeurd is en beslist wat de volgende stap is. In plaats van één antwoord te geven, iterateert het tot een doel bereikt is.
Een bruikbaar mentaal model is:
Plan → Doe → Check → Herzie
Deze lus verandert een enkele prompt in een kleine workflow. Daarom kunnen agents zelfstandiger aanvoelen dan chat: het model kiest acties en ordent ze.
Agents hebben duidelijke regels nodig voor wanneer te stoppen. Veelvoorkomende stopcondities zijn:
Guardrails zijn de beperkingen die de lus veilig en voorspelbaar houden: toegestane tools, toegestane datasources, goedkeuringsstappen (mens‑in‑de‑lus) en outputformaten.
Omdat een agent altijd “nog een stap” kan voorstellen, moet je ontwerpen voor faalmodi. Zonder budgetten, timeouts en staplimieten kan een agent in een herhalende cyclus vervallen (“probeer nogmaals met een iets andere query”) of kosten opjagen.
Praktische defaults: cap iteraties, log elke actie, valideer toolresultaten en faal gracieus met een gedeeltelijk antwoord plus wat geprobeerd is. Dat is vaak beter productontwerp dan een agent die eeuwig doorgaat.
Als je bouwt met een vibe‑coding platform zoals Koder.ai, is dit “agent + tools” mentale model bijzonder praktisch. Je bent niet alleen aan het chatten voor suggesties—je gebruikt een workflow waarin de assistant kan helpen features plannen, React/Go/PostgreSQL of Flutter componenten genereren en itereren met checkpoints (bijv. snapshots en rollback) zodat je snel kunt bewegen zonder controle te verliezen over wijzigingen.
Wanneer je een LLM achter een app‑feature zet, is je prompt niet langer “alleen tekst”. Het is het interfacecontract tussen je product en het model: wat het model moet doen, wat het mag gebruiken en hoe het moet reageren zodat je code het betrouwbaar kan consumeren.
Een handige mindset is om prompts als UI‑formulieren te behandelen. Goede formulieren verminderen onduidelijkheid, beperken keuzes en maken de volgende actie duidelijk. Goede prompts doen hetzelfde.
Voordat je een prompt uitrolt, zorg dat deze duidelijk zegt:
Modellen volgen patronen. Een sterke manier om het gewenste patroon te “leren” is een enkel voorbeeld van goede input en goede output op te nemen (vooral bij taken met randgevallen).
Zelfs één voorbeeld kan heen‑en‑weer verminderen en voorkomen dat het model een formaat verzint dat je UI niet kan tonen.
Als een ander systeem het antwoord gaat lezen, structureer het. Vraag om JSON, een tabel of strikte bullets.
You are a helpful assistant.
Task: {goal}
Inputs: {inputs}
Constraints:
- {constraints}
Output format (JSON):
{
"result": "string",
"confidence": "low|medium|high",
"warnings": ["string"],
"next_steps": ["string"]
}
Dit verandert “prompting” in voorspelbaar interfaceontwerp.
Voeg een expliciete regel toe zoals: "Als sleutelvereisten ontbreken, stel verduidelijkende vragen voordat je antwoordt."
Die ene regel kan zelfverzekerd‑klinkende, foutieve uitvoer voorkomen—omdat het model dan mag (en verwacht wordt) te pauzeren en de ontbrekende velden te vragen in plaats van te gokken.
In de praktijk zijn de meest betrouwbare prompts degene die passen bij hoe je product bouwt en uitrolt. Bijvoorbeeld: als je platform plannen ondersteunt, dan genereren en vervolgens code uitrollen, kun je dat in het promptcontract weerspiegelen (plan → produceer diff/stappen → bevestig → pas toe). Koder.ai’s “planning mode” is een goed voorbeeld van hoe het expliciet maken van fases drift vermindert en teams helpt wijzigingen te reviewen voordat ze uitrollen.
Vertrouwen komt niet doordat een model zelfverzekerd klinkt. Het komt doordat je AI‑output behandelt als elke andere afhankelijkheid in je product: meetbaar, gemonitord en beperkt.
Begin met een kleine set echte taken die je app goed moet doen. Zet die om in herhaalbare checks:
In plaats van te vragen “Is het goed?”, track je “Hoe vaak slaagt het?” Handige metrics zijn:
Als er iets misgaat, moet je het kunnen replayen. Log (met gepaste redactie):
Dat maakt debuggen praktisch en helpt je te bepalen “Is het model veranderd, of onze data/tools?”
Een paar defaults voorkomen veel incidenten:
Het betekent meestal dat het model samenhangende, doelgerichte tekst kan produceren die lijkt op begrip en redenering. In de praktijk doet een LLM next‑token‑predictie: het genereert de meest waarschijnlijke voortzetting gegeven je prompt, instructies en eventuele meegegeven context.
Voor app‑bouwers is de bruikbare conclusie dat “denken” het gedrag van de uitvoer is dat je kunt vormen en beperken—niet een interne garantie van waarheid.
Een token is een tekstblokje waar het model mee werkt en dat het genereert (een heel woord, een deel van een woord, interpunctie of witruimte). Omdat modellen op tokens werken, niet op “zinnen”, zijn kosten, limieten en afkapping token‑gebaseerd.
Praktisch:
Omdat generatie probabilistisch is. Bij elke stap kent het model vele mogelijke volgende tokens kansen toe, en de meeste systemen sampleen uit die distributie in plaats van altijd de enkele topoptie te kiezen.
Om uitvoer herhaalbaarder te maken:
LLM‑s optimaliseren voor plausibele tekst, niet voor feitencontrole. Ze kunnen zeker klinken omdat zeker klinkende formuleringen veel voorkomen in trainingsdata, zelfs wanneer de onderliggende bewering een gok is.
In productontwerp behandel je vloeiendheid als “goed schrijven”, niet als “juistheid”, en voeg je checks toe (retrieval, tools, tests, goedkeuringen) wanneer correctheid belangrijk is.
Het contextvenster is de maximale hoeveelheid tekst die het model tegelijk kan overzien (systeeminstructies, gespreksgeschiedenis, opgehaalde fragmenten, enz.). Wanneer de thread te lang wordt, valt oudere informatie buiten dat venster en kan het model die niet meer “zien”.
Mitigaties:
Niet automatisch. Standaard doorzoekt het model het web niet, leest het je database niet of voert het geen code uit. Het heeft alleen toegang tot wat je in de prompt zet plus eventuele tools die je expliciet koppelt.
Als je antwoord afhankelijk is van interne of actuele feiten, geef ze dan mee via retrieval (RAG) of een tool‑call in plaats van harder te vragen.
Gebruik tools wanneer je geverifieerde resultaten of echte acties nodig hebt in plaats van plausibele tekst. Veelvoorkomende voorbeelden:
Een goed patroon is voorstel → controleer → pas aan, waarbij het model iterereert op basis van tooluitkomsten.
RAG (Retrieval‑Augmented Generation) is “open‑boek AI”: je app haalt relevante fragmenten uit vertrouwde bronnen (docs, tickets, beleid) en voegt die toe aan de prompt zodat het model antwoorden genereert op basis van die feiten.
Gebruik RAG wanneer:
De belangrijkste foutmodus is slechte retrieval—het verbeteren van zoeken, chunking en actualiteit helpt vaak meer dan prompts tunen.
Een agent is een LLM die een meerstappenloop draait (plan, voer een actie uit, check resultaten, herzie) en vaak tools gebruikt. Het is handig voor workflows zoals “zoek info → stel op → valideer → verzend.”
Om agents veilig en voorspelbaar te houden:
Behandel prompts als een interfacecontract: definieer het doel, inputs, constraints en outputformat zodat je app resultaten betrouwbaar kan gebruiken.
Praktische vertrouwensbouwers: