Wanneer Claude het mis heeft (en ik doorvraag)

Een van de hardnekkigste misverstanden over AI-bouw is dat AI altijd gelijk heeft. Of bijna altijd. Of vaak genoeg dat je het kunt vertrouwen.

Dat klopt niet. AI is heel goed, ook in mijn ervaring. Maar het is ook zelfverzekerd over dingen waar het niet zeker over zou moeten zijn. Als jij niet doorvraagt, krijg je een mooie eerste indruk en een keuze die misschien niet de beste was.

Deze week had ik een concreet voorbeeld dat ik wil delen. Niet om Claude af te zeiken, maar om te laten zien hoe het zesogenprincipe in de praktijk werkt.

De situatie

Voor playitsmart heb ik een architectuur waarin twee verschillende workloads hun eigen plek nodig hebben:

1. De website (Next.js, mensen die playitsmart.nl bezoeken)
2. De Python trading job die elke ochtend draait, FMP data ophaalt, scores berekent, en straks via IBKR orders plaatst

Ik vroeg Claude eerder welke hosting we moesten gebruiken. Het advies was duidelijk: Vercel voor de website, Render voor de trading job. Twee platforms, ieder goed in zijn eigen rol.

Klopt allemaal. Maar bij het opzetten kwam de vraag terug: hoeft het echt op twee platforms? Kan ik niet alles op Vercel, of alles op Render? Vereenvoudigt mijn leven. Eén dashboard, eén factuur, één ding om te leren.

Eerste antwoord van Claude

Ik vroeg het. Claude gaf een goed onderbouwd antwoord. Vercel kan de Python trading job fundamenteel niet, omdat:

• Vercel is serverless: functies draaien maximaal 60 seconden tot 5 minuten, mijn job duurt 10 tot 15 minuten
• IBKR API werkt via een stateful TCP verbinding, Vercel kan dat fundamenteel niet hosten
• Python als primaire runtime is op Vercel beperkt, Node.js is daar thuis

Sterk antwoord met een tabel van concrete limieten en alternatieven. Render werd aanbevolen om drie redenen: server-based dus lange jobs mogelijk, native Python support, scheduled tasks als first-class concept.

Tot zover overtuigend.

Maar dan: doorvragen

Ik geloofde het deel over Vercel. Maar ik wilde weten: waarom Render specifiek? Er zijn meer platforms in dat segment. Railway is populair, Fly.io ook. Ik vroeg:

"En hoe zie je Railway dan? Die wordt toch ook veel gebruikt? Weet je zeker dat dat niet beter past?"

Het tweede antwoord van Claude was anders dan het eerste. Geen herhaling van de Render aanbeveling, geen verdediging. Juist het tegenovergestelde:

"Goede vraag om door te drukken. Je hebt helemaal gelijk dat Railway heel populair is, en eerlijk: voor veel projecten is het de betere keuze. Laat me eerlijk zijn, niet koppig vasthouden aan mijn eerste voorstel."

Daarna een echte vergelijking. Railway heeft mooiere UI, snellere deploys, usage-based pricing. Render heeft langere request timeouts, voorspelbaardere kosten, native cron support.

En toen kwam waar ik op zat te wachten: de specifieke afweging voor mijn use case. Niet generiek "Render is beter", maar concreet:

• Mijn cron job duurt 10-15 minuten, past bij Render zonder workarounds
• Mijn IBKR Gateway moet straks 24/7 draaien, Railway's credit-based pricing kan plotseling duur worden
• Cron jobs zijn op Render first-class, op Railway moet je workarounds bouwen

Conclusie: voor mijn use case Render. Voor een ander project zou Railway zomaar de eerste suggestie kunnen zijn.

Wat hier gebeurde

Twee dingen die ik wil benoemen.

Eén: Claude's eerste antwoord was niet fout, maar ook niet volledig. Het presenteerde Render alsof het de evidente keuze was, zonder te benoemen dat er prima alternatieven zijn. Dat is een patroon dat AI vaker doet. Een gemotiveerde aanbeveling klinkt als hét antwoord, terwijl het eigenlijk één van meerdere goede antwoorden is.

Twee: Claude verdedigde zijn eerste keuze niet. Bij doorvragen gaf hij meteen toe dat het meer smaak was dan objectiviteit. Daarna kwam wel een onderbouwde finale keuze, gebaseerd op mijn specifieke context.

Dit is hoe ik wil dat het werkt. Niet: AI heeft het altijd bij het juiste eind. Wel: AI geeft een doordacht eerste antwoord, en bij doorvragen ontstaat een betere afweging.

Waar dit fout kan gaan

Stel dat ik niet had doorgevraagd. Dan had ik Render gekozen op basis van een aanbeveling die ik niet helemaal had gewogen. Misschien werkt Render goed, misschien had Railway voor mij ook gewerkt. Ik had het niet geweten.

Erger: stel dat ik gevoelsmatig Railway leuker had gevonden, en toch Render gekozen omdat "de AI dat zei". Dan zou ik gefrustreerd zijn geweest na een week, zonder begrijpen waarom.

Doorvragen is geen wantrouwen. Het is verantwoordelijk omgaan met beslissingen. Mijn keuze, mijn project, mijn risico's.

Wat ik mensen die starten aanraad

Drie regels die ik voor mezelf hanteer:

Regel één: Bij elke aanbeveling vraag minstens één keer door. Niet "is dit goed?", wel "wat zijn alternatieven en waarom precies deze?"

Regel twee: Geef AI permissie om zijn eerste antwoord te heroverwegen. Letterlijk vragen: "weet je zeker dat dit beste past, of is het meer smaak?" Het verschil in antwoord kan groot zijn.

Regel drie: Beslis zelf. Niet omdat AI beter of slechter is, maar omdat jij de consequenties draagt. Als de hosting fout is, betaal jij. Niet AI.

Tot slot

Ik gebruik AI elke dag voor dit project. Voor design, architectuur, review, content. Het versnelt me met factor tien.

Maar dat versnellen werkt alleen als ik de kritische rol blijf vervullen. Het zesogenprincipe is geen luxe. Het is de reden dat de output betrouwbaar is. Drie perspectieven op elke beslissing: ik, Claude (denken en review), en Cursor (bouwen). Geen daarvan mag overgeslagen worden.

Bij twijfel: doorvragen. Bij stelligheid: dubbel doorvragen.