"Welk AI-model moet ik gebruiken voor programmeren?"
Als ik een euro had gekregen voor elke keer dat iemand me dat de afgelopen zes maanden vroeg, had ik genoeg gehad om mijn API-kosten voor een week te dekken. Misschien.
Dit is het punt — de meeste AI-modelvergelijkingen zijn nutteloos. Ze draaien synthetische benchmarks, testen geïsoleerde codefragmenten en roepen winnaars uit op basis van metrics die niets te maken hebben met hoe we daadwerkelijk werken. Niemand zit nog te wachten tot AI bubble sort-implementaties schrijft. We proberen echte software te bouwen.
Dus deed ik iets anders. Ik nam een monsterlijk Product Requirements Document — afgeleid van een echte, complete applicatie die ik had gebouwd — en gooide het naar vijf verschillende AI-modellen. Dezelfde PRD. Dezelfde instructies. Twee uur de tijd. Laten we zien wie het overleeft.
De resultaten verrasten me. En niet op de manier die ik verwachtte.
De opzet die de meeste modellen breekt
Voordat we erin duiken, laat me uitleggen wat ik eigenlijk testte. Dit was geen speelgoedproject of een "bouw me een todo-app"-prompt. De PRD die ik gebruikte was enorm — gedetailleerde technische documentatie over UI-componenten, backend-architectuur, AI-aangedreven functies, persoonlijkheidsprompts, aanbevelingsmotoren en meer.
Stel het je voor als een dashboard voor een streamingplatform. Gebruikers bladeren door shows, krijgen AI-gestuurde aanbevelingen, verkennen thematische concepten, zien cast- en crew-informatie, bekijken beoordelingen van meerdere bronnen en communiceren met een "alchemie"-functie waarmee je shows kunt combineren om nieuwe content te ontdekken op basis van gecombineerde concepten.
Het soort ding waarvoor een team weken nodig zou hebben om het goed te specificeren. Ik gaf elk model het volledige document en zei "begin hier."
De deelnemers:
- GPT-5.1 Codex Max (de vorige kampioen)
- GPT-5.2 Medium (OpenAI's aanbevolen tier)
- GPT-5.2 Extra High (maximaal denken, maximale kosten)
- Claude Opus 4.5 (Anthropic's vlaggenschip)
Ik wilde weten: Kunnen deze modellen daadwerkelijk complexe, real-world vereisten uitvoeren? Niet alleen functies schrijven — maar samenhangende applicaties bouwen vanuit dichte specificaties?
De eerste 30 minuten: Waar persoonlijkheden tevoorschijn komen
Er gebeurde bijna onmiddellijk iets interessants.
GPT-5.1 Codex Max sprong direct in actie. Bestanden verschenen. Dependencies werden geïnstalleerd. Een server draaide binnen de eerste tien minuten. Het voelde snel. Productief. Alsof je een ontwikkelaar ziet die te veel koffie heeft gehad en gewoon code begint te produceren.
GPT-5.2 modellen — zowel Medium als Extra High — kozen een andere aanpak. Ze besteedden meer tijd aan nadenken. Verwerken. Je kon ze bijna door de PRD zien lezen, proberend de volledige scope te begrijpen voordat ze één regel schreven.
En dan was er Opus 4.5.
Hier werd het interessant. Opus begon niet gewoon te coderen. Het begon met mij te praten. Een takenlijst verscheen. Het verwoordde wat het uit de PRD begreep. Het stelde verduidelijkende vragen. Het zei dingen als "Op basis van de vereisten ga ik dit structureren als..." voordat het iets deed.
Ik zal niet liegen — in het begin voelde dit langzamer. Maar er klopte iets aan.
De communicatiekloof waar niemand over praat
Laat me hier even pauzeren want dit werd het allerbelangrijkste inzicht van het hele experiment.
GPT-modellen beginnen onmiddellijk met coderen. Ze lezen je prompt en voeren uit. Geen bevestiging. Geen "dit is wat ik begrepen heb." Gewoon actie.
Opus-modellen communiceren eerst. Ze erkennen wat je vroeg. Ze leggen hun interpretatie uit. Ze laten je de routekaart zien voordat ze de weg bouwen.
Waarom is dit belangrijk?
Omdat je, wanneer je met AI aan complexe taken werkt, moet weten wat het daadwerkelijk begrepen heeft. Als GPT-5.2 een vereiste verkeerd interpreteert en het verkeerde bouwt, weet je het pas als je de kapotte output ziet. Als Opus iets verkeerd interpreteert, vertelt het je dat van tevoren — en kun je het corrigeren voordat er code geschreven wordt.
Dit gaat niet over welk model "slimmer" is. Het gaat over welk model samenwerking minder als gokken laat voelen.
Ik heb gewerkt met junior ontwikkelaars die sneller coderen dan seniors. Snelheid is niet hetzelfde als productiviteit. De beste medewerkers — mens of AI — bevestigen begrip voordat ze uitvoeren.
Uur één: De feature-race
Bij het zestig-minuten-punt werden de verschillen scherp.
GPT-5.1 Codex Max had een draaiende applicatie. Het zag er... functioneel uit. Basis-CSS, wat ontbrekende styling, maar de kernstructuur was er. Ontbrekende functies waren echter duidelijk — geen aanbevelingsmotor, beperkte metadata-weergave, onvolledige navigatie.
GPT-5.2 Medium toonde verbetering ten opzichte van 5.1. De UI voelde gepolijster. Het raakte meer van de gevraagde functies. Maar key art ontbrak. Sommige interactieve elementen waren niet aangesloten. Het "medium" in de naam voelde accuraat — midden op de weg.
GPT-5.2 Extra High was langzamer maar grondiger. De interface was schoner. Toegankelijker. Logische lay-out. De aanbevelingsmotor werkte. Metadata werd correct opgehaald. Cast- en crew-informatie werd correct weergegeven. Het was oprecht indrukwekkend — totdat ik merkte dat de afleveringslijsten onder TV-showseizoenen volledig ontbraken.
Opus 4.5 bouwde iets anders. Rijkere visuele elementen. Animaties die ik niet specifiek had gevraagd maar die logisch waren. Financiële gegevensweergaven (winst, ROI). Duidelijke uitsplitsingen van beoordelingen en genres. En — dit is cruciaal — een inline trailerplayer die geen van de GPT-modellen zelfs maar probeerde.
Maar Opus's UI was ook complexer. Drukker. Moeilijker te navigeren op het eerste gezicht. Het optimaliseerde voor volledigheid boven eenvoud.
De gap-document-onthulling
Dit is iets dat alles veranderde.
Geen van de modellen voltooide de PRD volledig in één keer. Niet eens in de buurt. Ze misten allemaal functies. Ze maakten allemaal aannames. Ze hadden allemaal hiaten.
Dus maakte ik wat ik een "gap-document" noem — een tweede prompt die alles opsomde wat de initiële build miste, waarbij elk model in wezen werd gevraagd zichzelf te auditen tegen de oorspronkelijke vereisten en de gaten op te vullen.
Dit is waar GPT-5.2 Extra High en Opus 4.5 dramatisch vooruit trokken.
Beide modellen reageerden op het gap-document door systematisch ontbrekende functies aan te pakken. Afleveringslijsten verschenen. Aanbevelingslogica verbeterde. UI-polish nam toe. Binnen nog een uur iteratie hadden beide wat ik schat op 90-95% functievolledigheid bereikt.
De oudere GPT-5.1? Die worstelde. Het raakte in de war over wat het al had gebouwd versus wat er werd gevraagd. Contextbeheer werd een probleem.
De les: Geen enkel AI-model vandaag kan een complexe PRD volledig autonoom uitvoeren. Maar de beste kunnen er opmerkelijk dichtbij komen met één ronde gestructureerde feedback. Het gat zit niet in ruwe capaciteit — het zit in zelf-auditing.
UI-filosofie: Elegantie vs volledigheid
Laat me het hebben over de visuele outputs want ze onthullen iets belangrijks over hoe deze modellen denken.
GPT-5.2 Extra High produceerde wat ik "ontwikkelaarsvriendelijke" interfaces zou noemen. Schoon. Voorspelbaar. Het soort UI dat makkelijk te gebruiken is omdat het niet te veel tegelijk probeert te doen. Goede spacing. Logische informatiehiërarchie. Als je het aan een productmanager zou laten zien, zouden ze het waarschijnlijk goedkeuren zonder veel wijzigingen.
Opus 4.5 bouwde iets ambitieuzers. Elk mogelijk datapunt kwam aan de oppervlakte. Meerdere interactiepatronen. Visuele rijkdom die grensde aan overweldigend. Het voelde alsof Opus probeerde te bewijzen dat het elke vereiste begreep door ze allemaal tegelijkertijd te tonen.
Geen van beide benaderingen is fout. Maar ze dienen verschillende doelen.
Als je een snel prototype nodig hebt om een idee te valideren, brengt GPT-5.2's schonere output je daar sneller. Als je uitgebreide functiedekking nodig hebt en het niet erg vindt om de presentatie later te verfijnen, geeft Opus je meer om mee te werken.
Ik merkte dat ik GPT-5.2's output als UI-referentie gebruikte terwijl ik functie-implementaties van Opus haalde. De combinatie werkte beter dan elk afzonderlijk.
De AI-functies: Waar het interessant wordt
Beide modellen implementeerden AI-aangedreven functies — conceptextractie, thematische aanbevelingen, dynamische verkenning op basis van gebruikersvoorkeuren. Dit is waar de PRD ingewikkeld werd, en waar ik verwachtte dat modellen zouden worstelen.
Dat deden ze niet. Niet echt.
De aanbevelingsmotoren werkten. Ze begrepen semantische relaties tussen shows. Ze konden uitleggen waarom twee schijnbaar verschillende series dezelfde kijker zouden kunnen aanspreken.
Opus's "alchemie"-functie viel op. Het liet gebruikers meerdere shows combineren en overlappende thematische concepten extraheren om nieuwe aanbevelingen te vinden. Dit stond in de PRD, maar het vereiste begrip van een vrij abstract concept. Opus nagelde het. De mashup-interface was intuïtief, en de aanbevelingen die het genereerde waren daadwerkelijk logisch.
GPT-5.2 implementeerde alchemie ook, maar meer letterlijk. Het combineerde shows en spuwde aanbevelingen uit. De magie — de meta-analyse van waarom bepaalde combinaties werkten — was er niet.
Voor AI-ondersteund coderen van AI-functies had Opus de voorsprong. Het begreep de intentie achter de vereisten, niet alleen de letterlijke specificaties.
Wat niemand goed kreeg
Laten we het over mislukkingen hebben want die zijn net zo belangrijk als successen.
Key art. Elk model worstelde met showafbeeldingen. De PRD specificeerde integratie met externe API's voor posterart en thumbnails. Geen enkel model haalde ze betrouwbaar op en toonde ze. Sommige maakten tijdelijke aanduidingsboxen. Sommige negeerden ze volledig. Geen enkele kreeg het volledig werkend.
Trailers. Alleen Opus probeerde inline trailer-afspeling. De anderen sloegen het over of genereerden kapotte implementaties.
Zelf-auditing. Geen enkel model controleerde natuurlijk zijn eigen werk tegen de oorspronkelijke PRD. Ze hadden allemaal expliciete gap-documenten nodig om ontbrekende functies te identificeren. Dit suggereert dat huidige AI-modellen goed zijn in uitvoeren maar slecht in het valideren van hun eigen output.
Mediaverwerking in het algemeen. Tekstgebaseerde functies waren solide. Alles met externe assets — afbeeldingen, video's, API-integraties — bleef achter. De modellen konden de code schrijven, maar het debuggen van API-responses en het afhandelen van randgevallen vereiste nog steeds menselijke interventie.
Snelheid vs kwaliteit: De echte afweging
Laat me je concrete cijfers geven.
GPT-5.1 Codex Max: Snelste initiële output. Laagste functievolledigheid. Meeste bugs. Tijd tot "bruikbaar" prototype: ~45 minuten. Tijd tot "complete" applicatie: Lukte niet binnen twee uur.
GPT-5.2 Medium: Matige snelheid. Redelijke functiedekking. Enkele afwerkingsproblemen. Tijd tot bruikbaar prototype: ~60 minuten. Tijd tot bijna-compleet: ~100 minuten met gap-document.
GPT-5.2 Extra High: Langzaamste initiële output. Hoge functievolledigheid. Schone UI. Tijd tot bruikbaar prototype: ~75 minuten. Tijd tot bijna-compleet: ~110 minuten met gap-document.
Opus 4.5: Vrij snelle initiële output (server startte vroeg). Hoogste functievolledigheid. Complexe UI. Tijd tot bruikbaar prototype: ~50 minuten. Tijd tot bijna-compleet: ~95 minuten met gap-document.
Als je puur optimaliseert voor snelheid, is GPT-5.2 Medium logisch. Als je optimaliseert voor volledigheid en niet bang bent voor iteratie, levert Opus 4.5 meer functies per bestede euro.
De kostenformule waar niemand over wil praten
Deze modellen zijn niet gratis. En de "Extra High"-tier van GPT-5.2 kost aanzienlijk meer dan Medium.
Dit is mijn eerlijke mening: GPT-5.2 Extra High rechtvaardigde zijn premie ten opzichte van Medium niet voor deze taak. Ja, de output was schoner. Ja, het ving een paar meer vereisten op. Maar de marginale verbetering was de 3-4x hogere kosten niet waard.
Opus 4.5, ondanks de hoge kosten, voelde het waard. De communicatiestijl alleen al bespaarde debugtijd. De functievolledigheid verminderde iteratiecycli. Het begrip van complexe AI-vereisten betekende minder herwerk.
Kostenefficiëntie is belangrijk. Anthropic's model leverde meer waarde per conversatiebeurt dan OpenAI's hoogste tier. Dat is geen fanboy-uitspraak — dat is boekhouding.
Wat dit betekent voor echte ontwikkeling
Laat me direct zijn: Noch GPT-5.2 noch Opus 4.5 vervangt binnenkort ontwikkelaars.
Maar ze vervangen maanden werk door uren werk. Dat is niet niks. Dat is transformatief.
De applicatie die ik als basis voor deze PRD gebruikte, kostte een team oorspronkelijk meerdere weken om te bouwen. Deze AI-modellen bereikten 90-95% functiepariteit in minder dan twee uur. De resterende 5-10% — de randgevallen, de afwerking, het debuggen — heeft nog steeds menselijke aandacht nodig. Maar het zware werk? Gedaan.
Dit verandert hoe we over prototyping denken. Het verandert hoe we ideeën valideren. Het verandert de economie van software bouwen.
We zijn nog niet bij "prompt en verzend". We zijn bij "prompt, controleer, itereer en verzend sneller dan ooit." Dat is nog steeds een enorme verschuiving.
Mijn aanbeveling
Na het uitvoeren van dit experiment, dit is wat ik een andere ontwikkelaar zou vertellen:
Gebruik Opus 4.5 wanneer:
- Je iets complexs bouwt met AI-gedreven functies
- Je hoge functievolledigheid nodig hebt en het niet erg vindt om de UI te verfijnen
- Je communicatie waardeert en begrip wilt verifiëren voor uitvoering
- Je bereid bent een premie te betalen voor verminderde iteratiecycli
Gebruik GPT-5.2 Medium wanneer:
- Je snelle prototypes nodig hebt voor validatie
- De UI belangrijker is dan functiediepte
- Budget een primaire beperking is
- Je comfortabel bent met meer hands-on debugging
Sla GPT-5.2 Extra High over. Voor de meeste use cases rechtvaardigt het de kostenpremie ten opzichte van Medium niet. De incrementele verbeteringen zijn niet genoeg.
Doe geen moeite meer met GPT-5.1 Codex Max. Het is ingehaald. De nieuwere modellen zijn aantoonbaar beter.
Het grotere plaatje
We zien AI-codeertools in realtime evolueren. Zes maanden geleden zou het vragen aan een model om een complexe PRD uit te voeren lachwekkend zijn geweest. Vandaag is het haalbaar — met kanttekeningen.
De kloof tussen "AI-gegenereerde code" en "productie-klare code" krimpt. Hij is niet weg. Maar hij krimpt snel.
De ontwikkelaars die uitzoeken hoe ze effectief met deze tools kunnen samenwerken — die leren betere PRD's te schrijven, die de kunst van gap-documenten beheersen, die begrijpen welk model ze voor welke taak moeten gebruiken — zij zullen een enorm voordeel hebben.
Dit gaat niet over vervangen worden. Het gaat over versterkt worden.
De beste menselijke ontwikkelaars zullen AI gebruiken om hun output te vermenigvuldigen. Degenen die zich verzetten zullen zich afvragen waarom iedereen anders sneller levert.
Ik weet aan welke kant ik sta.
Laatste gedachten
Als je één ding meeneemt uit dit experiment, laat het dit zijn: Stop met het evalueren van AI-modellen op synthetische benchmarks. Test ze op je daadwerkelijke werk. Geef ze je rommelige, complexe, real-world vereisten. Kijk wat er gebeurt.
De resultaten zouden je kunnen verrassen.
Ze verrasten mij zeker.
🤝 Inhuren / Samenwerken:
- 🔗 Fiverr (custom builds, integraties, performance): fiverr.com/s/EgxYmWD
- 🌐 Mejba Persoonlijk Portfolio: mejba.me
- 🏢 Ramlit Limited: ramlit.com
- 🎨 ColorPark Creatief Bureau: colorpark.io
- 🛡 xCyberSecurity Wereldwijde Diensten: xcybersecurity.io
