De agentic coding ladder is een lijst van wat je opgeeft: de governance-les voor de publieke sector

Steve Yegge heeft een raamwerk dat blijft terugkomen: acht niveaus van AI-ondersteunde ontwikkeling, van "geen AI" tot "bouw je eigen orchestrator". Het leest de klim af aan vertrouwen: hoeveel van de machine's output accepteer je zonder te kijken. Permissies aan, permissies uit, stoppen met diffs lezen, de IDE verlaten, een fleet draaien. Het is een goede manier om te bepalen waar je staat.

Jed Arden (The agentic coding ladder is a list of things you give up) richt een tweede instrument op dezelfde berg. De klim zelf, zegt hij, heeft een stiller mechanisme onder het groeiende vertrouwen: een renunciatie. Om een trede te beklimmen moest hij iets opgeven dat hij als zijn werk behandelde, niet alleen de machine meer vertrouwen maar minder doen van het ding waar hij trots op was. Dus: niet "hoeveel vertrouw je het?" maar "wat heb je opgegeven?"

Beide lezingen zijn waar, maar voor de publieke sector vertelt de tweede meer over wat er écht verandert. En dat is de kern van dit artikel: elke trede van de ladder is een assurance die je verliest, en de governance-vraag is wat die verloren assurance moet opvangen. Een codeermodel dat je niet meer leest is geen persoonlijke comfortzone, het is een audit- en aansprakelijkheidsbeslissing.

De ladder, formeel

Laat een trede T(n) gekarakteriseerd worden door twee functies:

• vertrouwen v(T(n)): de hoeveelheid machine-output die je accepteert zonder menselijke inspectie, monotoon stijgend in n.
• renunciatie r(T(n)): het object (vaardigheid, gewoonte, aanwezigheid) dat je op deze trede opgeeft, monotoon "zwaarder" in n.

De stelling van Arden is dat v en r twee instrumenten op dezelfde berg zijn, maar dat r meer zegt over de klimmer: v meet wat je accepteert, r meet wat je verliest. De ladder heeft twee helften en twee drempels.

Eerste helft: je geeft de code op. De eenheid die je overdraagt groeit. Een snippet, dan een functie, dan een bestand, dan een hele applicatie. Je schrijft nog steeds, maar steeds meer de intentie en steeds minder de code.

1. De Student: "Ik vraag het de error uit te leggen, maar zou nooit zijn code ongelezen plakken." Opgegeven: Google / Stack Overflow.
2. De Lener: "Ik plak zijn snippets, maar ik assembleer het programma." Opgegeven: boilerplate met de hand schrijven.
3. De Reviewer: "Het schrijft functies in mijn codebase, maar ik lees elke diff voordat hij landt." Opgegeven: de auteur zijn.
4. De Delegerende: "Ik laat het een heel bestand schrijven en ik test de output in plaats van elke regel te lezen." Opgegeven: elke regel lezen.
5. De Regisseur: "Ik schrijf de spec; ik beoordeel de app op of hij draait, niet op hoe hij gebouwd is." Opgegeven: weten hoe je eigen code van binnen werkt.

Drempel 1: je stopt met code schrijven. Boven deze lijn is er geen kleinere eenheid meer om over te dragen.

Tweede helft: je geeft je aanwezigheid op. De as klapt om. Je hebt geen grotere stukken code meer om te delegeren, dus wat groeit is je afstand tot het werk.

6. De Jongleur: "Ik heb twee of drie sessies en ik wip ertussen." Opgegeven: onverdeelde focus.
7. De Bottleneck: "Ik verlies bij welke sessie wat doet. Ik ben nu de beperking, niet het model." Opgegeven: het geloof dat aandacht schaalt.
8. De Dispatcher: "Ik start runs waar ik niet in zit en lees daarna de log; ze kunnen me niets meer vragen." Opgegeven: bereikbaar zijn.
9. De Operator: "Het volume betekent dat ik geen enkele individuele run kan inspecteren; ik leef op dashboards, gates en kosten." Opgegeven: de optie om een individuele run te inspecteren.

Drempel 2, de belangrijkste: het gesprek wordt een dispatch. Je stopt met sessies openen en begint jobs te lanceren. De agent kan je niet meer bereiken, dus kan hij je niet meer de vraag stellen die hem vroeger redde. Arden noemt dit dezelfde lijn als pets versus cattle: een live CLI is een gesprek (het raakt ambiguïteit, vraagt, jij antwoordt), headless is een dispatch (het raakt ambiguïteit en moet het alleen oplossen of falen, want jij bent weg).

De renunciatie-test

De kern van het raamwerk is een streng criterium: zoek niet je trede, zoek je band.

Lees van trede 1 omhoog. Elke trede noemt iets dat je hebt opgegeven. Blijf klimmen zolang de renunciatie echt en permanent waar is van jou, niet "ik zou kunnen", maar "ik heb". De eerste trede waarvan je de renunciatie niet echt hebt gemaakt, waar je eerlijk zou zeggen "nee, dat doe ik nog", is je plafond. Je woont op de trede eronder.

Dat is streng met opzet. De infrastructuur voor een trede bezitten zet je er niet op. Arden: "Ik heb een fleet-orchestrator gebouwd; ik kan trede 9 elke middag bereiken. Maar ik heb niet opgegeven om in individuele runs te duiken; ik doe dat nog steeds, constant, dus ik woon niet op 9. Ik woon lager en reik hoger." Niemand staat op één trede; de renunciatie-test houdt je alleen eerlijk over welke.

Hoger is niet beter, het is zwaarder

Een ladder nodigt uit om hem als ranking te lezen: kom bovenaan. Deze niet. Elke trede hoger koopt capability, maar voegt ook overhead toe: specificatie, planning, scaffolding, verificatie. Die overhead betaalt zich alleen terug boven een bepaalde taakgrootte. Dus elke trede heeft een break-even: het kleinste stuk werk dat de moeite waard is om erheen te brengen, en die break-even stijgt naarmate je klimt.

Arden draait headless fleets, maar zou er nooit een op een one-line typo richten. Die fix zo goed specificeren voor een worker die niets kan vragen, en dan wachten op orchestration en gates om het te bevestigen, kost meer dan het bestand openen en het karakter zelf typen op trede 3. Het is een goederentrein charteren om een brief te sturen.

De vaardigheid die de ladder bovenaan beloont is dus niet hoog wonen. Het is per taak de trede kiezen, en eerlijk blijven dat veel werk klein is en klein werk op een lage trede hoort. Het meest geavanceerde wat je met alle negen treden kunt doen, is de goedkoopste kiezen die de klus nog klaart.

Sommige mensen slaan treden over

Hier volgt de ongemakkelijke omkering: omdat de ladder in renunciaties meet in plaats van vaardigheid, kan een trede je alleen vertragen als je de gewoonte hebt die hij vraagt op te geven.

Iemand die van dag één met agents bouwde, heeft die gewoonte niet. Hij heeft nooit een functie alleen ge-auteurd, nooit de reflex gevormd om elke regel te lezen, nooit de zoekbalk-spier gebouwd, nooit zijn zelfbeeld gekoppeld aan weten hoe de internals werken. Hij beklímt treden 1 tot 5 niet zozeer, hij start erboven: er is simpelweg niets om te ontleren.

Dat is de kerninversie van het raamwerk: senioriteit is frictie. Hoe meer ervaring, hoe meer je gehecht bent aan precies de dingen die elke trede vereist dat je loslaat. De ladder straft de veteraan en wuift de nieuwkomer door.

Maar een trede overslaan is niet hetzelfde als hem verdienen. Het opgeven was nooit alleen verlies; elke overgave was ook waar je het oordeel opbouwde om de volgende te overleven. De veteraan die het auteurschap opgeeft weet nog steeds wat goede code is, omdat twintig jaar elke diff lezen is hoe hij het leerde. De nieuwkomer die nooit auteurd, kan een app regisseren die hij geen enkele manier heeft om te evalueren. De vloer wordt bepaald door gehechtheid, niet door vaardigheid.

Boven trede 9: de mist

Er is een trede boven 9, en Arden weigert te benoemen wat het is. Dat is geen ontwijking, het is de meest rigoureuze claim op de pagina. Kijk naar het patroon: elke trede geeft iets op dat de trede eronder als niet-onderhandelbaar beschouwde. Vraag de Reviewer op trede 3 om zich voor te stellen de diff niet meer te lezen en hij zegt dat dat de hele baan is. Vraag de Bottleneck op trede 7 om zich onbereikbaar voor te stellen en hij kan het niet eens parsen. Vanuit elke trede is de volgende overgave onzichtbaar, omdat je nog op het ding staat dat je gaat opgeven.

Trede 10 is dus gedefinieerd door zijn vorm, niet zijn inhoud: het is wat op trede 9 nog load-bearing voelt, het ding dat je het hardst zou weerstaan om op te geven. Een kandidaat kwalificeert alleen als niveau 10 als hij, staande op 9, nog onmisbaar voelt. "Fleets die hun eigen werk toewijzen" of "fleets die zichzelf tunen" zijn het niet, want die kan hij zich al voorstellen. Het is misschien menselijke intentie aan de wortel van het werk, menselijke aansprakelijkheid voor de output, of de mens als degene die nog beslist wat "goed" betekent. Hij wil het niet noemen, want als hij het correct kon benoemen, zou het geen 10 zijn.

De governance-translatie: wat de publieke sector op elke trede opgeeft

Hier wordt de ladder voor de Nederlandse overheid concreet. Arden beschrijft een individuele klim; voor een georganiseerde publieke sector is elke trede niet een persoonlijke keuze maar een assurance-profiel dat je verliest zonder het expliciet te beslissen.

• Trede 3 (auteurschap opgeven) is waar de code in je repository niet meer door een mens is geschreven. Voor een auditor is dat een provenance-verandering: de vraag "wie heeft dit geschreven?" wordt "welke prompt, welke agent, welk model, welke dataset?". Zonder provenance-integriteit in agentic workflows is die vraag niet beantwoordbaar.
• Trede 5 (weten hoe je eigen code werkt opgeven) raakt direct de governed AI-assisted engineering: als je niet meer weet hoe het werkt, kan de review-laag niet langer op inhoudelijke kennis vertrouwen en moet ze op gedwongen menselijke oversight overschakelen.
• Drempel 2 (het gesprek wordt een dispatch) is de kritieke governance-crossing. Zodra de agent je niets meer kan vragen, verdwijnt de laatste ingebouwde human-in-the-loop. Alle controles die eerder impliciet waren (de agent vraagt bij ambiguïteit) moeten nu expliciet geconstrueerd worden. Dit is precies de agentic delivery control plane: verifieerbare gates die de afwezige mens vervangen.
• Trede 9 (individuele run inspecteren opgeven) is waar je alleen nog op aggregaten leeft: fleet metrics, verificatie-gates, kosten. Voor de publieke sector is dat een aansprakelijkheidsdrempel: je stopt met kijken naar individuele runs en leeft op het kuddeniveau. Dat vereist een governance-raamwerk voor autonomieniveaus dat bepaalt welke trede acceptabel is per taakklasse.

De diepere les is de renunciatie-test zelf, vertaald naar organisatieniveau. Een overheidsorganisatie "woont" niet op de trede die haar tooling technisch bereikt, maar op de trede waarvan ze de renunciatie daadwerkelijk heeft gemaakt. Heeft ze opgegeven om de output te inspecteren? Heeft ze opgegeven dat de agent haar om bevestiging vraagt? Heeft ze opgegeven om individuele runs te kunnen auditen? Het antwoord bepaalt haar daadwerkelijke positie, niet de aangeschafte orchestrator.

En net als in Ardens raamwerk geldt: hoger is niet beter, het is zwaarder. Voor de publieke sector is de overhead van elke hogere trede (specificatie, planning, verificatie, audit-trails, assurance-gates) niet alleen technisch maar ook juridisch. De break-even van een trede is het kleinste stuk werk dat de extra governance-kosten waard is. De vaardigheid die de overheid nodig heeft is niet "zo hoog mogelijk klimmen", maar per taakklasse de laagste trede kiezen die de governance-verplichting nog klaart. Een eenmalige configuratiefix op een laag risico systeem op trede 8 of 9 brengen is een goederentrein charteren om een brief te sturen, met aansprakelijkheid erbovenop.

De afsluitende les

De agentic coding ladder van Arden is waardevol voor de publieke sector precies omdat hij niet meet wat je wint maar wat je opgeeft. In de overheid is elke trede een assurance die je verliest zonder expliciete beslissing: auteurschap, inhoudelijke review, de menselijke vraag, individuele auditbaarheid. En die verloren assurance moet ergens door worden opgevangen, of je nu de opencode-versus-claude-code keuze maakt, een control plane bouwt, of een benchmark-laag overlegt om agentic coding meetbaar te maken.

Wat boven trede 9 in de mist ligt, is voor de overheid geen speculatieve futuristische trede, maar een governance-vraag die al besloten wordt door elke organisatie die stilzwijgend een trede hoger klimt zonder de renunciatie expliciet te maken. De trede waarop je woont is niet je ambitie, maar wat je daadwerkelijk hebt opgegeven. En de meest geavanceerde governance is niet alles automatiseren, maar per taak de laagste trede kiezen die de aansprakelijkheid nog klaart.

Gerelateerd: governed AI-assisted engineering met gedwongen menselijke oversight, de agentic delivery control plane, provenance-integriteit in agentic workflows, en OpenEnv als agentic RL-infrastructuur.