AI verwijdert de middenklasse van software engineering

Het is 2020. Je bent de meest senior persoon in je team, verantwoordelijk voor de codekwaliteit en de architectuur. Je hebt goede engineering-praktijken opgezet, je reviewt grondig de PR's (pull requests) van minder ervaren collega's en je werkt hard om de codebase gezond te houden.

Dan ga je op een gegeven moment op vakantie. Wanneer je terugkomt, is de codebase een puinhoop. Iedereen heeft elkaars PR's gemerged zonder er echt aandacht aan te besteden; iemand heeft een reeks nieuwe tabellen aan de database toegevoegd om deze te denormaliseren omdat dat makkelijker was, en ze hebben serverless of Kafka aan de stack toegevoegd zonder enig bewijs dat dit nodig was.

Het is oké. Je kunt dit oplossen.

Spring vooruit naar 2026. Je bent niet op vakantie geweest. Het is gewoon een normale maandagochtend. Je zet een lekkere kop koffie, open je computer en ziet dat er zeven PR's klaarstaan om te reviewen. Je opent de eerste:

+24506 -3938

regels code, vergezeld van een door AI gegenereerde beschrijving van wat de wijzigingen zouden moeten doen. Op mysterieuze wijze heeft je team sinds vrijdag meer wijzigingen doorgevoerd dan ze voorheen deden terwijl jij een paar weken weg was.

AI heeft de snelheidslimiet opgeheven

AI zorgt ervoor dat projecten met een zwakke engineering-cultuur veel sneller falen. Er was een tijd dat mensen samen zaten om te bespreken hoe ze iets zouden aanpakken. Nu kunnen ze gewoon een paar uur lang een agent prompten en vervolgens een PR openen.

Het meest tragische aspect van deze werkwijze is dat het, voor het ongetrainde oog, werkt. Als je de branch ophaalt en test, krijg je waarschijnlijk iets dat enigszins functioneel is. Dus wat doen ze? Ze gaan door. Steeds weer. Tot het project een punt bereikt waarop niemand meer weet hoe iets precies werkt.

Het is als iemand die een nieuwe luxe auto op een creditcard koopt. Je ziet de schuld niet; je ziet alleen de auto die er geweldig uitziet.

Maar dan beginnen gebruikers een vreemde bug te rapporteren. Het is inmiddels de vierde keer dat je team probeert dit op te lossen. Of liever gezegd: AI vraagt om het op te lossen. Helaas lijkt het erop dat zelfs Fable er niet uitkomt.

Je gaat praten met de persoon die aan deze feature heeft gewerkt. "Dus, waar komt de data vandaan?" "Hmm... eigenlijk weet ik het niet. Laat me het aan Claude vragen."

Je zit naast elkaar en kijkt hoe er een eindeloze muur van tekst op het scherm verschijnt. Geen van jullie heeft enig idee of het waar is, maar Claude klinkt zeer zelfverzekerd. "Laten we gewoon ultracode aanzetten en het dubbel laten checken?"

Dit gaat even duren. Je begint te praten over het laatste drama op X. Uiteindelijk krijg je antwoord. "Slaat dit voor jou ergens op?" "Ik weet het niet zeker." "Heb jij dit niet gebouwd... vorige week?"

Stilte.

Dit project is zo complex geworden, met zoveel lagen en services, dat niemand in je team mogelijk kan begrijpen wat er aan de hand is. Dus, wat doe je? Het oplossen ervan zou een zodanig kolossale hoeveelheid werk vereisen dat het onmogelijk zou zijn om dit te rechtvaardigen bij het management.

En waar denk je eigenlijk aan? Over een paar maanden zou het toch weer in exact dezelfde staat verkeren. "Laten we Claude gewoon vragen het op te lossen." "Oké. Ik maak een loop en een doel aan, zodat hij niet stopt voordat hij heeft gecontroleerd of alles werkt." "Klinkt goed." "Eigenlijk is mijn Fable-verbruik voor vandaag op, dus ik draai het morgen wel."

Je pakt nog een kop koffie en loopt terug naar je computer. Je hebt nu nog 13 PR's te reviewen. Je ziet iets dat je niet helemaal begrijpt, dus stuur je een bericht naar de persoon die het geschreven heeft. "Waarom doen we dit hier?"

Ze sturen je een link. Het is een Claude-conversatie. Ergens in dat gesprek — begraven tussen Claude die zelfverzekerd één architectuur aanbeveelt, zich verontschuldigt, van gedachten verandert, je collega die vraagt om het opnieuw te overwegen en nog eens 15 rondes van wijzigingen — bevindt zich blijkbaar de ontwerpbeslissing achter deze code. "Welk deel moet ik lezen?" "Waarschijnlijk alles."

Klinkt dit bekend? Wanneer ik hierover spreek, vertelt iemand me uiteindelijk altijd dat niemand grote systemen ooit volledig begreep. Dat is waar. Er werd nooit van je verwacht dat je elke service en elke database volledig begreep. Maar er was tenminste iemand die dat wel deed en het aan je kon uitleggen.

Nu vragen ze het aan een LLM, omdat ze het zelf eigenlijk niet weten.

Slechte engineers zijn niet langer betaalbaar

In elk team zijn competente mensen die het project mogelijk maken. Er zijn ook mensen die het in essentie voor iedereen anderen moeilijker maken. En nu kan iedereen meer code produceren in één dag dan ze voorheen in een jaar deden.

In het bovenstaande verhaal faalt iedereen:

• De engineer die een PR van 25.000 regels opent, had de agent lang voordat het daarbij kwam moeten stoppen. Ze hadden moeten begrijpen wat de AI deed, het werk in kleinere stukken moeten opdelen en elke nieuwe abstractie die werd geïntroduceerd moeten bevragen.
• De persoon die het reviewde, had moeten weigeren om iets van die omvang te reviewen in plaats van toe te geven.
• De persoon die Kafka toevoegde, had precies moeten kunnen uitleggen waarom dit nodig was.
• De persoon die de feature bouwde, had moeten kunnen uitleggen waar de data vandaan kwam zonder een link naar een Claude-conversatie te sturen.

Maar wat is dan het probleem? Gebruik AI om het op te lossen. Nou, dat is niet zo makkelijk...

Voordat iemand hierop inspringt: dit betekent niet dat technische schuld altijd slecht is. Het belangrijke is dat je weet dat het een shortcut is. In ieder geval is het terugdraaien van een slechte beslissing moeilijk. Zeer moeilijk.

Neem bijvoorbeeld: hoe lang zou een LLM erover doen om een reeks tabellen en kolommen aan de database toe te voegen? Tien minuten? Maar zodra je daar data in gaat opslaan, kun je ze niet zomaar verwijderen. Je moet komen met een migratieplan, ervoor zorgen dat je het systeem niet verstoort (omdat mensen dagelijks betalen om dit te gebruiken), nadenken over wat je doet als de migratie faalt en controleren dat je niet eindigt met wees-foreign-keys. Het is simpelweg veel moeilijker om te repareren, zelfs met het beste model dat je kunt krijgen.

En terwijl je het herstelt, blijven er meer PR's binnenkomen. Meer code, meer abstracties, meer beslissingen. Een persoon kan in een middag 20.000 regels code genereren, maar je moet nog steeds daar zitten en begrijpen wat die regels daadwerkelijk doen. Tegen de tijd dat je één slechte beslissing hebt ontward, zijn er vijf nieuwe gemerged.

De nieuwe AI-economie

Natuurlijk waren slechte engineers altijd al een last. Dat is al decennia zo, lang voordat OpenAI of Anthropic bestonden. Slechte beslissingen stapelden zich op, onnodige complexiteit accumuleerde en teams eindigden met het onderhouden van systemen die niemand echt begreep.

Het verschil is dat er vroeger een limiet was aan de snelheid waarmee dit kon gebeuren.

Tegenwoordig is implementatie goedkoop. Je wordt betaald om goede beslissingen te nemen; om software te bouwen die schaalt terwijl je de complexiteit beheerst. Vraag jezelf af waarom bedrijven in Londen of San Francisco überhaupt zescijfrige salarissen betalen voor engineers. Als ze alleen iemand nodig hadden die een specificatie kon omzetten in werkende code, waarom betaalden ze dan zoveel toen dat al goedkoop elders gedaan kon worden? Waarom blijven techbedrijven die beweren dat "software is solved" nog steeds topsalarissen betalen om de beste mensen aan te trekken?

Mijn weddenschap is dat AI de salarissen verder uit elkaar drijft. Om inzetbaar te zijn, is er een lat waar je overheen moet, en die lat is precies wat het huidige beste model van de dag kan doen.

Goede engineers zijn waardevoller geworden omdat AI hen in staat stelt veel sneller te bewegen. Ze hebben niet langer zoveel mensen om zich heen nodig om alleen het implementatiewerk te doen. Tegelijkertijd zijn slechte engineers veel duurder geworden om aan te nemen. Ik schreef hier eerder over toen ik zei dat het carrièrepad van de vibe coder gedoemd is.

Je moet een bijdrage leveren die verder gaat dan wat iedereen al krijgt door een agent een prompt te geven. Als je het oordeelsvermogen mist dat nodig is om de aanbeveling van een LLM te evalueren, lost het vragen om meer oordeelsvermogen het probleem niet op.

Op een gegeven moment moet er nog steeds iemand weten wat er aan de hand is. En dat is de meest waardevolle persoon in het team. De mensen die dat niet weten, zullen veel goedkoper worden om aan te nemen of volledig worden vervangen, terwijl het geld vloeit naar een steeds kleiner aantal mensen die daadwerkelijk vertrouwd kunnen worden.

Ik geloof niet dat dit beperkt zal blijven tot software engineering. Ik geloof dat hetzelfde zal gebeuren in het grootste deel van de kenniswerkerssector. AI zal de beste mensen veel productiever maken en de slechte mensen bijna onmogelijk om aan te nemen. Voorheen was er een goede kans dat iemand hun slechte beslissingen zou opmerken voordat ze te ver gingen. Nu kunnen ze wijzigingen doorvoeren sneller dan wie dan ook om hen heen deze realistisch kan reviewen of begrijpen.