De paradox van 'vibe-codering' en de risico's van geautomatiseerde aannames

AI inzetten is tegenwoordig verrassend laagdrempelig. Met een enkele prompt kun je al iets bouwen dat werkt. Juist daarom raakt deze ontwikkeling van software engineering misschien wel moeilijker dan een ander vakgebied.

De belofte — of bedreiging — dat AI-ontwikkelaars gaat vervangen, wordt steeds serieuzer genomen. En eerlijk is eerlijk: we zien inmiddels genoeg voorbeelden van mensen zonder technische achtergrond die bruikbare software opleveren.Maar dat roept een fundamentele vraag op: hoe duurzaam is deze manier van werken? Bewegen we richting een wereld waarin technische kennis overbodig wordt? En belangrijker nog — hoe zeker kunnen we zijn van de veiligheid en juistheid van systemen die we niet volledig begrijpen?

Het korte antwoord: zo ver zijn we nog lang niet.‍

‍

Het raamwerkprobleem: AI kiest voor het bekende

Een eerste beperking zit in hoe AI keuzes maakt. Modellen zijn getraind op bestaande codebases en openbare voorbeelden. Zonder extra context kiezen ze daardoor bijna altijd voor de meest voorkomende oplossingen.

Vraag een AI om een webapplicatie te bouwen en de kans is groot dat je een React-oplossing krijgt.Dat is op zichzelf geen probleem — React is volwassen en krachtig. Maar het legt wel iets bloot: AI optimaliseert voor waarschijnlijkheid, niet voor kwaliteit of innovatie.

Nieuwe ideeën krijgen daardoor een achterstand. Een alternatief framework moet niet alleen technisch beter zijn, maar ook breed geadopteerd worden én zichtbaar zijn in trainingsdata, voordat AI het als standaard gaat beschouwen. Daarmee versterkt AI vooral wat er al is, in plaats van dat het vernieuwing stimuleert.

Met andere woorden: we automatiseren niet alleen code, maar ook de status quo.‍

‍

Het audit-gat: wat als we de code niet meer zien?

Er wordt gespeculeerd dat AI in de nabije toekomst directe machinecode kan genereren. Of dat realistisch is op korte termijn, is discutabel. Maar zelfs als het kan, is de vraag of we het moeten willen.

Vandaag hebben we nog een cruciale tussenlaag: leesbare broncode. Die stelt ons in staat om te controleren of een systeem doet wat we bedoelen. Softwareontwikkeling draait immers niet alleen om bouwen, maar ook om te begrijpen en te verifiëren.

Als die laag verdwijnt, verdwijnt ook onze belangrijkste vorm van controle.

Wat gebeurt er als er iets misgaat? Hoe debug je een systeem waarvan je de logica niet kunt volgen? Dan resteert alleen indirect onderzoek — reverse engineering of opnieuw dezelfde AI raadplegen. In beide gevallen verlies je grip.

We zouden daarmee niet alleen het vermogen om te ontwikkelen uit handen geven, maar ook het vermogen om te beoordelen.
‍

Prompting is ook programmeren — maar zonder garanties

Hoewel het anders aanvoelt, roept het in wezen gewoon op programmeren. We geven instructies aan een systeem en verwachten een bepaald resultaat. Het verschil zit in de aard van de 'compiler': een LLM is niet deterministisch en vult zelf ontbrekende informatie in.

Dat maakt het krachtig, maar ook onvoorspelbaar.

Dit brengt bekende problemen terug in een nieuwe vorm. Waar traditionele systemen kwetsbaar waren voor bijvoorbeeld SQL-injecties, zien we vergelijkbare risico's ontstaan in promptgebaseerde workflows. De grens tussen invoer en instructie is niet altijd scherp, zeker niet wanneer er externe of kwaadaardige gegevens in het spel zijn.

Daarnaast wijst onderzoek erop dat gedragsmodellen zich kunnen ontwikkelen op basis van indirecte of ogenschijnlijk irrelevante trainingsgegevens. Dat betekent dat beslissingen van een model beïnvloed kunnen worden door patronen die wij niet expliciet hebben meegegeven — en soms niet eens kunnen herleiden.

In een context waarin AI-code genereert, zijn dat geen academische nuances, maar potentiële risico's.
‍

Het automatiseren van aannamen

Wat er uiteindelijk gebeurt, is misschien nog fundamenteler: we automatiseren aannamen.

Elke keer dat een model ontbrekende informatie invult, maakt de keuzes namens ons. Over architectuur. Te veel beveiliging. Overedge schoenen. De grote intentie.

Een simpele test maakt dit zichtbaar. Geef een AI de opdracht: „Maak Tetris.” Je krijgt vrijwel direct een werkende implementatie. Maar wat ontbreekt, zijn de vragen die een ontwikkelaar normaal gesproken zou stellen:

• Op welk platform moet dit draaien?
• Hoe slaan we de score op?
• Welke invoermethoden ondersteunen wij?

Die vragen blijven uit, omdat het model niet ontworpen is om te wachten en te verkennen, maar om te leveren.

Voor een klein project is dat acceptabel. Maar software wordt zelden gebouwd voor triviale toepassingen. In serieuze systemen zijn juist die vragen cruciaal.

We zouden een ontwikkelaar die nooit doorvraagt niet vertrouwen met kritieke systemen. Waarom zouden we dat vertrouwen dan wel blindelings aan AI geven?
‍

Tot slot: vakmanschap verdwijnt niet, het verschuift

AI verandert ons vak — dat is onmiskenbaar. Maar het maakt vakmanschap niet overbodig. Integendeel: het verschuift waar de verantwoordelijkheid ligt.

Niet alleen in het schrijven van code, maar ook in het begrijpen van systemen. Bij het stellen van de juiste vragen. In het expliciet maken van aannamen.

Want uiteindelijk blijft één principe overeind: software is zo betrouwbaar als de aannamen waarop het gebouwd is.

En precies daar ligt de uitdaging van 'vibe coding'.