Het gaat tegenwoordig zo snel dat het bijna bedwelmend werkt. Je voert een prompt in, je ziet de regels code over je scherm vliegen, en binnen tien minuten heb je een feature die vroeger drie dagen kostte. Het voelt als vliegen.
Maar wie wel eens in de buurt van een vulkaan is geweest, weet dit: vloeibare lava stroomt razendsnel en ziet er indrukwekkend uit, maar zodra het afkoelt, verandert het in keihard gesteente.
In de software-engineering noemen we dit de Lavalaag. En we storten deze laag nu met recordtempo over onze codebases. De laag heeft trouwens een tweeling die nooit uithardt: code churn, de lava die je nog kunt meten.
De illusie van eigenaarschap
Wanneer je zelf een algoritme schrijft, bouw je een mentaal model op. Je weet waarom die if-statement daar staat, waarom je voor die specifieke array-methode koos en welke edge cases je (bewust of onbewust) hebt meegenomen. Dat is geen abstracte kennis; dat is intuïtie die je nodig hebt op het moment dat er om drie uur 's nachts iets knapt.
Bij AI-gegenereerde code ontbreekt dat model. Je bent geen architect, maar een curator. Je kijkt naar de code, ziet dat het "werkt" (de tests zijn immers groen, toch?), en je klikt op merge.
Op dat moment ontstaat de eerste korst van de lavalaag. Je hebt code toegevoegd die technisch functioneel is, maar waarvan niemand in het team de "ziel" begrijpt.
De refactoring-valkuil
Het echte probleem ontstaat pas na zes maanden. De business-eisen veranderen (zoals altijd) en die complexe module die de AI heeft uitgespuugd moet op de schop.
In een gezonde codebase is dat een kwestie van chirurgisch ingrijpen. Maar bij een lavalaag durft niemand er aan te komen. Omdat de oorspronkelijke logica niet uit een menselijk denkproces voortkwam, maar uit een statistische waarschijnlijkheid, zijn de verbanden vaak fragiel en onlogisch voor ons brein.
Het resultaat?
- Angst-gedreven ontwikkeling: "Raak die module maar niet aan, want we weten niet wat er dan omvalt."
- Hacks-op-hacks: In plaats van de code te verbeteren, bouw je er omheen. De lavalaag wordt dikker en dikker.
- Snelheidsverlies: De initiële winst die je boekte met de AI-agent, betaal je nu met rente terug omdat elke wijziging drie keer zo lang duurt.
Bovendien werkt de agent zelf ook steeds slechter in zo'n bevroren codebase: je agent lijdt onder je technische schuld.
Hoe herken je de Lavalaag?
Je kunt de verstening van je project vrij simpel meten. Stel jezelf en je team de volgende vragen:
| Symptoom | Oorzaak | Gevaarniveau |
|---|---|---|
| "De AI snapt het beter dan ik" | Je hebt de regie over de logica verloren. | 🔴 Kritiek |
| "Ik durf deze unit test niet aan te passen" | De test is een echoput van de AI-fout. | 🟠 Hoog |
| "Laten we deze file gewoon weggooien en opnieuw prompten" | Je bent aan het gokken, niet aan het bouwen. | 🔴 Kritiek |
Sloop de drilboor eruit
Betekent dit dat we terug moeten naar de typmachine? Natuurlijk niet. Maar we moeten stoppen met het storten van vloeibare lava.
- Beperk de scope: Laat de AI kleine, overzichtelijke functies schrijven. Geen complete classes of complexe orchestratielagen. Laat hem ook eerst zoeken voor hij schrijft, anders hou je twintig bijna-identieke hulpjes voor één taak over.
- De 15-minuten regel: Als je de code die de AI genereert niet binnen 15 minuten volledig aan een junior developer kunt uitleggen, dan mag het niet de repo in.
- Review als een scepticus: Behandel AI-code niet als een suggestie van een briljante collega, maar als een pull request van een enthousiaste stagiair die net iets te veel koffie op heeft.
- Plan de drilboor in: de laag die al hard is geworden krijg je alleen weg met een ingeplande opruimronde, vast in de agenda zoals backups, niet bewaard voor een rustige week.
Snelheid is prachtig, maar onderhoudbaarheid is wat je bedrijf overeind houdt. Een codebase die volledig uit AI-lava bestaat, is op korte termijn een sprintkampioen, maar op de lange termijn een standbeeld: mooi om naar te kijken, maar er zit geen beweging meer in.
Houd de regie. Blijf de eigenaar. En laat de lava niet uitharden.