De AI-codingval: 6 metrics die misleiden (en waarom je ROI-berekeningen waarschijnlijk fout zijn)

Je hebt de deal getekend. Je team werkt nu met AI-tools die code kunnen genereren. De leverancier belooft snellere ontwikkeling, tevreden developers en een duidelijke return on investment. Je manager wil bewijs.

De ongemakkelijke waarheid? De cijfers die je straks presenteert, kunnen iedereen overtuigen dat de tools werken—terwijl ze ondertussen problemen verhullen die je nog niet ziet.

Waarom "Lines of Code" een loze metric is

De meest verleidelijke metric is lines of code. Na de invoering van AI-tools meet je een stijging van veertig procent in code per developer. Succes, toch?

Niet per se.

Meer code betekent niet automatisch betere resultaten. Vaak is het tegenovergestelde waar. Een developer die tweeduizend regels verouderde, ingewikkelde code omzet naar tweehonderd regels strakke, onderhoudbare code heeft iets waardevols gedaan—maar jouw metric registreert een dramatische daling.

AI-tools schrijven vaak meer dan nodig. Ze leveren werkende code,但 ze kiezen meestal voor de uitgebreidere variant. Wat je eigenlijk meet, is niet productiviteit maar overdaad. En overdadige code brengt extra onderhoud, meer risico op bugs en maakt het lastiger voor nieuwe mensen om in te werken.

De les: Als je succes afmeet aan de hoeveelheid code, meet je het verkeerde.

De kunstmatige snelheidswinst die niet standhoudt

Een bekende studie toont aan dat developers met GitHub Copilot taken vijfenvijftig procent sneller afronden. Indrukwekkend.

Maar de context ontbreekt: de developers bouwden een HTTP-server in JavaScript vanaf nul, zonder afleiding, in een vast tijdsvenster van negentig minuten.

In de praktijk ziet softwareontwikkeling er anders uit. Developers werken aan bestaande, grote codebases. Ze krijgen vaak vagere requirements, moeten schakelen tussen Slack en meetings, en zijn afhankelijk van meerdere teams. De snelheid die ze in een geïsoleerde, eenvoudige taak laten zien, zegt weinig over hun werk in de dagelijkse praktijk.

Er is nog een studie die laat zien dat ervaren open-source developers juist negentien procent langer nodig hebben met AI-tools. De schijn van efficiency maskeert de extra tijd die nodig is om suggestions te reviewen en corrigeren.

De les: Benchmark op realistische taken. Experimenten met een simpele taak zijn goed voor marketing, maar slecht voor beslissingen.

Voordat en daarna zonder een controle groep

January: je introduceert AI-tools.

June: de snelheid van pull requests stijgt met veertig procent.

De tools lijken te werken. De conclusie is klaar.

En toch: tussen januari en juni ook nog:

• Je nam twaalf nieuwe engineers aan
• Je verbeterde je CI-pipeline
• Je wisselde van cloud provider
• Je leverde twee grote features die je codebase eenvoudiger maakte

De conclusie is niet te vertrouwen zonder een groep dat de tools niet kreeg. De stijging van de geschwindigkeit kan door elk van deze maatregelen komen. Je meet een verband, niet een oorzaak.

De les: A/B-testing is ook voor tooling beslissingen belangrijk—evenals wanneer het overdreven voelt.

"87% van de developers voelt zich productiever" (en waarom dat irriterend is)

Survey resultaten zijn populair. Ze zijn ook misleidend. Niet omdat developers eerlijk of dishonest zijn, maar omdat drie biases meespelen:

Hawthorne Effect: Als mensen weten dat ze geobserveerd worden, veranderen hun gedrag.

Novelty Effect: Nieuwe tools voelen sneller omdat ze nieuw zijn. Dit effect verdwijnt snel, but de survey krijgt het niet mee.

Social Desirability Bias: Developers rapporteren wat ze denken dat management wil horen.

Het gevoel van productiviteit meet niet wat er echt gebeurt.

De les: Vertrouw niet alleen op het gevoel van developers. Meet wat er echt gebeurt.

Commits, PRs en Tickets tellen (en hoe Goodhart's Law je opbreekt)

McKinsey adviseert om developer productivity te meten met commit counts, pull requests en ticket velocity. Het klinkt objective.

Dan komt Goodhart's Law: als een meting een doel wordt, verliest ze haar waarde.

De developers weten dat commit counts worden gemeten, so ze maken meer en kleinere commits. De numbers verbeteren, but de echte waarde blijft hetzelfde.

De les: Metrics die publiek zichtbaar zijn, zullen worden beïnvloed.