Waarom je nooit code moet shippen die je zelf niet snapt

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.

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 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-eend scenario 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.

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. Blijf de baas over je eigen stack.