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 het 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 het 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 business-model klopt niet meer.

Pak de regie terug

Een coding agent is een prima assistent, maar een waardeloze architect. Gebruik het 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 het niet in je repo thuis. Die zin houdt inmiddels ook voor de rechter geen stand. Blijf de baas over je eigen stack.

(2 van 31)
01Je hebt geen AI-probleem. Je hebt een procesprobleem.02Waarom je nooit code moet shippen die je zelf niet snapt03Stop met copy-paste engineering04De lavalaag: waarom AI-code je codebase langzaam versteent05De prompt is geen spec06Het briljante papegaai-probleem: wat AI eigenlijk doet als het 'denkt'07De bureaucratie van bots: waarom we de controleur controleren08De wapenwedloop om je vertrouwen: Mythos, Cyber en de security-hype09Laat je agents stoppen met Markdown schrijven10Je vindt de bug niet als je de code niet schreef11Een op vier: de beveiligingsschuld die niemand telt12Je 10x-developer zit vast in een 0,1x-pipeline13Caveman vs context-mode: kleinere mond, of kleinere kamer?14Code churn: de lava die je nog kunt meten15Het plafond is van beton16De token-belasting: ik trek mijn Caveman-advies in17Zelfs de malware is nu AI-slop18ThePrimeagen had gelijk19Tokenmaxxing: wat er gebeurt als je het verkeerde meet20Ze vroegen het de bot gewoon netjes: je supportagent is het aanvalsoppervlak21Snelheid werd goedkoop. Je oordeel niet.22De Ferrari heeft een begrenzer: een dag met Claude Fable 523De uitknop was nooit van jou24Een open MCP-server is erger dan een open database25De uitknop werkt nu ook andersom26AI genereert je tests. Maar test het ook echt?27Beter code leren lezen: een oefenroutine28Programmeren leren in het AI-tijdperk: wat ik als eerste zou leren29Wie is verantwoordelijk voor AI-code? Jij, en sinds dit jaar staat het zwart op wit30Wanneer je beter geen AI gebruikt bij programmeren: het werk dat ik zelf blijf doen31Junior developers aannemen in 2026: de instroom stopte, en dat was een keuze