Het artikel waarschuwt voor de trend van 'vibe-coding', waarbij ontwikkelaars blind vertrouwen op AI voor het schrijven en lezen van code. De auteur betoogt dat AI geen echte 'wijsheid' bezit: het kan patronen herkennen, maar mist de intuïtie van ervaren software engineers die is opgebouwd door jarenlange ervaring en het oplossen van complexe productieproblemen.
De kernpunten zijn:
- Onderhoudbaarheid: Slechte architectuur wordt vaak pas na lange tijd zichtbaar, iets wat AI niet kan voorzien omdat er geen onmiddellijk meetbaar beloningssignaal is voor onderhoudbaarheid.
- Het risico op kwaliteitsverlies: Omdat AI vaak slecht is in het écht vereenvoudigen van code en vaak patronen uit kwalitatief matige bronnen overneemt, kan dit leiden tot onbeheersbare projecten.
- Verlies van meesterschap: Wanneer ontwikkelaars stoppen met het maken van actieve keuzes en het leren van hun eigen fouten, bereiken zij nooit het niveau van meesterschap.
- AI als hulpmiddel: De auteur ziet LLM's als uitstekende instrumenten voor routinematig werk, maar niet als vervanging voor menselijk inzicht.
De auteur voorspelt dat 'NO-AI'-beleid in de toekomst juist een concurrentievoordeel zal worden voor bedrijven die kwaliteit en duurzame software garanderen.
AI heeft geen wijsheid, en jij zult dat ook niet hebben
In de afgelopen maand alleen heb ik deze zinnen gehoord:
- "Ik heb sinds 2025 geen code meer geschreven."
- "Code reviews zijn dood."
- "Mensen lezen geen code meer."
Natuurlijk is de sector in beweging, maar de mensen en organisaties die in de val lopen door geen code meer te lezen en te schrijven, doen dit op eigen risico.
Het feit is dat 'vibe-coded' projecten na verloop van tijd uitmonden in een onbeheersbare puinhoop. De reden is simpel, maar moeilijk op te lossen: voor de onderhoudbaarheid van code en een goede architectuur bestaan geen goede meetmethoden die we direct kunnen toepassen, omdat het maanden, zo niet jaren duurt voordat de effecten van een slechte architectuur of ononderhoudbare code merkbaar worden.
Wat is slechte code?
We kunnen slechte code zeker definiëren: code die moeilijk te lezen is, moeilijk te begrijpen en moeilijk te evolueren voor wat de toekomst ons ook brengt.
Het is het soort code waarbij:
- Het wijzigen van één ding het programma op niet-deterministische manieren breekt, of de logica op een andere plek breekt die ver verwijderd is van je wijziging (vergelijkbaar met het "butterfly-effect").
- Het toevoegen van een functie een enorme onderneming wordt, omdat code op meerdere plaatsen moet worden gewijzigd en er nog steeds zaken worden vergeten, wat leidt tot inconsistenties.
- De invarianten van het ontwerp onduidelijk zijn, waarbij de oorspronkelijke auteurs niet meer aanwezig zijn om schendingen te voorkomen en coherentie te waarborgen.
- Code moeilijk te testen is, omdat er mocks nodig zijn en implementatiedetails worden blootgesteld, wat leidt tot fragiele tests die uiteindelijk zinvolle refactoring in de weg staan.
Toch weten we dat het tijd kost om slechte code op te merken. Maanden, jaren. Natuurlijk hebben ervaren software engineers een neus voor 'code smells' en kunnen ze actie ondernemen lang voordat de slechte effecten waarneembaar zijn.
De intuïtie van de expert
Bekwame ontwikkelaars, de experts, vertrouwen op hun intuïtie die is opgebouwd met zweet en tranen, door lange uren te werken aan het debuggen en oplossen van productieproblemen, waarbij ze zweren nooit meer zo dwaas te zijn om fouten uit het verleden te herhalen.
Dit is een soort intuïtie die niet echt kan worden omgezet in een lijst met rigide regels, omdat alles afhankelijk is van de context. Experts zijn incompatibel met dezelfde regels en recepten die beginners productiever maken. Experts volgen de regels niet; zij maken de regels.
En hier ontstaat een probleem.
Waarom AI geen wijsheid bezit
Ten eerste is AI niet getraind op wat het betekent dat code onderhoudbaar is. Voor reinforcement learning is bijvoorbeeld een beloningssignaal nodig dat onmiddellijk gemeten kan worden, niet pas over maanden of jaren.
De AI leert regels uit handleidingen die bedoeld zijn voor beginners. De AI herkent patronen uit code die in de praktijk wordt gebruikt, en laten we eerlijk zijn: het meeste code in de praktijk is behoorlijk slecht. Er is geen fitness function die je kunt definiëren voor onderhoudbare code—althans, niet een die we kunnen onderscheiden—anders zou deze al in onze linters zijn ingebouwd.
Heb je gemerkt hoe verschrikkelijk AI is in het "vereenvoudigen" van code? Zelfs de SOTA-modellen. Het kan functies niet eens correct definiëren en kiest ervoor om functies op te splitsen in kleinere functies die eigenlijk niet herbruikbaar zijn. Het extraheren van een kleinere functie uit een grotere functie is een zeer slechte keuze als je, om de grotere functie te begrijpen, ook de implementatie van de geëxtraheerde kleinere functie moet lezen. Het definiëren van herbruikbare en verduidelijkende functies is een kunstvorm die meesterschap vereist. De meeste ontwikkelaars, die volgens het Dreyfus-model nog "gevorderde beginners" zijn, zijn niet in staat om goede, verduidelijkende, herbruikbare functies te definiëren, en dat is de AI momenteel ook niet.
Het risico op het verlies van meesterschap
Dit zou niet zo erg zijn als mensen nog steeds de controle zouden hebben en zouden leren van deze fouten. Maar we zien een trend waarbij mensen op AI vertrouwen om code te schrijven, en zelfs om het te lezen.
Deze mensen zullen nooit meesterschap bereiken, omdat ze geen keuzes meer maken, geen verantwoordelijkheid meer nemen voor fouten in de codering en niet meer leren van die fouten. Het is nu de AI die de fouten maakt; de AI leert niet van die fouten, en de mensen die op AI vertrouwen voor het coderen doen dat ook niet.
AI als instrument, niet als vervanging
Begrijp me niet verkeerd, ik denk dat LLM's een geweldig hulpmiddel zijn. Ik ben geen Luddite; ik heb AI geïntegreerd in mijn dagelijkse werk, terwijl ik mijn collega's leer wat ik heb ontdekt. Ik gebruik LLM's graag voor al het saaie, geestdodend werk waar we mee te maken hebben. Ook geniet ik van de efficiëntievoordelen die ik zie.
Maar uiteindelijk is het slechts een instrument, en zoals alle andere revoluties zal ook het licht ervan vervagen. Naar mijn mening gebeurt dit nu al; het tech-nieuws is momenteel eerlijk gezegd behoorlijk saai.
Mensen zijn over het algemeen slecht in het doen van voorspellingen. Ik geloof dat de toekomst ons allemaal zal verrassen. Maar ik ga mijn eigen voorspelling doen:
In de toekomst zullen we meer en meer bedrijven zien die trots pronken met hun "NO-AI"-beleid als een concurrentievoordeel. En ze zullen gelijk hebben.
Men zegt: "Maar geautomatiseerde assemblagelijnen zijn altijd efficiënter". Behalve dat de software-industrie speciaal is, omdat we automatisering altijd op schaal hebben gedaan. Alles wat we doen is automatisering; LLM's zijn niet het enige middel hiervoor en, afhankelijk van de context, kunnen ze zelfs een afleiding zijn.
"Coderen" is in geen enkele zin opgelost. Zeker, je kunt een LLM instrueren om een C/C++ compiler voor je te bouwen, of je kunt gewoon GCC of LLVM klonen, en dan krijg je een betere C/C++ compiler, en dat nog gratis. En misschien zijn er betere manieren om onze tijd en middelen te besteden dan het opnieuw uitvinden van dezelfde CRUD-apps (menselijke behoeften en verlangens zijn oneindig, er is geen tekort aan nieuwe doelen om aan te werken).
Als mensen en bedrijven niet verantwoordelijk beginnen te zijn over het gebruik ervan, zullen er consequenties zijn.
AI heeft geen wijsheid, en jij zult dat ook niet hebben
In de afgelopen maand alleen heb ik deze zinnen gehoord:
- "Ik heb sinds 2025 geen code meer geschreven."
- "Code reviews zijn dood."
- "Mensen lezen geen code meer."
Natuurlijk is de sector in beweging, maar de mensen en organisaties die in de val lopen door geen code meer te lezen en te schrijven, doen dit op eigen risico.
Het feit is dat 'vibe-coded' projecten na verloop van tijd uitmonden in een onbeheersbare puinhoop. De reden is simpel, maar moeilijk op te lossen: voor de onderhoudbaarheid van code en een goede architectuur bestaan geen goede meetmethoden die we direct kunnen toepassen, omdat het maanden, zo niet jaren duurt voordat de effecten van een slechte architectuur of ononderhoudbare code merkbaar worden.
Wat is slechte code?
We kunnen slechte code zeker definiëren: code die moeilijk te lezen is, moeilijk te begrijpen en moeilijk te evolueren voor wat de toekomst ons ook brengt.
Het is het soort code waarbij:
- Het wijzigen van één ding het programma op niet-deterministische manieren breekt, of de logica op een andere plek breekt die ver verwijderd is van je wijziging (vergelijkbaar met het "butterfly-effect").
- Het toevoegen van een functie een enorme onderneming wordt, omdat code op meerdere plaatsen moet worden gewijzigd en er nog steeds zaken worden vergeten, wat leidt tot inconsistenties.
- De invarianten van het ontwerp onduidelijk zijn, waarbij de oorspronkelijke auteurs niet meer aanwezig zijn om schendingen te voorkomen en coherentie te waarborgen.
- Code moeilijk te testen is, omdat er mocks nodig zijn en implementatiedetails worden blootgesteld, wat leidt tot fragiele tests die uiteindelijk zinvolle refactoring in de weg staan.
Toch weten we dat het tijd kost om slechte code op te merken. Maanden, jaren. Natuurlijk hebben ervaren software engineers een neus voor 'code smells' en kunnen ze actie ondernemen lang voordat de slechte effecten waarneembaar zijn.
De intuïtie van de expert
Bekwame ontwikkelaars, de experts, vertrouwen op hun intuïtie die is opgebouwd met zweet en tranen, door lange uren te werken aan het debuggen en oplossen van productieproblemen, waarbij ze zweren nooit meer zo dwaas te zijn om fouten uit het verleden te herhalen.
Dit is een soort intuïtie die niet echt kan worden omgezet in een lijst met rigide regels, omdat alles afhankelijk is van de context. Experts zijn incompatibel met dezelfde regels en recepten die beginners productiever maken. Experts volgen de regels niet; zij maken de regels.
En hier ontstaat een probleem.
Waarom AI geen wijsheid bezit
Ten eerste is AI niet getraind op wat het betekent dat code onderhoudbaar is. Voor reinforcement learning is bijvoorbeeld een beloningssignaal nodig dat onmiddellijk gemeten kan worden, niet pas over maanden of jaren.
De AI leert regels uit handleidingen die bedoeld zijn voor beginners. De AI herkent patronen uit code die in de praktijk wordt gebruikt, en laten we eerlijk zijn: het meeste code in de praktijk is behoorlijk slecht. Er is geen fitness function die je kunt definiëren voor onderhoudbare code—althans, niet een die we kunnen onderscheiden—anders zou deze al in onze linters zijn ingebouwd.
Heb je gemerkt hoe verschrikkelijk AI is in het "vereenvoudigen" van code? Zelfs de SOTA-modellen. Het kan functies niet eens correct definiëren en kiest ervoor om functies op te splitsen in kleinere functies die eigenlijk niet herbruikbaar zijn. Het extraheren van een kleinere functie uit een grotere functie is een zeer slechte keuze als je, om de grotere functie te begrijpen, ook de implementatie van de geëxtraheerde kleinere functie moet lezen. Het definiëren van herbruikbare en verduidelijkende functies is een kunstvorm die meesterschap vereist. De meeste ontwikkelaars, die volgens het Dreyfus-model nog "gevorderde beginners" zijn, zijn niet in staat om goede, verduidelijkende, herbruikbare functies te definiëren, en dat is de AI momenteel ook niet.
Het risico op het verlies van meesterschap
Dit zou niet zo erg zijn als mensen nog steeds de controle zouden hebben en zouden leren van deze fouten. Maar we zien een trend waarbij mensen op AI vertrouwen om code te schrijven, en zelfs om het te lezen.
Deze mensen zullen nooit meesterschap bereiken, omdat ze geen keuzes meer maken, geen verantwoordelijkheid meer nemen voor fouten in de codering en niet meer leren van die fouten. Het is nu de AI die de fouten maakt; de AI leert niet van die fouten, en de mensen die op AI vertrouwen voor het coderen doen dat ook niet.
AI als instrument, niet als vervanging
Begrijp me niet verkeerd, ik denk dat LLM's een geweldig hulpmiddel zijn. Ik ben geen Luddite; ik heb AI geïntegreerd in mijn dagelijkse werk, terwijl ik mijn collega's leer wat ik heb ontdekt. Ik gebruik LLM's graag voor al het saaie, geestdodend werk waar we mee te maken hebben. Ook geniet ik van de efficiëntievoordelen die ik zie.
Maar uiteindelijk is het slechts een instrument, en zoals alle andere revoluties zal ook het licht ervan vervagen. Naar mijn mening gebeurt dit nu al; het tech-nieuws is momenteel eerlijk gezegd behoorlijk saai.
Mensen zijn over het algemeen slecht in het doen van voorspellingen. Ik geloof dat de toekomst ons allemaal zal verrassen. Maar ik ga mijn eigen voorspelling doen:
In de toekomst zullen we meer en meer bedrijven zien die trots pronken met hun "NO-AI"-beleid als een concurrentievoordeel. En ze zullen gelijk hebben.
Men zegt: "Maar geautomatiseerde assemblagelijnen zijn altijd efficiënter". Behalve dat de software-industrie speciaal is, omdat we automatisering altijd op schaal hebben gedaan. Alles wat we doen is automatisering; LLM's zijn niet het enige middel hiervoor en, afhankelijk van de context, kunnen ze zelfs een afleiding zijn.
"Coderen" is in geen enkele zin opgelost. Zeker, je kunt een LLM instrueren om een C/C++ compiler voor je te bouwen, of je kunt gewoon GCC of LLVM klonen, en dan krijg je een betere C/C++ compiler, en dat nog gratis. En misschien zijn er betere manieren om onze tijd en middelen te besteden dan het opnieuw uitvinden van dezelfde CRUD-apps (menselijke behoeften en verlangens zijn oneindig, er is geen tekort aan nieuwe doelen om aan te werken).
Als mensen en bedrijven niet verantwoordelijk beginnen te zijn over het gebruik ervan, zullen er consequenties zijn.
Groetjes,