Stop met copy-paste engineering
4m leestijd

Stop met copy-paste engineering

We kweken een generatie developers die op topsnelheid richting een ravijn rennen. Over AI-hallucinaties, echoput-tests en waarom jouw brein de enige echte debugger is.

Laten we de "corporate" taal even overboord gooien. Als senior developer zie ik de bui namelijk al hangen: we zijn collectief een generatie "copy-paste engineers" aan het kweken die op topsnelheid richting een ravijn rennen. Zo eet het vak zijn eigen zaaigoed op. Het probleem is niet dat AI dom is. Het probleem is dat AI overtuigend is, zelfs als het klinkklare onzin verkoopt.

Hier is de rauwe waarheid over waarom je die "magic button" nooit moet indrukken voor logica die boven je eigen pet gaat.

De "gestoorde professor" in je codebase

Stel je voor: je huurt een assistent in die 10.000 boeken heeft gelezen, maar nog nooit een dag in de echte wereld heeft gewerkt. Dat is een coding agent. Hij kan je een briljante oplossing geven voor een complex probleem in Rust of Go, maar hij begrijpt de consequenties niet.

Het afgelopen jaar zagen we dit bij de "AI Package Hallucination" aanvallen. Onderzoekers van Lasso Security ontdekten dat AI's vaak verwijzen naar libraries die helemaal niet bestaan. Hackers zagen dit, registreerden die namen op npm of PyPI met kwaadaardige code erin.

Resultaat: je hebt malware in je systeem gepusht omdat je de code die de agent schreef niet zelf kon valideren. Jij dacht dat je een handige helper had. In werkelijkheid heb je een achterdeur opengezet voor hackers omdat je te lui was om de import-logica zelf te checken.

Het "student die zijn eigen examen nakijkt"-syndroom

Je zegt dat je de tests ook door de AI laat schrijven? Gefeliciteerd, je hebt zojuist een echoput gebouwd. In de software-engineering noemen we dit confirmation bias op steroïden.

Als een agent een subtiele fout maakt in een algoritme, laten we zeggen een O(n²) operatie waar een O(n log n) nodig is (het verschil tussen een bevroren browser en tien milliseconden), dan zal de test die diezelfde agent genereert alleen controleren of de output klopt voor kleine datasets. De agent "weet" immers niet dat de code efficiënt moet zijn. Hij weet alleen wat hij zojuist heeft geschreven.

Je krijgt een groen vinkje, gaat rustig slapen, en wordt de volgende dag wakker met een gecrashte server omdat je productie-data 100 keer groter was dan je test-data. Je hebt geen kwaliteit gecontroleerd. Je hebt alleen gevraagd: "Vind je jezelf een goede programmeur?" en de AI zei "Ja". Wil je weten wat zulke tests echt waard zijn, haal er dan mutation testing bij.

De AWS- en Cloudflare-lessen: automatisering is een vermenigvuldiger

Kijk naar de grote incidenten van eind 2024 en begin 2025. Rapporten van Snyk en Datadog wijzen op een stijgende lijn in "automated misconfigurations". Bij een grote cloud-outage vorig jaar had een AI-agent een reeks Terraform-scripts aangepast om "kosten te besparen". De wijzigingen waren technisch correct, maar de engineers die de code goedkeurden begrepen de diepere netwerk-implicaties niet.

Ze vertrouwden op de snelheid van de agent.

Het resultaat? Een cascade-fout die een hele regio platlegde.

De les: AI versterkt je fouten en maakt ze sneller en groter. Als jij de logica niet zelf kunt uitschrijven, ben je gewoon een passagier in een vliegtuig zonder piloot.

Waarom jouw brein de enige echte debugger is

Software schrijven is voor 10% typen en voor 90% nadenken over randgevallen. Een agent is een kampioen in die 10%, maar een amateur in die 90%.

Uit een veelgeciteerd onderzoek van de Universiteit van New York (NYU) bleek dat ongeveer 40% van de code gegenereerd door AI-tools beveiligingslekken bevat. Waarom? Omdat AI getraind is op alle code op internet, inclusief de troep die studenten in 2012 op GitHub gooiden.

Als jij die code accepteert zonder het fundamentele inzicht om de kwetsbaarheid te herkennen, ben jij degene die verantwoordelijk is wanneer de data op straat ligt.

Je kunt tegen je CEO niet zeggen: "Maar de chatbot zei dat het veilig was." De rechter in de Air Canada-zaak (2024) was daar heel duidelijk over: een bedrijf is 100% verantwoordelijk voor de onzin die hun AI uitkraamt. Dat geldt voor chatbots, en dat geldt dubbel voor je broncode.

Wil je de bronnen zelf checken?

Mijn advies? Gebruik die agent voor je boilerplate, voor je saaie CSS-classes of om een regex uit te leggen. Maar zodra het aankomt op je business logica, je beveiliging of je database-integriteit: leg die agent het zwijgen op en pak zelf het toetsenbord.

(3 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