Code wordt goedkoop. Engineering niet.

Brett Chalupa programmeert twintig jaar. Hij publiceerde op zijn kanaal Brett Codes een video met de titel I'm done coding with AI — niet de video die je bij die titel verwacht.

De luie versie van dit genre stelt dat de tools niet werken. Brett stelt het tegenovergestelde. Hij was sceptisch over Copilot en de eerste modellen, ging in 2025 overstag voor agentic programmeren, en leverde vervolgens meer software op dan hij met de hand had kunnen schrijven — hij beschrijft hoe hij Linear aan Claude Code hing en niet-triviale projecten kreeg opgeleverd zonder zelf een regel te wijzigen. Dat werkte, en wie met de rest in discussie wil, moet daar eerst bij stilstaan.

Zijn probleem begon na een jaar, en het was niet productiviteit. De agents produceerden meer code dan hij zinvol kon reviewen. Hij voelde zich losgeraakt van codebases die formeel de zijne waren. Hij leerde minder, omdat hij was gestopt met worstelen met implementatie — en in die worsteling zat het leren. Hij gaf minder om code die hij niet zelf had geschreven. Meer output werd niet meer omzet of een beter product, en als genereren vrijwel gratis is, houdt weinig een team tegen om features te maken waar niemand om vroeg. Zijn rol was platgeslagen tot het reviewen van werk van iemand anders: "basically just a hamster on a wheel, checking boxes", zoals hij het zelf zegt. Dus stopte hij, en ging hij weer met de hand programmeren.

Even helder: de belangrijke delen zijn vrijwel zeker juist. Samengevat is zijn betoog een reeks ongelijkheden die boven elk engineeringbureau mag hangen — meer code is niet betere software, betere software is niet meer klantwaarde, en niets daarvan levert automatisch betere engineers op. Reviewcapaciteit als de echte bottleneck. Eigenaarschap dat verdampt als niemand het ding zelf geschreven heeft. Goedkoop genereren dat stilletjes featurebloat financiert. Wij schreven eerder al dat gegenereerde code niet automatisch goed is, dat constante AI-hulp uitputtend werkt, en dat AI het pad van junior naar senior erodeert. Onze branche heeft op geen van die punten een goed antwoord.

Ik kom alleen niet tot zijn conclusie. Bretts antwoord is stoppen met AI. Mijn antwoord is dat software engineering zelf moet veranderen.

Dus hier is het: de tijd dat je je Java-kennis voor €150 per uur verkocht, loopt af.

Dertig jaar lang was implementatiekennis schaars, en die schaarste was het verdienmodel. Bedrijven hadden mensen nodig die Java en Spring kenden, relationele databases, AWS of GCP, Kubernetes, CI/CD, welk JavaScript-framework dat jaar in de mode was. Die kennis was duur omdat ze moeilijk te verwerven was, en een hele consultancybranche — de onze inbegrepen — verkocht haar per uur.

Generatieve AI valt de schaarste aan, niet het vakmanschap. Competente implementatie wordt dramatisch goedkoper. Als de ene leverancier vier developers drie maanden nodig heeft en een AI-native team hetzelfde probleem met twee ervaren engineers in een fractie van die tijd oplost, gaan klanten dat merken. Ze kochten nooit Java-uren. Ze kochten een opgelost probleem.

Dat betekent niet dat senior engineers waardeloos zijn geworden. Ik schreef in 2023 al dat "het einde van programmeren" verkooppraat was, en dat vind ik nog steeds. Wat ik toen onderschatte, is hoeveel het vak zelf zou opschuiven.

Code wordt goedkoop. Engineering judgement niet. Zodra implementatie overvloedig wordt, schuift de waarde naar de vragen die altijd al moeilijk waren: Wat moeten we bouwen, en wat juist níet? Welke architectuur houdt drie jaar stand, en hoe integreert die met het ERP-systeem waar niemand aan wil zitten? Hoe migreren, beveiligen en beheren we het? Hoe herkennen we gegenereerde code die subtiel en aannemelijk fout is? Hoe voorkomen we dat een agent drie abstractielagen verzint voor een CSV-import, en blijft het resultaat begrijpelijk voor wie er dienst op heeft? En hoe doen we dat allemaal zonder onze beste engineers te veranderen in uitgeputte reviewers van tienduizend gegenereerde regels per dag?

Lees dat lijstje nog eens, want het is Bretts lijstje. Hij benoemt de centrale engineeringproblemen van het AI-tijdperk scherper dan de partijen die eraan verdienen. Zijn conclusie is stoppen met AI. Onze conclusie is betere engineering eromheen.

Nog één economisch punt.

Als iets vijf keer goedkoper wordt, kopen afnemers zelden dezelfde hoeveelheid. Ze kopen meer. Projecten die de businesscase nooit haalden, halen hem opeens. De interne applicatie van €500.000 wordt een project van €75.000. De integratie van €150.000 wordt €25.000. Het klantportaal dat in drie budgetrondes sneuvelde, is plotseling de moeite waard. Het proces dat nooit de moeite van automatiseren waard was, is dat nu op een donderdagmiddag.

De waarschijnlijke toekomst is niet simpelweg "minder programmeurs". Het is veel goedkopere software, en veel meer ervan — software die nog steeds gearchitectureerd, beveiligd, geïntegreerd en beheerd moet worden door mensen die weten wat ze doen. Economen noemen dit de elasticiteit van softwarevraag. Engineers mogen het een grotere backlog noemen.

Dit is de transitie die ZEN Software richting AI-native software engineering en AI-technologieconsultancy heeft geduwd — geen nieuw label op dezelfde uren, maar omdat het werk echt anders is geworden.

In de praktijk helpen we organisaties uitzoeken waar AI de ontwikkelkosten daadwerkelijk verlaagt en waar hij die alleen minder zichtbaar maakt; hoe een team coding agents inzet zonder te verdrinken in review; wat er verandert in architectuur, testen en delivery als een groot deel van je code voorgeschreven binnenkomt; hoe je AI-gegenereerde complexiteit buiten een codebase houdt die je tien jaar moet onderhouden; hoe je moderniseert wat je al hebt in plaats van blind te regenereren; en hoe je van "onze developers hebben Copilot-licenties" naar AI-native workflows komt. Bovenal: hoe lagere implementatiekosten iets worden waar de business naar wijst.

Bijna niemand heeft meer code nodig. Dus: niet meer code kopen — betere software voor minder.

Wil je weten wat AI-native engineering betekent voor je softwareorganisatie, ontwikkelkosten of technologiestrategie? Neem contact met ons op. Kom met een echt probleem in plaats van een demo-aanvraag; dat levert een beter gesprek op.