Samengesteld door de llmnet.nl-redactie met AI-ondersteuning · Laatst bijgewerkt: 27 juli 2026
Wanneer je als individuele ontwikkelaar of onderzoeker met Large Language Models (LLM's) werkt, is de verleiding groot om prompts ad-hoc aan te passen. Een woordje hier, een instructie daar, totdat de output er in de playground goed uitziet. Zodra AI-toepassingen echter de kern vormen van productieapplicaties, is deze "cowboy-aanpak" niet langer houdbaar. Prompts moeten binnen een team op een gestructureerde manier worden behandeld, beoordeeld en goedgekeurd.
In dit artikel bespreken we waarom je prompts zou moeten reviewen met dezelfde discipline waarmee je softwarecode (zoals Python of JavaScript) reviewt. We behandelen het inrichten van testsets, het scheiden van subjectieve smaak en meetbare kwaliteit, en we bieden een concreet sjabloon dat je vandaag nog in jullie pull requests kunt integreren.
Een prompt is niet zomaar een stukje tekst; het is gedeclareerde logica. Waar traditionele code het hoe definieert, definieert een prompt het wat. Een ogenschijnlijk onschuldige aanpassing in een prompt kan verstrekkende gevolgen hebben voor de betrouwbaarheid en veiligheid van de applicatie. Daarom is het essentieel om te werken met gedegen prompt-versiebeheer.
Binnen een team ontstaan vaak de volgende problemen als prompts niet structureel worden gereviewd:
Een fundamentele regel bij het reviewen van prompts is: je kunt een wijziging niet beoordelen zonder bewijs. Omdat de output van een LLM niet-deterministisch is (zelfs bij een temperatuur van 0 is absolute consistentie niet gegarandeerd over tijd), kan een reviewer niet simpelweg naar de prompt kijken en met 100% zekerheid zeggen: "Dit gaat werken".
Voor elke significante prompt-wijziging moet de ontwikkelaar de prompt draaien tegen een gouden standaard: de testset. Een goede testset voor prompts bevat:
Tijdens een review moet de auteur niet alleen de nieuwe prompt aanleveren, maar ook een diff (verschil) van de gegenereerde output ten opzichte van de vorige prompt-versie, op basis van de afgesproken testset. Meer over het gestructureerd testen van LLM-outputs lees je op ons zusterplatform in de gids over LLM kwaliteitsborging en validatie.
Een van de grootste valkuilen tijdens een prompt-review is de discussie over smaak. Zinnen als "Ik vind dit antwoord niet vriendelijk genoeg klinken" of "Misschien moet het iets korter" zijn funest voor de voortgang. Ze leiden tot eindeloze iteraties zonder duidelijk einddoel.
Om effectief in teamverband te reviewen, moet subjectieve smaak worden omgezet in meetbare rubric-criteria. Bij het beoordelen van veelvoorkomende prompt-fouten hanteren we objectieve standaarden.
| Subjectieve Feedback (Fout) | Meetbare Feedback (Goed) |
|---|---|
| "De toon is te saai." | "De output mist de voorgeschreven merkidentiteit: gebruik maximaal 2 zinnen per alinea en spreek de lezer aan met 'jij'." |
| "Het antwoord is te lang." | "De output overschrijdt de strikte limiet van 150 woorden die in de systeeminstructie is vastgelegd." |
| "Het voelt alsof het model hallucineert." | "Het model claimt feiten in alinea 3 die niet in de meegeleverde RAG-context (Retrieval-Augmented Generation) staan." |
Om discussies over subjectiviteit verder in te dammen, zetten volwassen AI-teams vaak een ander LLM (vaak een zwaarder, langzamer model zoals GPT-4 of Claude 3 Opus) in om de output van de aangepaste prompt te scoren. Dit principe, waarbij een onafhankelijke prompt de kwaliteit van een andere prompt beoordeelt op een schaal van 1 tot 5 aan de hand van vastgestelde criteria, biedt een kwantitatieve basis voor de menselijke reviewer.
Een prompt leeft nooit in een vacuüm; hij is onlosmakelijk verbonden met het onderliggende model. Wanneer OpenAI, Google of Anthropic een model updatet (bijvoorbeeld van versie 0613 naar 1106), kan de semantiek van je prompt ineens anders geïnterpreteerd worden. Wat voorheen een perfecte JSON-output opleverde, resulteert nu misschien in JSON met ongewenste markdown-wrappers.
Een goede teampraktijk is om prompt-versies altijd vast te pinnen aan een specifieke model-versie. Wanneer een model-upgrade nodig is, wordt dit behandeld als een major breaking change. De bestaande prompts moeten door de volledige testset heen, en het review-proces richt zich specifiek op "model drift": de subtiele manieren waarop de nieuwe modelversie afwijkt van de oude. Verdieping in dit fenomeen vind je in ons overzichtsartikel over de impact van model updates op productieomgevingen.
Als iedereen verantwoordelijk is, is niemand verantwoordelijk. Binnen een ontwikkelteam moet er duidelijkheid zijn over het eigenaarschap van prompts. We zien in de praktijk vaak de volgende rolverdeling:
Tijdens een pull request (PR) voor een kern-prompt moet er minimaal een goedkeuring (approval) zijn van degene die de applicatielogica beheert, en—bij inhoudelijke wijzigingen—de domeinexpert.
Een prompt zonder documentatie is legacy code vanaf het moment dat hij wordt gecommit. Om een prompt goed te kunnen reviewen én onderhouden, is randinformatie essentieel. Deze documentatie hoort idealiter thuis in een centrale prompt-bibliotheek of op zijn minst in een docstring boven de code waarin de prompt wordt aangeroepen.
Een complete prompt-documentatie bevat altijd:
Om het reviewproces in de praktijk soepel te laten verlopen, raden we aan om een standaard Pull Request-sjabloon in te richten in platforms zoals GitHub, GitLab of Azure DevOps. Hieronder vind je een lichtgewicht sjabloon dat specifiek is ontworpen voor prompt-wijzigingen.
pull_request_template.md of maak er een specifieke issue-template van binnen jullie repository.
Het bouwen van robuuste AI-applicaties vereist dat we afstappen van het idee dat prompts magische tekstjes zijn die we iteratief in een webinterface aanpassen. Door prompts te behandelen als een fundamenteel onderdeel van je codebase—inclusief versiebeheer, objectieve testsets, helder eigenaarschap en formele peer reviews—verhoog je de stabiliteit van je applicatie en verlaag je de stress binnen het development team. De invoering van een review-sjabloon zoals hierboven beschreven, is een uitstekende eerste stap naar een volwassen AI-ontwikkelproces.