Als AI het meeste code schrijft, draait het om oordeel

Anthropic deelde onlangs een getal dat veel mensen deed stilhouden: Claude schrijft nu meer dan 80 procent van de productiecode die hun eigen engineeringteams deployen. Hun engineers shippen ruwweg acht keer meer per dag dan in 2024. Dit zijn geen projecties. Dit gebeurt nu binnen één van de voorzichtigste AI-labs ter wereld.

Bij de meeste agentschappen en productteams is het instinct om dat getal toe te juichen. Sneller output. Lagere kosten per feature. Meer runway met dezelfde headcount. Al dat spul is echt. Maar de interessantere vraag is die niemand stelt op hun sprint planning: wanneer het systeem dat de code schrijft ook het systeem verbetert dat code schrijft, wie neemt dan eigenlijk de besluiten?

De loop die niemand op het whiteboard heeft getekend

Er zit hier een specifieke dynamiek waar het waard is om precies naar te kijken, want de vage versie ervan leidt tot vaag denken.

Een developer die een AI-codeeringsassistent gebruikt, is nog steeds de auteur. Ze zetten het doel uit, reviewen de output, pushen de commit, dragen de verantwoordelijkheid. Het model is een heel snelle, heel capabele tool. Dit is de wereld waar de meeste productteams denken dat ze in leven.

Maar wanneer het model het merendeel van zijn eigen infrastructuur, zijn eigen testsuites en zijn eigen tooling genereert, verandert de relatie. De engineer authoriseert niet meer. Ze superviseren. En supervisie op acht keer vorige snelheid betekent dat elke reviewbeslissing zwaarder weegt, niet lichter, omdat de blast radius van een gemiste oordeel groter is.

Dit is niet hypothetisch. Anthropic worstelt publiekelijk met de vraag of zelf-verbeterend AI een gecoördineerde wereldwijde ontwikkelingspauze rechtvaardigt. Dat ze de vraag überhaupt stellen, vertelt je dat de loop echt is en dat de mensen er dicht tegenaan niet zomaar afschuiven.

Wat dit betekent voor agentschappen en productteams

De meeste agentschappen zijn niet Anthropic. Je bouwt geen frontier models. Maar dezelfde structurele vraag speelt ook op kleinere schaal, en ze komt sneller aan dan de meeste teams hebben opgemerkt.

Als je developers AI gebruiken om het merendeel van de code te schrijven, is je werkelijke schaarse resource verschoven. Het is niet langer typsnel heid of syntaxis onthouden. Het is smaak, oordeel en het vermogen om een plausibel verkeerd antwoord te pakken voordat het production raakt. Dat zijn geen vaardigheden die uit prompt engineering-cursussen komen. Die komen van jaren dingen debuggen die zouden moeten werken maar niet werkten.

De teams die in de problemen komen zijn de teams die zich hebben geoptimaliseerd voor doorvoer zonder in de oordeelslaag te investeren. Ze shippen sneller, stapelen onzichtbare schuld op, en raken uiteindelijk op een punt waar niemand op het team kan uitleggen waarom het systeem zich zo gedraagt. De teams die niet in problemen zijn zijn die teams die de snelheidswinst hebben gezien als kans voor harder nadenken, niet minder.

Er is ook een clientgesprek dat agentschappen voor moeten zijn. Wanneer een client vraagt hoe lang een feature gaat duren, en het eerlijke antwoord is "twee dagen met AI-hulp," volgt daarop de vraag: "Waarom kost het dan wat het kost?" Het antwoord is niet het typen. Het was nooit het typen. Het antwoord is de scoping, de architectuurbeslissing, de keuze wat niet te bouwen, en de review die het zelfverzekerde misverstand van het model op regel 340 pakt. Als je dat niet kunt uitleggen, verlies je het gesprek.

De governancegap die niemand opvult

Anthropics interne debat over pauzering van zelf-verbeterend AI-ontwikkeling is een governancevraag op beschavingsschaal. Je agentschapversie van dezelfde vraag is bescheidener maar structureel identiek: wie heeft het gezag om nee te zeggen, en op welk moment in het proces?

De meeste teams hebben dit niet beantwoord. Ze hebben AI-codeeringstools aangenomen omdat de productiviteitswinsten duidelijk zijn, en ze hebben aangenomen dat bestaande code review-processen zullen pakken wat nodig is. Die aanname staat onder druk.

Code review is ontworpen voor menselijk getimede output. Wanneer een pull request 800 regels bevat die in 40 minuten zijn geschreven, gebeurt de review niet met dezelfde diepte als voor 800 regels die over twee dagen zijn geschreven. De reviewer weet minder over de redenen achter elke keuze, omdat er geen zichtbaar redeneringsproces was om op te letten. Het model laat geen notities achter over wat het heeft overwogen en verworpen.

Er zijn hier echt een paar dingen die helpen. Eerst. maak de review-eenheid kleiner. Kleinere PRs die vaker reviewed worden slagen beter dan grote PRs die snel reviewed worden. Dit vereist dat je het commit-ritme afremdt, wat ertegen instrijkt wanneer het hele punt was om sneller te gaan. Doe het toch. Tweede: laat de engineer die de output heeft aangestuurd het approach hardop uitleggen voordat je reviewt. Niet de code, het approach. Als ze dat niet kunnen, mag de code niet shippen. Derde: maak expliciete decision logs voor alles wat architecturaal is. Niet een document dat niemand leest, een kort verslag van wat is overwogen, wat is gekozen en waarom. AI kan die ook helpen schrijven, maar een mens moet bevestigen dat ze accuraat zijn.

De vraag die het waard is om op je volgende retrospective te stellen

Niet "hoeveel shippen we" maar "begrijpen we goed wat we hebben geshipt?"

Die twee dingen zijn altijd aan elkaar gerelateerd geweest. Nu zijn ze ontkoppeld. En de teams en studios die de gat eerst opmerken, zijn degenen die de voorwaarden bepalen hoe dit werkt, in plaats van iemand anders zijn antwoord over te nemen.

Bij Studio Hyra hebben we hier het afgelopen jaar mee gewerkt voor clients in product- en agentschapcontexten. Het patroon dat we steeds zien is dat de bottleneck nooit het vermogen van het model is. Het is het menselijk proces eromheen. Het model kan de code schrijven. De vraag is of je team er de eigenaar van is.

Die eigenaarsvraag wordt niet opgelost met een beter prompt. Die wordt opgelost door eerlijk te zijn over wat je team echt begrijpt, processen te bouwen die verwarring vroeg aan het licht brengen, en oordeel als de vaardigheid te behandelen waar het nu om gaat nu raw output goedkoop is.

Tachtig procent van de code gewritten door het model. Acht keer het dagelijkse shipritme. Die getallen zullen blijven groeien. De oordeelslaag is de ene variabele die niet automatisch opscaalt.