Waarom AI-teams sneller bouwen maar slechter lanceren: het intent-debt-probleem

AI maakte code schrijven vrijwel gratis. Bepalen wat er geschreven moet worden is moeilijker geworden. Dat gat is intent debt, en het groeit sneller dan welke legacy codebase ooit heeft gedaan.

Garry Tan meldt 37.000 regels code per dag te shippen over vijf projecten, terwijl hij fulltime Y Combinator runt. Anthropics eigen engineers leverden 47 dagen stille regressies in Claude Code voordat die werden ontdekt in een publieke postmortem op 23 april 2026. Beide cijfers beschrijven hetzelfde probleem, maar vanuit tegenovergestelde kanten.

Schrijft uw team meer code dan ooit en levert het slechtere resultaten op dan een jaar geleden, dan ziet u intent debt in real time oplopen. Technische schuld was de belasting op traag coderen. Intent debt is de belasting op traag beslissen. Dit artikel benoemt het knelpunt, laat zien waarom review- en evaluatielagen het niet kunnen opvangen, en beschrijft de vier aanpakken om de schuld af te lossen.

• AI comprimeerde codeertijd met 30 tot 100 keer. Beslissingstijd comprimeerde met 3 tot 5 keer. Dat verschil is het nieuwe knelpunt.

• Intent debt bevindt zich stroomopwaarts van elke reviewlaag. AI-codebeoordelaars, evals en QA-agents vangen slechte code op; ze vangen niet op dat het verkeerde ding goed gebouwd is.

• Anthropics 47 dagen stille regressies in Claude Code zijn een intent-debt-postmortem vermomd als een eval-probleem. De drift zat niet in de code, maar in waar het team aandacht aan besteedde.

• De oplossing is structureel, niet tactisch. Er is geen weg door meer te shippen. De enige uitweg is eerder en sneller beslissen.

• webvise behandelt intent-vastlegging als het eigenlijke eindproduct, niet als een gratis pre-salesactiviteit. Bekijk waar dit van toepassing is op uw team.

Wat intent debt werkelijk is

Technische schuld is de term die Ward Cunningham in 1992 bedacht voor de toekomstige kosten van het kiezen van een snelle oplossing boven een schone. De afweging had duidelijke economie: eerder leveren, rente betalen in de vorm van moeilijker onderhoud later, en het kapitaal lag in de codebase als iets dat u kon refactoren wanneer de tijd het toeliet.

Intent debt heeft dezelfde vorm. De afweging is snellere code in ruil voor vagere beslissingen. U levert eerder omdat de AI de implementatie in 30 minuten schreef in plaats van drie dagen, en de rente is alles stroomafwaarts dat oploopt wanneer het team nooit heeft vastgesteld wat de juiste uitkomst had moeten zijn.

Het vocabulaire ontbreekt omdat de afweging nieuw is. Martin Fowlers schrijven over naamgeving en design intent gaat uit van een wereld waarin het schrijven van code de dure stap was, zodat een goed ontwerp zichzelf terugverdiende in minder herschrijfwerk.

Die aanname keerde in 2024 om. Wanneer herschrijven een dag kost, betaalt de ontwerpstap zich niet meer terug zoals vroeger. Teams merken dit en slaan de ontwerpstap over: precies de plek waar intent werd samengevat tot iets waarover de volgende persoon kon redeneren.

Twee patroonfouten die persoonlijk zijn waargenomen.

De eerste: een feature wordt in drie dagen geshipt die voor AI drie weken had gekost. Het werkt. Het lost ook een probleem op dat gebruikers niet hadden, omdat de spec een Slack-bericht was en de uitvoerder een Cursor-agent. De bouwkosten waren zo laag dat het team nooit opnieuw heeft afgevraagd of het de moeite waard was.

De tweede: een senior engineer beëindigt zes productrichtingen in één jaar. Geen enkele gaat ten onder om technische redenen. Elke richting sterft in de pre-salesfase, terwijl de engineer die stap steeds overslaat omdat code schrijven productiever aanvoelt. Dat is een persoonlijke ervaring, en de postmortemkosten van die zes richtingen waren hoger dan welke technische schuld ooit is afgelost.

Beide verhalen zijn intent debt met de bonnetjes. De meeste engineeringteams proberen ze nog altijd op te lossen op de bouwlaag: met een extra reviewer, een extra eval, een extra linter. De oplossing zit één laag hoger. Produceert uw team dit soort bonnetjes, dan is webvise gebouwd rondom die inversie.

De cijfers achter de verschuiving

De duidelijkste first-party data over de asymmetrie komt uit het gstack ETHOS-bestand van Garry Tan, gepubliceerd in april 2026. Tan shippt een open-source agenttoolkit vanuit Y Combinator en instrumenteert zijn agents met expliciete compressieratio's mens-versus-AI per taaktype.

Lees de tabel kolom voor kolom. Boilerplate comprimeert 100x, tests schrijven 50x, featurewerk 30x. Architectuur en onderzoek comprimeren 5x en 3x.

De onderste drie rijen zijn intentwerk. Ze comprimeren, maar op een tiende van het tempo van de bovenste drie. Dat is de structurele bron van intent debt: coderen is nu vrijwel gratis, beslissen blijft duur.

Concreet gesteld: besteedde uw team vroeger 80% van een engineeringdag aan code en 20% aan beslissingen, dan ziet de nieuwe verhouding na 30x compressie op code er ruwweg uit als 12% code en 88% beslissingen. De meeste teams hielden dezelfde bezetting, hetzelfde vergaderritme en dezelfde reviewstructuur aan, en zagen vervolgens de tweede kolom overlopen.

Dat overlopen is hoe intent debt er in de praktijk uitziet.

Drie symptomen waaraan u het herkent

Intent debt is onzichtbaar totdat u het benoemt. Drie symptomen komen steeds terug bij teams waarmee gewerkt wordt.

Scope-snijreflex bij werk met vaste kosten

U betrapt uzelf op het schrijven van drie tests in plaats van tien, het overslaan van de documentatie, het genoegen nemen met 80%. Het instinct klopte toen menselijke tijd de beperkende factor was. Met AI in de loop kost de volledige versie dezelfde minuten als de tijdelijke oplossing.

De reflex is inmiddels verouderd denken, automatisch toegepast. De kosten zijn de beslissingsgewoonte die zegt dat eerder shippen beter is dan correct shippen, terwijl eerder shippen u geen tijd meer oplevert.

Meer reviewen, minder beslissen

Elie Steinbock publiceerde op 20 april 2026 een these die review aanwijst als het nieuwe knelpunt. Hij somt zeven verdedigingslagen op, van AI-codebeoordelaars zoals Cubic en CodeRabbit tot toegewijde QA-agents en gerichte observability. Teams adopteren de lagen en het reviewoppervlak absorbeert steeds meer van de dag.

Intent debt bevindt zich stroomopwaarts van al deze tools. AI-reviewers vangen slechte code op; ze vangen niet op dat het verkeerde ding goed gebouwd is. Een QA-agent die elke stroom bij elke release doorloopt, vertelt u dat de stroom werkt, niet of de stroom zou moeten bestaan.

Stille drift die u pas in postmortems ziet

Anthropic publiceerde op 23 april 2026 een postmortem over 47 dagen stille regressies in Claude Code. Het hoofdframe was "evals vangen drift niet op". Het diepere frame is dat drift zich ophoopt in het gat tussen wat het team bedoelde en wat het systeem feitelijk deed.

Elk team dat AI-ondersteunde ontwikkeling gebruikt, heeft zijn eigen venster van 47 dagen momenteel open. De meeste teams ontdekken het pas in een postmortem.

Waarom reviews en evals het niet kunnen opvangen

Reviewtools beantwoorden de vraag: "deed de code wat de spec zei?" Eval-suites beantwoorden: "gedroeg het model zich zoals de eval verwachtte?" Beide zijn correcte, smalle vragen. Beide behandelen de spec en de eval als grondwaarheid.

Intent debt ontstaat op de laag daarboven. De kosten zitten in het gat tussen wat de klant nodig had, wat de briefing zei en wat de spec vastlegde. Tegen de tijd dat de code voor een reviewtool belandt, heeft de spec de intent al vergrendeld. De reviewer kan geen specdefect opvangen; die kan alleen implementatiedefecten markeren ten opzichte van een gebrekkige spec.

Dit heeft dezelfde vorm als Anthropics drift. Het Claude Code-team had evals. De evals slaagden.

De drift zat in wat de evals maten ten opzichte van wat gebruikers werkelijk ervaarden. Zevenenveertig dagen groen licht, terwijl echte gebruikers elke dag een regressie troffen. De oplossing is nauwere feedback tussen de mensen die bepalen wat er gemeten wordt en de mensen die het productiesignaal volgen.

Review-knelpuntdenken behandelt dit als een toolingprobleem. Het is een laagprobleem. Combineer dit artikel met het eerdere stuk over waarom AI-gegenereerde software nog steeds engineeringreview nodig heeft voor de bouwlaaghelft van het argument. Intent debt aflossen vereist een andere vraag, eerder in het proces.

De beslissingslaag comprimeert niet zoals code dat doet

Tans formulering voor waarom dit structureel is: "u levert de smaak terwijl u met de agent praat". De agent levert volledigheid. De mens levert richting en oordeel. Smaak loopt niet op dezelfde compressiecurve als code.

Drie componenten van smaak die codegeneratie niet kan vervangen.

Het juiste probleem kiezen

Alex Vacca's services-as-software-these, gepubliceerd via Sequoia-partner Julien Bek in april 2026, formuleert de bredere versie hiervan. Softwareleveranciers die het gereedschap verkopen, racen het model voor altijd achterna. Bedrijven die het werk bezitten en het model gebruiken om het te leveren, verbeteren elke keer als het model verbetert.

Dezelfde logica geldt intern in teams. Engineers die het juiste probleem kiezen, verbeteren elke keer als het model verbetert. Engineers die alleen uitvoeren op doorgegeven specs worden van de ene op de andere dag inwisselbaar.

Weten wanneer te stoppen

AI-tools zeggen nooit dat u moet stoppen. Een LLM benadert de zeventiende invalshoek op hetzelfde probleem met evenveel enthousiasme als de eerste, en elke reactie voelt als vooruitgang. Zonder een externe stopconditie loopt de cyclus eindeloos door.

Ervaren engineers legden vroeger de stopconditie op door verveeld te raken of geen tijd meer te hebben. Beide budgetten zijn nu onbeperkt. De stopconditie moet expliciet vooraf worden vastgesteld, vóór de eerste prompt.

De tegenspraak die senior engineers leveren

De moeilijkste first-party bijdrage van een senior engineer is de tegenspraak: het bericht "dit is het verkeerde ding om te bouwen" dat een kwartaal aan uitvoering afwendt. AI-agents spreken niet tegen. Ze bouwen wat u vraagt, volledig, op een compressiecurve van 100x.

U levert wat u vroeg, en pas later beseft u dat u het verkeerde heeft gevraagd.

Vier aanpakken om intent debt af te lossen

Dit zijn tactische maatregelen. Ze gaan ervan uit dat uw team het probleem al heeft benoemd en gestopt is met het proberen op te vangen op de reviewlaag.

Pre-sell voordat u de editor opent

Dit is de aanpak die op de harde manier opnieuw is geleerd. Bouwt u iets voor iemand anders dan uzelf, verkrijg dan een mondelinge toezegging, een aanbetaling of een intentieverklaring voordat een agent ook maar één regel schrijft.

Mondelijk enthousiasme, lanceringsupvotes en een wachtlijst zonder inzet zijn zwakke vraagssignalen. De bouwkosten zijn zo laag dat het enige filter dat overblijft is of de klant wil betalen.

Behandel de spec als het duurzame artefact

Voor AI was de spec een werkdocument en de code het artefact. Na AI is de code regenereerbaar en de spec het duurzame gegeven.

Schrijf specs die expliciet de klant, de faalopties en de succesmaatstaf benoemen. Sla ze op onder versiebeheer naast de code. Wanneer de spec verandert, is de regeneratie triviaal; wanneer de spec onjuist is, redt geen enkele regeneratie u.

Voer een twee-model beslissingsreview uit

Één LLM kan elke richting rationaliseren; een tweede model dat uitgenodigd wordt om te bekritiseren vangt de helft van de slechte beslissingen op. Het patroon werkt voor codereview, waarbij Claude plus Codex plus Gemini kruislings worden ingezet bij elke geshipte feature.

Het hogere-waarde gebruik is beslissingsreview. Presenteer twee modellen de spec, vraag ze het oneens te zijn, en weeg de onenigheid af voordat u begint te bouwen. De kosten zijn verwaarloosbaar vergeleken met het bouwen van het verkeerde ding.

Houd een bestand bij van gedode richtingen

Elk product, elke feature of campagne die u vóór het shippen heeft stopgezet, komt in één document met de reden. De reden is belangrijker dan het aantal. Lees het door voordat u iets nieuws begint.

Het patroon van waarom richtingen sterven is de goedkoopste terugbetaling van intent debt die beschikbaar is, en vrijwel elk team slaat het over. Wilt u beoordelen waar u deze aanpakken in uw team kunt toepassen, webvise kan helpen.

Een webpartner kiezen in het AI-tijdperk

De duurste fout die een AI-tijdperkteam maakt, is het inhuren van een bureau dat alleen de bouwlaag bezit. Bouwen is nu het goedkope deel. De beslissingslaag (wat te shippen, wanneer te stoppen, wie de gebruiker werkelijk is) is waar de vermenigvuldiger zit.

De meeste bureaus prijzen nog steeds het bouwwerk, omdat dat het enige is wat hun margemodel kent. webvise is gebouwd rondom de inversie.

De AI-automatisering en full-stack-applicatie-trajecten beginnen met een discoverysprint die een geschreven spec, een lijst van gedode richtingen en een twee-model beslissingsreview oplevert voor elk vastgelegd scope-item. Een feature kan in een dag worden geshipt, maar dat gebeurt pas wanneer het team het eens is over hoe succes er in productie uitziet.

Heeft u dit kwartaal meer code geshipt dan ooit en voelt u zich verder van een werkend product dan zes maanden geleden, plan een discoverygesprek. De snelste manier om intent debt af te lossen is stoppen met het verder opbouwen ervan.