Waarom je nooit code moet shippen die je zelf niet snapt
3m leestijd

Waarom je nooit code moet shippen die je zelf niet snapt

Als je code niet aan een collega kunt uitleggen zonder te zeggen 'dat heeft de AI gedaan', dan hoort die niet in je repo. Over black boxes, WC-eend-tests en waarom hoop geen strategie is.

De verleiding is groot. Je tikt een prompt in en binnen een paar seconden spuugt een AI-agent een complexe class of een algoritme uit waar je normaal een middag op had gezeten.

Maar daar zit direct het probleem. Als je een agent gebruikt voor code die je, met genoeg tijd en de docs erbij, niet ook zelf had kunnen schrijven, dan bouw je op drijfzand. Je ruilt fundamenteel begrip in voor snelheid. En in onze wereld is dat een schuld die je altijd met een veel te hoge rente terugbetaalt zodra er een bug opduikt. Die rente is inmiddels gewoon meetbaar: code churn, regels die binnen twee weken alweer worden herschreven.

De black box in je stack ​

Zodra een agent code voor je schrijft die buiten je eigen bereik ligt, creëer je een black box die langzaam versteent in je eigen applicatie. Je mist de inzichten over waarom bepaalde keuzes zijn gemaakt. Waarom deze datastructuur? Wat doet dit met je geheugen als je straks moet schalen?

Als je de logica niet zelf kunt reproduceren, kun je die ook niet fatsoenlijk reviewen. Laat staan onderhouden. Je wordt een passagier in je eigen codebase. Zodra de AI een subtiele fout maakt, heb je de bagage niet om te zien waar het misgaat. Je bent dan niet meer aan het programmeren. Je bent aan het hopen dat de AI het goed had. En hoop is geen strategie.

Het WC-eendscenario bij testing ​

Het grootste gevaar zit in je tests. Er is een harde regel die veel developers in hun enthousiasme vergeten: laat nooit de agent die de code schreef, ook de tests schrijven. Doe je dit wel, dan krijg je het klassieke "Wij van WC-eend"-verhaal. Wil je toch AI-tests, meet dan met mutation testing wat ze waard zijn.

Een LLM werkt op basis van waarschijnlijkheid en patronen. Als de AI een foute aanname doet in de code, bijvoorbeeld door een edge case te missen, dan is de kans bijna 100% dat diezelfde fout ook in de unit tests belandt. Je tests kleuren prachtig groen, niet omdat de code klopt, maar omdat de test de fout in de code simpelweg bevestigt. Je bent dan je eigen blindheid aan het automatiseren.

Waar het in de praktijk misgaat ​

Een paar voorbeelden waar die AI-tunnelvisie je de kop kost:

De off-by-one error: De agent schrijft een filter maar vergeet het laatste element. De test die de AI genereert, verwacht ook die incomplete lijst. Alles lijkt te werken, totdat je data mist in productie.

Security: Een agent genereert een SQL-query die openstaat voor injectie. De test checkt alleen de happy path en ziet geen probleem, omdat de AI "denkt" dat het zo veilig genoeg is.

Business logic: De AI verzint een kortingsregel die technisch prima draait, maar die volgens de business rules helemaal niet mag. Je test bevestigt de berekening, maar je businessmodel klopt niet meer.

Pak de regie terug ​

Een coding agent is een prima assistent, maar een waardeloze architect. Gebruik hem voor je boilerplate of als een soort rubber duck, maar houd zelf de pen vast bij de kernlogica.

Als je de code niet aan een collega kunt uitleggen zonder te zeggen "dat heeft de AI gedaan", dan hoort die niet in je repo thuis. Die zin houdt inmiddels ook voor de rechter geen stand. Blijf de baas over je eigen stack.

(2 van 40)
1Je hebt geen AI-probleem. Je hebt een procesprobleem.2Waarom je nooit code moet shippen die je zelf niet snapt3Stop met copy-paste engineering4De lavalaag: waarom AI-code je codebase langzaam versteent5Het briljante papegaaiprobleem: wat AI eigenlijk doet als het 'denkt'6De prompt is geen spec7De bureaucratie van bots: waarom we de controleur controleren8De dag dat Claude mijn productiedatabase verwijderde9De wapenwedloop om je vertrouwen: Mythos, Cyber en de security-hype10Laat je agents stoppen met Markdown schrijven11Je agent lijdt onder je technische schuld12Je vindt de bug niet als je de code niet schreef13Een op vier: de beveiligingsschuld die niemand telt14Je 10x-developer zit vast in een 0,1x-pipeline15De benchmarks zeiden 'frontier'. Ontwikkelaars zeiden 'dom'.16Caveman vs context-mode: kleinere mond, of kleinere kamer?17Code churn: de lava die je nog kunt meten18Het plafond is van beton19De token-belasting: ik trek mijn Caveman-advies in20Zelfs de malware is nu AI-slop21ThePrimeagen had gelijk22Tokenmaxxing: wat er gebeurt als je het verkeerde meet23Ze vroegen het de bot gewoon netjes: je supportagent is het aanvalsoppervlak24Snelheid werd goedkoop. Je oordeel niet.25Je coding agent heeft geen wereldmodel. Jij hebt er een omheen gebouwd.26De Ferrari heeft een begrenzer: een dag met Claude Fable 527De uitknop was nooit van jou28Een open MCP-server is erger dan een open database29Het veerkrachtigste beroep eet zijn eigen zaaigoed op30De uitknop werkt nu ook andersom31AI genereert je tests. Maar test het ook echt?32Beter code leren lezen: een oefenroutine33Programmeren leren in het AI-tijdperk: wat ik als eerste zou leren34Wie is verantwoordelijk voor AI-code? Jij, en sinds dit jaar staat het zwart op wit35Wanneer je beter geen AI gebruikt bij programmeren: het werk dat ik zelf blijf doen36Junior developers aannemen in 2026: de instroom stopte, en dat was een keuze37Software inschatten met AI: het typen was nooit waar de tijd in zat38Slopsquatting: bestaat het package? Verkeerde vraag39Acht rapporten, één meetlat: jureren bij een AI-safety sprint40Er sloeg geen agent op hol