Menselijke review vs volledig AI-gegenereerde code: waarom het verschil het product is
Date Published
Volledig AI-gegenereerde code en gereviewde AI-code kunnen uit hetzelfde model op dezelfde prompt komen en toch twee verschillende producten zijn. De gereviewde versie is software waarop je een bedrijf draait. De niet-gereviewde versie is een demo die nog niet is gefaald. De review is het verschil.
Elk efficiënt team gebruikt inmiddels AI om code te schrijven, dus "gebruiken jullie AI?" is geen nuttige vraag meer. De vraag die een betrouwbare leverancier scheidt van een onbetrouwbare is nauwer: wie leest de code voordat die live gaat, en wat vangt die persoon? Beide antwoorden volgen hieronder, in het detail waarnaar de rest van ons vibe coding-cluster steeds terugwijst. Voor de praktijk waarop deze review rust, begin je met vibe coding en AI-ondersteunde ontwikkeling.
Dezelfde code, twee verschillende producten
Een AI-model produceert code die er plausibel uitziet. Plausibel is niet dezelfde bewering als correct, veilig of onderhoudbaar, en het model draagt geen gevolg van het gat daartussen. Het heeft de prompt beantwoord. Of het antwoord standhoudt is het probleem van iemand anders, en in een gevibecodeerd project is die iemand niemand.
De menselijke review dicht dat gat. Een senior engineer leest wat het model schreef, stelt het ter discussie, corrigeert het, en laat het pas daarna mergen. Aan de generatiestap verandert niets. Aan het resultaat verandert alles. De code ging van een onderbouwde gok naar een gereviewde beslissing, en je bedrijf kan er nu op bouwen. Zelfs Google, dat meer dan een kwart van zijn nieuwe code met AI genereert, houdt engineers die het reviewen voordat het wordt geaccepteerd (The Verge, 2024). De organisaties die het best zijn in AI-code zijn de organisaties die het meest gedisciplineerd zijn in het lezen van wat het produceert.
Wat een menselijke reviewer echt vangt
Een review is geen stempel. Het is waar vier precieze faalscenario's worden gestopt, dezelfde vier die recht naar productie gaan wanneer niemand de code leest. Ons artikel over of AI-code veilig is behandelt de risicolijst; hier is wat de reviewer met elk ervan doet.
Beveiligingslekken die het model uit zijn trainingsdata kopieerde. Grote taalmodellen leerden van publieke code, fouten inbegrepen. Het 2025 GenAI Code Security Report van Veracode stelde vast dat 45% van de door AI gegenereerde voorbeelden bekende kwetsbaarheden bevatte: hardgecodeerde inloggegevens, ontbrekende invoervalidatie, injectiegevoelige queries. Een reviewer vangt de blootgestelde sleutel en het niet-gevalideerde formulierveld in de diff, voordat ze een incident worden.
Dependencies die niet bestaan. Modellen importeren soms softwarepakketten die ze verzonnen hebben. Een USENIX Security-studie uit 2025 mat dat ongeveer 5,2% van de door commerciële modellen voorgestelde pakketten gehallucineerd was, oplopend tot ongeveer 21,7% bij open source-modellen. Aanvallers registreren echte malware onder die verzonnen namen, zodat de volgende persoon die de mislukte import "repareert" die installeert. Een reviewer, gesteund door een dependency-scan, voorkomt dat de fictieve import ooit de build bereikt.
Logica die fout is zonder te crashen. Een korting die op één valuta de verkeerde kant op afrondt, een datumfilter dat de laatste dag van de maand weglaat, een rechtencontrole die slaagt voor elke rol behalve de niet-geteste: deze draaien wekenlang schoon en komen pas aan het licht wanneer een klant merkt dat het totaal niet klopt. Een reviewer die het bedrijf begrijpt, leest op intentie, niet alleen op of het compileert.
Code die vandaag werkt en morgen niet kan veranderen. Modellen dupliceren logica in plaats van die te hergebruiken, omdat elke prompt vers wordt beantwoord, zonder geheugen van de codebase. Een reviewer voegt de duplicatie weer samen en houdt de architectuur samenhangend, wat voorkomt dat een kleine wijziging zes maanden later iets ongerelateerds breekt.
Waarom geautomatiseerde tools alleen niet volstaan
De gangbare tegenwerping is dat scanners en linters de mens kunnen vervangen. Dat kunnen ze niet, en ze als vervanging behandelen is een faalscenario op zich.
Geautomatiseerde dependency-scanning is echt waardevol, en die draait op elke serieuze build: een pakket met een bekende beveiligingswaarschuwing moet de build laten falen in plaats van de productie te bereiken. Maar een scanner toetst bekende patronen aan bekende databases. Hij weet niet dat jouw kortingslogica de verkeerde kant op afrondt, dat een rechtengrens op de verkeerde plek zit, of dat het model het verkeerde probleem correct heeft opgelost. Dat zijn afwegingen, en een afweging is precies wat een model, en een linter, missen.
De juiste verhouding is gelaagd, geen of-of. Tools vangen de mechanische fouten op machinesnelheid en -schaal. Een mens vangt die welke vragen om begrip van het bedrijf dat de software dient. Haal de mens weg en de mechanische controles blijven slagen terwijl de software stilletjes het verkeerde doet. Ons volledige proces, waar de twee lagen samenkomen, staat beschreven in hoe we scopen, bouwen en reviewen, en de tooling-kant in detail in hoe we elke build beveiligen (in het Engels).
Review is ook waar de verantwoordelijkheid woont
Een review levert nog iets op dat geen tool kan: een verantwoordelijke mens die jouw software begrijpt.
Wanneer een engineer elke regel leest voordat die mergt, kan iemand uitleggen hoe het systeem werkt, waarom het zo is gebouwd en wat er breekt als je het verandert. Die persoon kan de codebase netjes overdragen, een beveiligingsvragenlijst eerlijk invullen en de volgende bug oplossen zonder een blinde onderhandeling met het model. Een gevibecodeerde app heeft die persoon niet, en daarom is die zo duur in bezit: het CISQ becijferde de jaarlijkse kosten van slechte softwarekwaliteit in de Verenigde Staten op 2,41 biljoen dollar, grotendeels besteed aan het repareren en uitbreiden van code die niemand volledig begrijpt (CISQ, 2022).
De verantwoordelijkheid verklaart ook waarom review en eigendom samen reizen. Een leverancier die elke regel leest en je vervolgens de volledige code-eigendom (in het Engels) overdraagt, overhandigt iets wat hij begrijpt en waar hij achter staat. Een leverancier die ongelezen output uitlevert en je afhankelijk van hem houdt, doet het tegenovergestelde, wat het contract ook zegt.
Wat je een leverancier over review moet vragen
Elke AI-ontwikkelshop noemt zijn code gereviewd. Weinig kunnen de review beschrijven op een manier die je kunt controleren. Drie vragen scheiden de twee.
Vraag wie de code leest: je wilt een benoemde rol, een senior engineer, niet "het team" of "ons proces". Vraag wanneer hij hem leest: voor elke merge, niet "ooit" of "als er iets vreemd lijkt". Vraag wat er gebeurt als een controle faalt: een echte pipeline blokkeert de release; een decoratieve pipeline logt een waarschuwing en levert toch uit. Een leverancier die alle drie in heldere zinnen beantwoordt, heeft een reviewstap. Een leverancier die in bijvoeglijke naamwoorden antwoordt, heeft die waarschijnlijk niet, en dat ene gat weegt zwaarder dan bijna al het overige in zijn pitch.
Veelgestelde vragen
Wie zou AI-gegenereerde code moeten reviewen?
Een senior engineer die de code kan lezen, het bedrijf dat ze dient begrijpt en de architectuurbeslissingen draagt. Niet het model dat de code schreef, niet een junior die ongelezen tekent, en niet een scanner alleen. Een review is een taak van oordeel, dus hij vraagt om gekwalificeerd menselijk oordeel.
Kunnen geautomatiseerde tools menselijke code-review vervangen?
Nee. Dependency-scanners en linters vangen snel mechanische problemen met bekende patronen, en ze horen op elke build. Ze kunnen niet zien dat de code het verkeerde probleem correct oploste of dat een rechtengrens verkeerd zit. Dat vraagt een mens die begrijpt waar de software voor dient.
Wat vangt een menselijke reviewer dat AI mist?
Beveiligingslekken die het model uit trainingsdata kopieerde, imports van pakketten die niet bestaan, logica die fout is zonder te crashen, en gedupliceerde code die toekomstige wijzigingen gevaarlijk maakt. Alle vier gaan recht naar productie wanneer niemand de output leest voor de release.
Vertraagt het reviewen van AI-gegenereerde code het project?
Nauwelijks, en het bespaart later veel meer. De AI comprimeert nog steeds het schrijven, dus een gereviewde build wordt in weken opgeleverd, niet in maanden. Review overslaan lijkt alleen sneller tot het eerste incident, wanneer de ongelezen kortere weg een noodgeval wordt in plaats van een opmerking.
Is gereviewde AI-code net zo veilig als door mensen geschreven code?
Ja, om dezelfde reden dat door mensen geschreven code veilig is: iemand die gekwalificeerd is, heeft die gelezen, getest en beveiligd. Veiligheid komt van de review en de tests, niet van of een mens of een model het eerste concept produceerde. "Gereviewd" is het woord dat telt, niet "AI" of "mens".
Hoe reviewt Globaprom AI-gegenereerde code?
Een senior engineer leest elke regel voordat die mergt, dependency-scanning draait op elke build, en een testsuite bewijst het gedrag voor de oplevering. Onze diensten voor AI-ondersteunde ontwikkeling zetten dat proces op papier, met benoemde reviewers die je rechtstreeks kunt bevragen.
De review is wat je koopt
De snelheid komt van de AI. Het vertrouwen komt van de review. Koop alleen het eerste en je hebt een demo die nog niet is gefaald; koop beide en je hebt software die een bedrijf draagt. Vertel ons wat je moet laten bouwen en we tonen je precies wie je code leest en wanneer, samen met een vaste scope, een vaste prijs en een opleverdatum.