De meeste developers gebruiken AI op dezelfde manier: prompt typen, output doornemen, beslissen dat het er goed uitziet, committen.
Die derde stap — "beslissen dat het er goed uitziet" — is waar het stil misgaat. Je beoordeelt AI-output aan de hand van een vaag mentaal beeld van wat je gevraagd hebt. Het model klinkt even zelfverzekerd of het nu goed of fout zit. En jij bent de enige reviewer van iets wat jij niet hebt geschreven.
De oplossing is niet zorgvuldiger promppen. Het is een fundamenteel ander proces.
Rollen, geen prompts
Het idee is simpel. In plaats van AI te vragen wat het moet bouwen, vraag je het na te denken over wat het moet bouwen — vanuit meerdere conflicterende invalshoeken, nog voordat er code bestaat.
Je definieert drie rollen. Elk krijgt een apart mandaat. Elk heeft een andere reden om terug te duwen.
De Architect ontwerpt de oplossing voordat er ook maar één regel code wordt geschreven. Zijn output is geen code — het is een kaart. Componenten, interfaces, invarianten, afwegingen, risico's. Een structuur om over te redetwisten.
De Fact Checker ondervraagt die kaart. Bestaat de library waar naar verwezen wordt echt? Is de prestatieclaim realistisch op schaal? Zijn er bekende kwetsbaarheden in deze aanpak? Hij repareert niets — hij rapporteert wat hij vindt.
De Devil's Advocate leest het ontwerp en de aantekeningen van de Fact Checker, en probeert het vervolgens te breken. Faalscenario's, randgevallen, kwaadaardige input, onderhoudsnachtmerries achttien maanden later. Zijn taak is de sterkst mogelijke case te maken dat het ontwerp zal falen.
Drie perspectieven. Één vereiste. Nul regels productiecode geschreven.
Eén prompt voor alles
Je hebt geen drie aparte sessies of een orchestratielaag nodig. Eén prompt regelt dit. Instrueer het model om alle drie de rollen in volgorde te spelen — het zal dat doen, elke sectie na elkaar.
You will analyse the following requirements by playing three distinct roles in sequence.
Complete each role fully before moving to the next. Do not write implementation code at any point.
---
ROLE 1 — THE ARCHITECT
Produce a design document covering:
1. Components and their responsibilities
2. Interfaces between them (inputs, outputs, contracts)
3. Invariants that must hold under all conditions
4. Trade-offs and what is explicitly being accepted
5. The top three risks and how you would mitigate them
---
ROLE 2 — THE FACT CHECKER
Review the design above and verify every factual claim:
- Do referenced libraries and APIs actually exist and behave as described?
- Are performance characteristics realistic?
- Are there known vulnerabilities in any approach described?
- Are there implicit assumptions stated as facts?
Report each issue with: the claim, why it's suspect, what would confirm or refute it.
---
ROLE 3 — THE DEVIL'S ADVOCATE
Now argue against the design as forcefully as possible:
- Every failure mode you can imagine, including unlikely ones
- What happens when assumptions are violated (load spikes, malformed inputs, third-party outages)
- How an attacker would approach this design
- What this looks like to a new engineer 18 months from now
- Conditions under which this design would need to be completely replaced
---
Requirements:
[YOUR REQUIREMENTS HERE]Één response. Drie gestructureerde perspectieven. Voor de overgrote meerderheid van features is dit alles wat je nodig hebt.
Parallel gaan met Claude
Wanneer de inzet hoger is — een nieuwe auth-flow, een betalingsintegratie, alles wat security-kritiek is — is het de moeite waard de rollen in aparte agent-calls te splitsen.
De sleutelinzicht: de Fact Checker en de Devil's Advocate zijn niet van elkaar afhankelijk. Beide hebben de output van de Architect nodig, maar geen van beide hoeft op de ander te wachten. Met Claude's API schiet je ze gelijktijdig af zodra de Architect klaar is. Twee parallelle requests, twee rapporten tegelijk terug.
Architect
/ \
▼ ▼
Fact Checker Devil's Advocate
(parallel) (parallel)
\ /
▼ ▼
Jij reviewt alle drieDit is ook waar verschillende modellen per rol het verschil maken. Als beide agents hetzelfde contextvenster delen, nemen ze dezelfde biases mee van rol naar rol. De Fact Checker weet impliciet wat de Architect dacht. De Devil's Advocate houdt zich misschien in op een ontwerp dat hij zojuist zelf produceerde. Echte onafhankelijkheid vereist echte scheiding.
Wat je met de output doet
Alle drie de documenten landen voor je. Je leest ze. Je neemt beslissingen.
Dat is het. Dat is de rol van de mens — en die is niet onderhandelbaar.
Wat verandert is de kwaliteit van de informatie waarop je beslist. In plaats van gegenereerde code te reviewen aan de hand van een vaag geheugen van wat je vroeg, kijk je naar een gestructureerd argument: een ontwerp, de verificatie ervan, en een rigoureuze aanval erop. De beslissing is nog steeds van jou. Maar je neemt hem met betere input dan je ooit eerder had.
De agents beantwoorden je vraag niet. Ze zorgen ervoor dat je de juiste vraag stelt.
Wanneer je dit gebruikt
Niet voor alles. Een hulpfunctie, een standaard patroon dat je al twintig keer hebt gebouwd, een doorsnee CRUD-endpoint — prompt het gewoon en review het zelf. De overhead is het niet waard.
Maar voor alles waarbij fout zitten echte gevolgen heeft: gebruik de rollen. Een paar minuten gestructureerde analyse voordat je een regel code schrijft, bespaart je uren aan het ontwarren van de verkeerde implementatie later.
De single-prompt versie kost bijna niets. De parallelle Claude-opzet kost een paar extra seconden. Geen van beide is een reden om het niet te gebruiken als de inzet het rechtvaardigt.
Stem het process af op het risico. Dat is de enige regel.