AI haalt de middenklasse uit software engineering

Er is een soort pull request dat je de laatste tijd vaker voorbij ziet komen. Ruim 24.000 toegevoegde regels, geopend op dinsdag, gemerged op woensdag. Niemand heeft het gelezen. Iedereen heeft goedgekeurd. De pipeline was groen, dus wat wil je nog.

Dat voorbeeld komt uit AI is removing the middle class of software engineering van Florian Herrengt, een stuk dat me langer bijbleef dan ik had verwacht. Zijn stelling: AI heeft de kwaliteit van code niet veranderd, maar wel de snelheid waarmee verkeerde beslissingen je codebase in glippen. Teams met een zwakke engineeringcultuur falen daardoor niet minder vaak, maar sneller.

Op het grootste deel daarvan heeft hij gelijk. Op zijn conclusie over de arbeidsmarkt niet helemaal, en dat is precies het interessante deel.

De snelheidslimiet zat nooit in het typen

Jarenlang was de trage stap het schrijven. Je zat een middag op een module, je collega las hem in twintig minuten, en die verhouding was werkbaar. Reviewen kostte een fractie van bouwen.

Die verhouding is omgekeerd. Genereren duurt nu een minuut, begrijpen nog steeds een middag. En omdat alleen de eerste helft versneld is, staat de tweede helft onder druk die niemand expliciet heeft ingecalculeerd.

Wat er dan gebeurt is voorspelbaar. Mensen scrollen. Ze kijken naar de bestandsnamen, ze zien dat de tests draaien, ze typen "LGTM" en gaan door met hun eigen werk. Het onderzoek dat SmartBear in 2006 bij Cisco deed staat er nog steeds: voorbij ongeveer 400 regels of zestig minuten aaneengesloten reviewen zakt het aantal gevonden defects in elkaar. Die grens verschuift niet mee omdat het model beter werd. Hij gaat over ons.

Dus je merget code die werkt. Werkt is niet hetzelfde als klopt.

Niemand weet meer waarom

Het scherpste stuk uit Florians verhaal is de scène waarin iemand een bug onderzoekt in een feature die hij zelf drie dagen eerder heeft gebouwd, en niet kan uitleggen waar de data vandaan komt zonder het even aan Claude te vragen.

Dat is het punt waarop iets fundamenteels verschuift. git blame geeft je altijd nog wie en wanneer. De waarom zat vroeger in het hoofd van degene die het schreef, of anders in een discussie onder de PR. Nu zit die in een chatsessie die niemand bewaard heeft, op de laptop van iemand die in maart is vertrokken.

Ik zie dat terug in hoe teams over hun eigen systeem praten. Vragen als "waarom draait die job elke tien minuten en niet elk uur" leveren steeds vaker een schouderophalen op. De redenering heeft nooit ergens vorm gekregen buiten het gesprek waarin ze ontstond.

Een voorbeeld uit een project van vorig jaar. In de webhookhandler stond een deduplicatievenster van elf minuten. Elf. Niemand kon uitleggen waarom het geen tien of vijftien was, dus bij een opruimronde ging het naar vijf, met als commit message: config opgeschoond.

Drie weken later kwamen er dubbele orders binnen: een stuk of veertig, verspreid over een dag of tien. Dat was weinig genoeg om het pas laat op te merken.

Het antwoord bleek in de documentatie van de betaalprovider te staan. Die probeert een mislukte webhook opnieuw na één, vijf en tien minuten, dus een venster van elf minuten dekt alle drie de pogingen af. Zet je het op vijf, dan valt de laatste retry erbuiten. Je systeem maakt vervolgens keurig een tweede order aan.

Het opsporen kostte anderhalve dag. Daarna nog een middag handmatig corrigeren bij de administratie en twee terugbetalingen aan klanten die het zelf gemeld hadden. Die elf minuten waren maanden eerder gekozen in een sessie met een assistent ernaast. Niemand had opgeschreven waarom.

De asymmetrie is het hele verhaal

Bouwen werd goedkoper. Terugdraaien niet.

Een gedenormaliseerde kolom die vorige maand handig leek, wordt in veertig plekken uitgelezen tegen de tijd dat je merkt dat het model niet klopt. Daar is geen prompt voor. Dat is een migratie, een backfill, een leesperiode met dubbele schrijfacties en een week waarin je collega's vragen waarom hun feature stilligt.

Herrengt formuleert het scherper dan ik het zou doen: tegen de tijd dat je één slechte beslissing hebt ontward, zijn er vijf andere gemerged.

Daar zit de kern. AI schrijft inmiddels prima code; het probleem is dat de generatiesnelheid met een factor tien omhoog ging en de correctiesnelheid met nul. Elk systeem waarin de instroom sneller groeit dan de afvoer, loopt uiteindelijk over. Dat is geen mening over AI, dat is een wachtrij.

Hier ben ik het niet met hem eens

Zijn conclusie is dat de markt uiteenvalt. Goede engineers worden veel meer waard, slechte onbetaalbaar, en de middenmoot verdwijnt.

De economische logica klopt op korte termijn. De sociologische niet, denk ik. Wat verdwijnt is geen categorie mensen maar een categorie werk.

Kijk naar hoe je vroeger een medior werd. Je kreeg het saaie implementatiewerk: de vierde CRUD-endpoint, het formulier, de mapper tussen twee datamodellen. Je deed dat honderd keer onder review van iemand die er meer verstand van had, en ergens rond keer zeventig begon je te zien waarom bepaalde patronen steeds terugkwamen. Oordeelsvermogen ontstond als bijproduct van herhaling.

Dat werk is nu weg. Daarmee zijn de onderste treden van de ladder eruit gezaagd, terwijl we van mensen blijven verwachten dat ze bovenaan verschijnen.

Dus ja, teams betalen straks meer voor engineers met oordeelsvermogen. Maar dat is geen natuurwet die zichzelf oplost, het is een tekort dat we zelf aan het produceren zijn. De teams die over vijf jaar seniors hebben, zijn de teams die nu bewust betalen voor het trage leerproces dat ze technisch gezien niet meer nodig hebben. Dat kost geld en het staat op geen enkel dashboard.

Wat je maandag kunt veranderen

Je hoeft hiervoor niet minder AI te gebruiken. De tweede helft moet alleen meebewegen met de eerste.

Zet een harde bovengrens op de omvang van een PR. Vierhonderd regels is een goed startpunt, met een expliciete uitzondering voor gegenereerde bestanden en lockfiles. Gaat het eroverheen, dan splitsen. Vanaf die omvang leest niemand een diff nog echt, hoe goed bedoeld ook.

Laat de auteur de PR-beschrijving zonder AI schrijven. In eigen woorden: wat verandert er, waarom deze aanpak, wat is de eerste plek waar het misgaat. Wie dat niet kan opschrijven, snapt zijn eigen change niet, en dan is de review van een collega een formaliteit.

Leg beslissingen ergens vast waar ze te vinden zijn. Een ADR van tien regels in de repo is genoeg. Een chatgeschiedenis is geen documentatie, want je nieuwe collega kan er in maart niet in zoeken.

Maak terugdraaien goedkoop voordat je het nodig hebt. Feature flags, migraties met een geteste down-stap, deploys die je binnen een minuut ongedaan maakt. Zolang correctie duur blijft, wint de instroom altijd.

Meet geen output in gemergde regels of PR's. Die getallen kun je nu met een prompt vervalsen zonder dat iemand liegt, dus ze meten niets meer.

De teams die hier de komende jaren tegenaan lopen zijn niet de teams die AI omarmd hebben. Het zijn de teams die het met review al niet zo nauw namen, en die nu vier keer zo hard dezelfde kant op rijden. Het gereedschap heeft niets kapotgemaakt; het laat vooral zien hoeveel van je engineeringcultuur op traagheid dreef.

Het originele stuk van Florian Herrengt lees je hier. Aanrader, ook als je het met de conclusie oneens bent.