Menselijke review vs volledig AI-gegenereerde code: waarom het verschil het product is
Publicatiedatum
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. Niet-gereviewde AI-code moet worden behandeld als onbewezen code: ze kan werken, maar haar correctheid, veiligheid en onderhoudbaarheid zijn nog niet aangetoond. De review is het verschil.
Steeds meer ontwikkelteams gebruiken AI om code te schrijven, maar de mate van gebruik verschilt sterk per organisatie en team, 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 de gevolgen van het gat daartussen niet. 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. Google meldde tijdens zijn Q3-earningscall van 2024 dat meer dan een kwart van al zijn nieuwe code met AI wordt gegenereerd en vervolgens door engineers wordt gereviewd en geaccepteerd; dit is een bedrijfsclaim uit 2024 over Google specifiek, geen universeel marktgegeven over de sector. De organisaties die het best zijn in AI-code zijn doorgaans 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 de plek 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 zijn onder meer getraind op grote hoeveelheden code, en gegenereerde output kan daardoor patronen en fouten bevatten; de precieze trainingsdata en herkomst verschillen per model. 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; dat resultaat betreft Veracodes testopzet en is geen universeel percentage voor alle AI-code. Een reviewer onderschept de hardgecodeerde 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, gebaseerd op 576.000 codevoorbeelden van 16 LLM's, mat dat het gemiddelde aandeel gehallucineerde pakketten minstens 5,2% bedroeg bij commerciële modellen, oplopend tot ongeveer 21,7% bij open source-modellen. Onderzoekers hebben gewaarschuwd dat niet-bestaande pakketnamen kunnen worden geregistreerd door aanvallers, waardoor een ontwikkelaar bij een latere reparatie kwaadaardige code zou kunnen installeren; het risico hangt af van ecosysteem, pakketbeheer en het concrete incident. 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 blijven wekenlang onopgemerkt draaien en komen pas aan het licht wanneer een klant merkt dat het totaal niet klopt. Een reviewer die het bedrijf begrijpt, beoordeelt de bedoeling, niet alleen 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. Scanners en linters vervangen menselijke beoordeling echter niet voor alle risico's: ze zijn vooral geschikt voor bekende patronen, terwijl context, bedrijfslogica en architectuur vaak aanvullende menselijke beoordeling vereisen, en ze als volledige 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. Het NCSC beschrijft Software Supply Chain Security als een manier om beveiligingsrisico's bij de ontwikkeling, distributie en implementatie van software tot een minimum te beperken; ook externe libraries en modules moeten worden geïnventariseerd en aan een vergelijkbaar proces onderworpen. Volgens het NCSC is inzicht in alle gebruikte softwarecomponenten, inclusief subcomponenten, essentieel, en is een Software Bill of Materials relevant voor het invullen van een software-security-controlframework. 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, kan 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.
Review is ook waar de verantwoordelijkheid ligt
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. Voor AI-systemen met een hoog risico vereist de AI-verordening onder meer risicomanagement, monitoring en de mogelijkheid tot menselijk toezicht; de precieze verplichting hangt af van de rol en de risicocategorie van het systeem, en de verordening wordt sinds 2 februari 2025 gefaseerd toegepast. Een gevibecodeerde app heeft die persoon niet, en daarom kan die duur zijn in bezit: een CISQ-rapport raamde de kosten van slechte softwarekwaliteit in de Verenigde Staten voor 2020 op ongeveer 2,08 biljoen dollar, een schatting op basis van publiek beschikbare bronnen; dat cijfer bewijst niet dat de kosten grotendeels voortkomen uit code die niemand volledig begrijpt, maar illustreert wel de macro-economische schaal van het probleem.
De verantwoordelijkheid verklaart ook waarom review en eigendom hand in hand gaan. Een leverancier die elke regel leest en je vervolgens de volledige code-eigendomoverdraagt, 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 oordeelswerk, 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 (wat een supply-chainrisico kan vormen wanneer iemand ze zonder verificatie installeert), logica die fout is zonder te crashen, en gedupliceerde code die toekomstige wijzigingen gevaarlijk maakt. Zonder controle kunnen dergelijke fouten productie bereiken.
Vertraagt het reviewen van AI-gegenereerde code het project?
Meestal maar beperkt, en het bespaart later vaak veel meer. AI kan bepaalde ontwikkelactiviteiten versnellen, maar de totale doorlooptijd hangt af van scope, review, testen, integratie en wijzigingen; zonder projectdata kan geen algemene vergelijking tussen weken en maanden worden vastgesteld. Review overslaan lijkt alleen sneller tot het eerste incident, wanneer de ongelezen sluiproute een noodgeval wordt in plaats van een opmerking.
Is gereviewde AI-code net zo veilig als door mensen geschreven code?
Een menselijke review en passende tests kunnen risico's verminderen, maar maken AI-gegenereerde code niet automatisch precies even veilig als door mensen geschreven code; de uitkomst hangt ook af van de implementatie, het dreigingsmodel, de testdekking en de controles. Wat hier het meest telt, is of iemand die gekwalificeerd is de code heeft gelezen, getest en beveiligd, niet of een mens of een model het eerste concept produceerde.
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. Bij het gebruik van AI moet een organisatie volgens de Autoriteit Persoonsgegevens eerst vaststellen in welke risicocategorie het systeem valt; voor bepaalde hoogrisicosystemen gelden onder meer eisen rond logging, datamanagement en menselijk toezicht. Onze diensten voor AI-ondersteunde ontwikkeling zetten ons eigen reviewproces 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.