Het eerste is een cijfer. De werkgelegenheid onder jonge software developers daalt al 33 maanden op rij. Je vindt het in vrijwel elk stuk over het einde van de instapfunctie, meestal in de eerste alinea, meestal met een link naar Stanford eronder.

Het tweede is dat IBM in februari aankondigde dit jaar in de VS drie keer zoveel mensen op instapniveau aan te nemen. De HR-directeur zei er iets bij dat veel meer aandacht had verdiend dan het kreeg: “And yes, it’s for all these jobs that we’re being told AI can do.”

Ik ben op zoek gegaan naar die 33 maanden. Ze staan niet waar iedereen zegt dat ze staan.

Iedereen citeert een cijfer dat zo nooit is gemeten

Het spoor loopt naar het Digital Economy Lab van Stanford en het paper Canaries in the Coal Mine?, in augustus 2026 bijgewerkt met loondata van ADP tot en met juni. Het is goed werk: administratieve gegevens over miljoenen werkenden, doorlopend gepubliceerd, en ongewoon eerlijk over de eigen beperkingen.

Zoek in dat paper naar die reeks en je vindt hem niet. Geen “33 maanden op rij”, geen “oktober 2023”, geen enkele reeks op jaarbasis. Het cijfer wordt verderop in de keten in elkaar gezet uit het publieke dashboard van het lab, en krijgt daarna een etiket dat het paper er nooit op heeft geplakt.

Bij dat in elkaar zetten gaan er twee dingen verloren.

Op het etiket staat software developers. Wat er gemeten is, zijn werkenden van 22 tot 25 jaar in beroepen die sterk aan AI blootstaan, en dat is een veel bredere groep: klantenservicemedewerkers, administratieve functies, een lange reeks andere functies die op vastgelegde kennis draaien. De auteurs wijzen er zelf nadrukkelijk op. Haal je de computerberoepen uit de steekproef, dan is de schatting “essentially unchanged”. Haal je de techbedrijven eruit, dan is hij maar iets kleiner. Hun eigen conclusie: “our findings are not specific to technology roles.”

Het tweede verlies is statistisch. Wil je een maandreeks specifiek voor jonge software developers, dan is de publieke data daar te dun voor. In de bijlage van het paper staat dat de Current Population Survey “between 23 and 48 young software developers aged between 22 and 25 per month” bevat, met “common fluctuations of 20% or greater in estimated employment month-to-month”. Een reeks van 33 maanden die op een steekproef van dertig mensen berust, meet vooral die steekproef.

Dat maakt de daling nog niet verzonnen. De werkgelegenheid onder 22- tot 25-jarigen in de twee kwintielen die het sterkst aan AI blootstaan daalde met ongeveer 11% tussen november 2022 en juni 2026, terwijl dezelfde leeftijdsgroep in de drie minst blootgestelde kwintielen zo’n 10% groeide. Afgezet tegen een scenario waarin ze gelijk waren opgelopen, is het gat 19%. In de vorige versie van de data stond dat nog op 15%. Dat verschil is echt en het loopt nog steeds op.

De belangrijkste bevinding uit het paper is de zin die niemand als kop gebruikt: “no evidence of widespread, economy-wide job displacement from AI.”

De twee feiten die eronder liggen

Feit vier uit het paper zou het gesprek moeten veranderen. Het verschil, in hun woorden: “operates primarily through reduced hiring rather than increased separations”.

Die junior werd om te beginnen nooit aangenomen. Er kwam geen vervanging aan te pas.

Dit is een inkooporder die niet meer getekend werd, kwartaal na kwartaal, door mensen die stuk voor stuk een verdedigbare reden hadden om hem te laten liggen. Dat betoogde ik eerder vanuit de vraagkant, toen de koppen over veerkracht verschenen, en de loondata laat nu zien welk mechanisme eronder zit: een branchebrede aannamestop, vermomd als technologische onvermijdelijkheid.

Feit vijf is de andere helft. De dalingen concentreren zich in beroepen waar AI het werk overneemt. Waar AI de werkende aanvult, blijft de werkgelegenheid gelijk of stijgt hij. Die indeling komt uit de Anthropic Economic Index, vertaald naar beroepen.

De bevinding is dus preciezer en bruikbaarder dan de kop die eruit voortkwam. Overal waar de functie bestond uit het deel dat een model in zijn eentje af kan, werd hij niet meer aangeboden.

Dat roept de voor de hand liggende vraag op. Wat gebeurt er als iemand de functie opnieuw omschrijft?

Het bedrijf dat anders besloot

IBM deed dat in februari. Drie keer zoveel mensen op instapniveau in de VS in 2026, over alle afdelingen heen, in hetzelfde jaar waarin branchegenoten hun dunnere lichting afgestudeerden verklaarden met het woord “AI”.

Nickle LaMoreaux, HR-directeur bij IBM, beschreef de herziening zonder omhaal. Ze herschreef de functieomschrijvingen voor instapfuncties: “less focused on areas AI can actually automate, like coding, and more focused on people-forward areas like engaging with customers”.

De redenering erachter is het zaaigoedargument, nu doorgerekend op de balans. Snijden in je instroom scheelt vandaag geld en levert later een tekort aan middenkader op, en dan koop je ze weg bij de concurrent, trager en tegen een hogere prijs.

Voordat dit klinkt als een persbericht: dit is wat IBM niet in de aankondiging zette. Het bedrijf noemde geen baseline, dus “drie keer zoveel” is een verhouding en verder niets. Drie keer een uitgeklede lichting van 2025 kan nog altijd kleiner zijn dan die van 2019. IBM voert ondertussen het hele jaar door reorganisaties uit, op een niveau dat het bij de kwartaalcijfers van januari zelf omschreef als vergelijkbaar met het jaar ervoor. Dit is een bedrijf dat de vorm van zijn personeelsbestand verandert, dat onderin bijkoopt terwijl het in het midden snijdt, en de uitbreiding aan de onderkant is één regel in die ruil.

De redenering blijft de aandacht waard, want IBM is de enige grote werkgever die openlijk ingaat tegen een consensus die de rest als natuurkunde presenteert.

Waar de gok klopt

Leg de herziening van IBM naast het vijfde feit uit het paper en ze vallen bijna samen. De dalingen zitten waar AI het werk overneemt. IBM haalde de juniorfunctie weg bij precies dat werk en richtte hem op werk dat aanvult. Dat is de goede richting, zelfstandig gevonden, en het is meer dan wie dan ook met dezelfde data heeft gedaan.

Waar de gok mis kan gaan

Het paper heeft nog één uitkomst, weggestopt in een regressietabel, en die zou ik voorleggen aan iedereen die IBM wil nadoen.

Overname en aanvulling zijn samen afgezet tegen de verandering in werkgelegenheid, per leeftijdsgroep. Bij 22- tot 25-jarigen is alleen de coëfficiënt voor overname significant, en die is negatief. De coëfficiënt voor aanvulling is positief en significant bij werkenden van 41 tot 49 jaar, en bij vijftigplussers.

Aanvulling betaalt zich tot nu toe uit bij mensen die al iets hadden om aan te vullen.

Daar loopt de gok van IBM tegenaan. Een aanvullende rol gaat ervan uit dat het oordeelsvermogen al in huis is. De junior is juist degene die het nog niet heeft, en precies daarom werd die functie geschrapt.

Het aanvullende werk dat daadwerkelijk groeide is bovendien het werk waar een junior het minst toe in staat is. De seniortijd verdween in de reviewwachtrij: telemetrie over vierduizend teams laat zien dat de tijd tot de eerste review met 156,6% is opgelopen, met code die er “often not review-ready” binnenkomt, zodat de reviewer hem afmaakt. De output van een agent goed reviewen vraagt dat je weet wat de code had moeten doen, en dat leer je pas als laatste.

Lees de redenering van LaMoreaux daarna nog eens. Ze had het over een tekort aan middenkader.

Ze heeft daar waarschijnlijk gelijk in, en dat is een ander tekort dan het zaaigoedprobleem beschrijft. Klantgericht werk met toezicht op AI levert over vijf jaar mensen op die een team kunnen leiden en een klant aankunnen. Het levert niet vanzelf degene op die naar negenhonderd gegenereerde regels kijkt en aanwijst welke veertig fout zijn. Allebei die gaten zijn echt. Eén ervan wordt gefinancierd.

Neem je de gok over, neem dan meer over dan de aantallen

Juniors aannemen is de goedkope helft. De dure helft is wat je ze maandag laat doen.

• Zet ze als tweede lezer in de reviewwachtrij, nooit als degene die goedkeurt. Meelezen met de review van een senior op de pull request van een agent, met de diff ernaast, is op dit moment de snelste manier om oordeelsvermogen op te bouwen, en het kost die senior vrijwel niets.
• Geef ze de kleine gevaarlijke wijzigingen, met hun naam eraan. Een migratie op een testtabel, een permissiegrens, een retry die iemand dubbel kan laten betalen. Je leert het van de gevolgen, en het toezicht houdt het leergeld betaalbaar.
• Tel wat ze lezen, niet wat ze afvinken. Een junior die op gemergede pull requests wordt afgerekend, laat de agent ze schrijven. Een junior die daarnaast elke week andermans code in eigen woorden navertelt, groeit uit tot de reviewer die je nu mist.

Dat is de goedkoopste senior engineer die je ooit koopt, met een levertijd van vijf jaar. Dat is ook ongeveer de aanlooptijd van het tekort dat iedereen nu al inprijst in zijn wervingsbudget voor 2031. De helft van deze afspraak waar de junior zelf over gaat, schreef ik uit in wat een junior in plaats daarvan zou moeten leren. Dit is de helft van degene die het contract tekent.

De ingestorte instroom was nooit een oordeel over wat een junior waard is. Het was een keuze die duizenden bedrijven los van elkaar maakten: de roadmap van dit jaar woog zwaarder dan de engineers van 2031. IBM tekent de order die de rest niet meer tekent. Of daar seniors uit groeien of alleen maar personeel, hangt volledig af van wat het ze maandagochtend laat doen.

Het wordt toegeschreven aan DORA. Daar komt het niet vandaan, en van de drie reviewgetallen in het rapport waar het wél vandaan komt, is dit het minst bruikbare.

Van wie het cijfer echt is

De 441% staat in het AI Engineering Report 2026 van Faros AI, met als ondertitel The Acceleration Whiplash. Twee jaar telemetrie van 22.000 developers verspreid over ruim 4.000 teams, waarbij per organisatie de periode met de laagste AI-adoptie is afgezet tegen de eigen periode met de hoogste.

Op de pagina van DORA staat niets van dien aard. Dat is een enquête onder 1.110 respondenten. Daaruit komt dat 90% van de technologieprofessionals AI op het werk gebruikt, dat ruim 80% denkt er productiever van te worden, en dat hogere adoptie samenhangt met zowel meer doorstroom als meer instabiliteit. Prima onderzoek, en een heel ander soort bewijs. Een enquête legt vast wat developers zeggen. Telemetrie legt vast wat hun git-historie deed.

Dit reken ik mezelf aan. In mijn stuk over wanneer je werk beter zelf houdt schreef ik deze cijfers aan DORA toe, met een link naar dora.dev. Dat klopte niet en het is inmiddels rechtgezet.

Het gaat hier om meer dan muggenziften. Als je in een planningsoverleg om reviewcapaciteit vraagt, is “uit een enquête blijkt dat mensen vinden dat reviews trager gaan” iets heel anders dan “telemetrie over vierduizend teams meet een stijging van 441,5% in de mediane tijd in review”, en maar één van de twee overleeft een sceptische directeur.

Drie getallen, en het beroemdste zegt het minst

Faros splitst de review-pipeline op in drie metingen:

Iedereen citeert de derde.

De eerste is het getal dat ik voor een manager op tafel zou leggen. Tijd tot de eerste review is wachttijd in de rij. Het is de tijd tussen het openen van een pull request en het moment dat er überhaupt een mens naar kijkt. Dat getal staat helemaal los van hoe moeilijk de code leest, want op dat moment heeft nog niemand er een regel van gezien.

Een stijging van 156,6% in die wachttijd betekent dat je reviewers al overbelast zijn voordat de moeilijkheidsgraad van welke PR dan ook meespeelt. Daar helpt betere reviewtooling niet tegen. Alleen meer reviewcapaciteit of minder binnenkomend werk brengt dat getal omlaag.

Kleinere PR’s helpen, maar daar houdt het verhaal niet op

Het advies dat standaard bij de 441% hoort, is: schrijf kleinere pull requests. De gemiddelde PR-grootte is met 51,3% gestegen, dus daar zit iets in.

Lees wel even de voetnoot. Faros merkt op dat die 51,3% lager ligt dan de 154% uit hun vorige rapport, en zegt er eerlijk bij dat “the two datasets differ in size, composition, and time period, so direct comparison should be treated as directional”.

Ook als je het alleen als richting leest, wringt het met het simpele verhaal. De groei in PR-grootte lijkt af te vlakken terwijl de reviewtijd juist hard de andere kant op gaat. Er gaat dus tijd van je reviewers op aan iets anders dan het aantal regels.

De bevinding die onder de kop verdween

Faros geeft zelf een verklaring, en dat is de nuttigste zin uit het hele rapport:

the code arriving for review is often not review-ready. Reviewers are not just assessing more code, they appear to be working harder to bring that code up to a standard it should have met before the PR was opened.

Daarmee kantelt het hele probleem. De reviewwachtrij was de plek waar code werd gecontroleerd en is de plek geworden waar code wordt afgemaakt.

Het rapport benoemt ook het mechanisme. AI-code is vaak “superficially convincing: idiomatic, well-named, stylistically consistent with the surrounding codebase”. De structurele en logische fouten zitten onder dat oppervlak, en om die te vinden moet je aandachtig lezen, nadenken over de bedoeling en reconstrueren welk probleem de code moest oplossen. Faros noemt dat “slow, expensive cognitive work” en wijst aan wie het uiteindelijk doet: je senior engineers, precies de mensen die je hoopte vrij te spelen.

De rest van de cijfers volgt daaruit. Merges zonder enige review zijn met 31,3% toegenomen. Bugs per developer stegen met 54%. Het aantal incidenten per PR ging met 242,7% omhoog. En code churn, gemeten als verwijderde regels tegenover toegevoegde regels in gemergede code per kwartaal, steeg met 861%.

Bij die laatste loont het om even stil te staan. Churn van die omvang betekent dat een flink deel van wat er gemerged werd kort daarna alweer weg was, waardoor elk doorstroomcijfer in datzelfde rapport een te rooskleurig beeld geeft van wat er werkelijk bleef staan.

Wat dit verandert aan je werkwijze

Zorg dat de code review-klaar is voordat hij een pull request wordt. Dat is de conclusie van het rapport zelf en het levert hier het meeste op. Elke controle die een reviewer zou draaien, draai je eerst: de testsuite, de linter, een eigen leesronde over de volledige diff. Een agent die een PR opent zodra de code compileert, heeft het onaffe werk verplaatst naar andermans wachtrij, waar het seniortijd kost in plaats van agenttijd.

Keur het plan goed zolang dat nog goedkoop is. Beslissen wat er gebouwd wordt is ook een review, en dat doen voordat de diff bestaat kost minuten in plaats van uren. Plan mode wordt meestal verkocht als planningsfunctie, terwijl de echte winst is dat de diff al vorm heeft als hij binnenkomt en je reviewer de bedoeling niet uit 900 regels hoeft af te leiden.

Werk de wachtrij af op risico, niet op volgorde van binnenkomst. Omdat het eerste getal wachttijd is, zit de winst in welke PR als eerste wordt opgepakt. Een migratie, een wijziging in authenticatie en een permissiegrens verdienen vandaag een senior reviewer. Een dependency-bump kan wachten.

Kijk wat “gereviewd” in je eigen cijfers betekent. Als een bot opmerkingen achterlaat bij een pull request en die wordt gemerged, telt dat in de meeste dashboards als gereviewd. De bureaucratie van bots is wat je daarvan op schaal krijgt: een bot die een bot beoordeelt, met aan geen van beide kanten iemand die achteraf uitlegt waarom. Het is de moeite waard om te weten bij welke reviews er een mens aan te pas kwam. En als er wel een mens bij zit: waar je in de pull request van een agent op let is iets anders dan wat je bij een collega nakijkt.

Helemaal nieuw is het probleem niet. Je 10x-developer zit vast in een 0,1x-pipeline voerde de structurele versie van dit argument aan: code werd goedkoop, de machinerie die code in waarde omzet niet, en dus verschoof de beperking naar verderop in de keten. Faros meet nu waar die terechtkwam.

De wachtrij is inmiddels de plek waar code wordt afgemaakt. Dat werk moest sowieso ergens gebeuren. Op dit moment gebeurt het op de duurste plek die je hebt, door de mensen die je daar het minst kunt missen, en het staat geboekt als review.

Die post eindigde op een zin waar ik nog steeds achter sta: een belofte kun je niet auditen, een verbinding wel.

De voor de hand liggende vervolgvraag bleef onbeantwoord. Prima, ik heb naar de verbinding gekeken. En dan? Wat doe ik eraan dat de shell van mijn agent elk token op die machine kan lezen?

Claude Code bouwde daar in stappen een antwoord op: gemaskeerde omgevingsvariabelen sinds 2.1.199, gemaskeerde credential-bestanden sinds 2.1.221, en sinds 2.1.224 van 7 augustus de opties die het bruikbaar maken op echte waarden in plaats van op kale tokens. Alles hieronder is gecontroleerd op 2.1.231.

Het idee: je shell krijgt het geheim nooit te zien

Credential masking zit tussen twee botte opties in die je al had.

Je kon de agent GH_TOKEN laten zien en hopen. Of je zette er deny op, waarna gh niet meer werkt en de agent jou om de haverklap vraagt dingen met de hand te draaien.

Maskeren neemt van allebei de goede helft. Het commando in de sandbox ziet een sentinel: een nepwaarde die per sessie wisselt. Zodra een verzoek de sandbox verlaat richting een host die jij hebt aangewezen, wisselt de sandbox-proxy die sentinel onderweg om voor de echte credential.

Het commando authenticeert gewoon. Het commando heeft het geheim nooit vastgehouden. Wat het ook logt, in een transcript echoot of per ongeluk op een pastebin zet: daar staat de sentinel in.

Dit is het minimum dat werkt:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "tlsTerminate": {},
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    },
    "credentials": {
      "envVars": [
        { "name": "GH_TOKEN", "mode": "mask", "injectHosts": ["api.github.com"] },
        { "name": "NPM_TOKEN", "mode": "mask" }
      ]
    }
  }
}

injectHosts is het onderdeel dat je goed moet zetten. GH_TOKEN wordt alleen omgewisseld op verzoeken naar api.github.com. NPM_TOKEN heeft geen injectHosts en gaat dus naar élke host in allowedDomains, en dat is makkelijker dan verstandig. Alles wat in injectHosts staat, moet ook onder allowedDomains vallen.

tlsTerminate is niet optioneel. De proxy moet in het verzoek kunnen kijken om iets te kunnen omwisselen, en dus moet hij TLS zelf termineren.

Laat je het weg, dan krijg je dit bij het opstarten. Ik heb het expres uitgelokt om de formulering te controleren:

⚠ sandbox.credentials mask entries (DEMO_TOKEN) are configured but TLS
termination is unavailable — sandboxed commands see only a sentinel value
and the proxy cannot substitute the real credential on egress, so tools
needing these will fail to authenticate.

Lees die faalmodus goed, want het is de goede soort. Zet je dit verkeerd, dan komt de sentinel ongewijzigd bij de server aan. Je build breekt. Je geheim lekt niet. In die volgorde.

Waarden met structuur

De hele waarde vervangen past bij een kaal token. Lang niet elke credential is een kaal token.

extract neemt een reguliere expressie en vervangt alleen wat groep 1 vangt, zodat de rest van de waarde overeind blijft:

{ "name": "DATABASE_URL", "mode": "mask", "extract": "://[^:]+:([^@]+)@" }

Het proces in de sandbox krijgt nu een connection string die het gewoon kan parsen, met een echte host, poort en databasenaam. Alleen het wachtwoord is een placeholder.

Combineer dat met onExtractNoMatch, dat bepaalt wat er gebeurt als het patroon niets vindt. De standaard is warn, en die standaard laat de variabele ongemaskeerd door. Dat is de verkeerde keuze voor alles wat ertoe doet. Als het geheim er zou kunnen staan en je patroon het zou kunnen missen, zet dan deny zodat de variabele in de sandbox helemaal niet bestaat, of error om het opzetten van de sandbox te blokkeren tot je het hebt rechtgezet.

Voor een JWT gebruik je decode. Dat laat zich niet combineren met extract:

{
  "name": "SERVICE_JWT",
  "mode": "mask",
  "decode": "jwt",
  "maskClaims": ["sub", "email"],
  "injectHosts": ["api.internal.example.com"]
}

Claude Code controleert eerst of de waarde echt een JWT is en geeft de sandbox een structureel geldige nepversie, zodat code die het token uitleest blijft werken in plaats van een error te geven. Met maskClaims maak je het fijnmaziger: maskeer de claims die een mens identificeren en laat iss en exp leesbaar, zodat je debugsessie nog ergens op slaat.

AWS, en de drie verzoeken die je niet opnieuw kunt ondertekenen

AWS is het lastige geval, want een SigV4-verzoek is ondertekend over zijn eigen inhoud. Een sleutel omwisselen in een ondertekend verzoek levert een verzoek met een kapotte handtekening op.

De proxy lost dat op door het verzoek te herkennen aan de sentinel van de access key, en ondertekent het na de omwisseling opnieuw. Dat betekent dat je AWS_ACCESS_KEY_ID en AWS_SECRET_ACCESS_KEY samen moet maskeren. Maskeer je alleen de secret, dan herkent de proxy het verzoek helemaal niet, gaat het met een placeholder ondertekend naar AWS en sneuvelt het daar.

De gebruikelijke variabelenamen worden automatisch aan elkaar gekoppeld. Eigen namen koppel je met awsPairs:

{
  "sandbox": {
    "credentials": {
      "awsPairs": [
        {
          "accessKeyIdVar": "MY_KEY_ID",
          "secretAccessKeyVar": "MY_SECRET_KEY",
          "sessionTokenVar": "MY_SESSION_TOKEN"
        }
      ]
    }
  }
}

Drie soorten verzoeken dragen een handtekening die de proxy niet kan herberekenen: aws-chunked streaming uploads, presigned URL’s en asymmetrische SigV4A-handtekeningen. Standaard stranden die bij de proxy in plaats van kapot naar buiten te gaan. Met de instelling sigv4 versoepel je dat per soort via passthrough: het verzoek gaat alsnog de deur uit, zodat de tool die het verzoek doet de afwijzing van AWS zelf terugkrijgt in plaats van een proxyfout. Gebruik het om de echte foutmelding te zien, en repareer daarna je config.

Je repo kan dit niet aanzetten

Dit is de ontwerpkeuze die ik het mooiste vind, en meteen degene die je beter kunt testen dan geloven.

Maskeren geeft de proxy toestemming om je echte credential naar hosts te sturen die in een configbestand staan. Een configbestand is nu juist het soort ding dat binnenkomt als je iets cloont. Daarom worden mask-regels, tlsTerminate en awsPairs alleen gehonoreerd vanuit user settings, managed settings en de --settings-vlag. De .claude/settings.json van een repository wordt genegeerd.

Ik heb het gecontroleerd in plaats van aangenomen. Ik zette identieke mask-regels in twee scopes en draaide ze in één sessie: DEMO_TOKEN via --settings, PROJ_TOKEN via de .claude/settings.json van het project. De opstartwaarschuwing noemde alleen DEMO_TOKEN. De regel uit de repo verdween zonder een woord.

Geruisloos, en dat is het weten waard. Een collega die dit in de projectconfig zet krijgt geen foutmelding, alleen een masker dat er nooit komt.

Het is dezelfde grens die ik natrok bij wat een repo wel en niet kan afdwingen aan permissies: een repository mag altijd inperken wat een agent mag, en nooit oprekken.

Wat dit je niet oplevert

Drie grenzen, en die schrijf ik op, want een maatregel die je verkeerd begrijpt is erger dan een die je overslaat.

Het wisselt credentials om, en verder niets. Wat er nog meer in dat verzoek meelift, blijft ongezien. Alles waar ik me druk om maakte bij de Grok-capture geldt onverkort: besluit een client jouw repository naar een toegestane host te uploaden, dan kijkt het masker toe. Dit dicht het gat van je .env-bestand. Het gat van de upload dicht het niet.

Je termineert nu je eigen TLS. tlsTerminate staat nog als experimenteel aangemerkt, en aanzetten betekent dat er een onderscheppende proxy in je lus zit met echte credentials in het geheugen. Dat is een verdedigbare ruil tegenover een shell vol levende tokens, en het blijft een ruil. De proxy is nu het onderdeel dat vertrouwen verdient.

De allowlist eronder is al een keer bezweken. Maskeren leunt op de sandbox-proxy, en de hostnaam-allowlist van die proxy had vijfeneenhalve maand lang een parserverschil in zich. Aonan Guan liet zien dat een hostnaam als attacker-host.com\x00.google.com langs de JavaScript-controle met endsWith() glipte en daarna ergens heel anders uitkwam, omdat getaddrinfo() uit libc stopt met lezen bij de nulbyte. Elke release van v2.0.24 tot en met v2.1.89 was kwetsbaar, stilletjes gerepareerd in v2.1.90 op 1 april, zonder CVE tegen Claude Code zelf. Zijn eigen conclusie is de juiste bril voor alles hierboven: behandel de sandbox van je leverancier als een extra laag, en leg je echte uitgaande filtering op netwerk- of hypervisorniveau, buiten het bereik van de agent.

Nog een praktisch puntje voor Linux en WSL2, dat mij tien minuten verwarring kostte: de sandbox heeft naast bubblewrap ook socat nodig, en zonder dat pakket draait Claude Code je commando’s stilletjes buiten de sandbox, met een waarschuwing bovenaan de sessie. Draai /sandbox en lees het tabblad Dependencies voordat je aanneemt dat hier ook maar iets van actief is. De sandbox zelf moet staan voordat maskeren iets betekent.

Die capture in juli werkte omdat één iemand de client genoeg wantrouwde om de bytes te lezen. Dit is de eerste maatregel die ik zie die de bytes met opzet saai maakt: laat de agent werken, laat het verzoek authenticeren, en zorg dat wat de moeite van het stelen waard is, daar nooit ligt.

Stel het in, en ga daarna alsnog naar de verbinding kijken.

Die scheiding is nooit een besluit geweest. De helft van mijn setup die de agent iets leert, is gedeeld. De helft die de agent iets toestaat, bleef op één machine staan en groeide daar verder, één “ja, niet meer vragen” tegelijk.

Die scheiding blijkt niet aan mijn slordigheid te liggen. Zo zit het systeem in elkaar. Een repo kan alles delen wat de agent beperkt. Alles wat de agent iets toestaat, kan een repo hooguit voorstellen. Zodra je die grens ziet, ben je in een minuut of tien klaar met beslissen wat je voor vijf ontwikkelaars commit.

Wat je in de repo kwijt kunt

Vier dingen gaan mee in versiebeheer, en ze gedragen zich verschillend zodra ze op een andere machine terechtkomen:

Skills zijn de makkelijke winst, en meteen de reden dat mijn repo zo scheefgegroeid is. Zet een SKILL.md in .claude/skills/, commit hem, en elke collega heeft jouw /consolidation-pass de volgende sessie tot zijn beschikking, zonder ook maar één installatiestap. Wil je hem kunnen versioneren en in meerdere repo’s hergebruiken, dan bouw je hem later om tot plugin, en ruil je die installatie zonder gedoe in voor een marketplace-entry en een installatiecommando per ontwikkelaar. Begin standalone.

Die scheiding loopt dwars door één enkel skill-bestand heen, en daar staat de regel het duidelijkst in de documentatie. De instructies van een gecommitte skill laden bij iedereen. De allowed-tools-regel in de frontmatter, die de skill git laat draaien zonder tussendoor te vragen, werkt pas nadat die ontwikkelaar de map vertrouwt, net als de permissieregels in .claude/settings.json. Het advies van Anthropic op diezelfde pagina is om de skills van een project te lezen voordat je een repo vertrouwt, want een skill kan zichzelf brede toegang toekennen. Wat de agent leert, reist mee. Wat hij mag, wacht.

Bij de andere drie rijen in die tabel lopen teams tegen verrassingen aan.

De volgorde staat precies verkeerd om

Claude Code bepaalt zijn settings in deze volgorde, hoogste eerst:

1. Managed settings (/etc/claude-code/managed-settings.json op Linux en WSL)
2. Argumenten op de commandoregel
3. .claude/settings.local.json
4. .claude/settings.json
5. ~/.claude/settings.json

Lees drie en vier nog eens. Bij elke instelling met één waarde wint het persoonlijke bestand dat je niet kunt inzien van het teambestand dat jullie in een PR hebben doorgenomen. defaultMode is degene waar je het merkt: commit plan voor het team, en de lokale acceptEdits van je collega wint stilletjes op zijn machine, zonder dat de repo daar iets van laat zien.

Permissieregels zijn de uitzondering, en die uitzondering pakt goed voor je uit. Ze worden over de scopes heen samengevoegd in plaats van vervangen, en daarna loopt de deny-eerst-volgorde over die samengevoegde set. Een lokale Bash(*) van je collega haalt dus geen deny weg die jij hebt gecommit, hij verruimt alleen wat die collega zelf mag. Toestemmingen stapelen zich per persoon op. Beperkingen overleven het samenvoegen.

Er is één laag die boven de discussie staat, en die zit met opzet niet in je repo: managed settings, een bestand dat root beheert op een vast systeempad, uitgerold via MDM of Ansible. Daar houdt disableBypassPermissionsMode op een voorkeur te zijn waar iemand zichzelf omheen praat. Al het andere wat je in .claude/settings.json zet, is een stevige standaardwaarde, en een standaardwaarde houdt het precies zo lang vol als de minst geduldige collega toelaat.

Toestaan wacht, verbieden niet

Dit is de asymmetrie die de handleidingen overslaan. permissions.allow-regels en additionalDirectories in de .claude/settings.json van een project geven de agent iets extra’s, en daarom past Claude Code ze pas toe nadat die ontwikkelaar de workspace trust-dialoog voor die map heeft geaccepteerd. Tot die tijd leest hij ze in en doet er niets mee. Bij deny en ask speelt dat niet, want die perken alleen in.

De allowlist die je hebt gecommit om je team van promptmoeheid te redden, doet in een net gekloonde repo dus niets tot iedereen ja zegt tegen een dialoog die precies opsomt wat de map wil toestaan. De denylist die je hebt gecommit om .env-bestanden uit de context te houden, werkt vanaf de eerste sessie, bij iedereen, geruisloos en correct.

Die ene regel verklaart de rest van de verrassingen:

• Een gekloonde repo kan zijn eigen MCP-servers niet goedkeuren. Zet enableAllProjectMcpServers in je projectsettings en hij wordt genegeerd zolang de map niet vertrouwd is. De server blijft op ⏸ Pending approval staan tot iemand daar claude draait en ja zegt.
• Teamplugins vragen ook. Met extraKnownMarketplaces en enabledPlugins in .claude/settings.json krijgen je collega’s de marketplace aangeboden zodra ze de map vertrouwen. Zet alleen het project een plugin uit een externe bron aan, dan laadt die pas als ze hem zelf installeren.
• Een gecommitte externe import krijgt één kans. Importeert je CLAUDE.md iets van buiten de werkmap, bijvoorbeeld @~/.claude/standards.md, dan verschijnt de eerste sessie een goedkeuringsdialoog. Wijs je die af, dan blijven de imports uit staan en komt de dialoog nooit meer terug. Geen waarschuwing, geen tweede kans, en de collega die afwees leest sindsdien een kortere CLAUDE.md dan jij.

En dan het echte addertje: in -p-modus, dus zonder interactie, verschijnt er geen dialoog en blijven de regels genegeerd. Je zorgvuldig beoordeelde allowlist doet in CI helemaal niets, permanent, zonder één regel output die dat verraadt. Wat je pipeline mag doen, moet uit managed settings komen, uit --settings, of uit de flags op het commando zelf.

De gitignore die in je home-directory staat

Als Claude Code een instelling wegschrijft naar .claude/settings.local.json in een repo die dat bestand nog niet negeert, zet hij **/.claude/settings.local.json in je globale git excludes. Ik heb het tijdens het schrijven even bij mezelf nagekeken: die regel staat in ~/.config/git/ignore, en de .gitignore van dit project heeft nog nooit van dat bestand gehoord.

Daar volgen twee dingen uit. Een collega die het bestand met de hand aanmaakt, of het door de agent met de Write-tool laat schrijven, heeft die uitzondering helemaal niet, en zo belandt een persoonlijke allowlist van 354 regels in een PR. En als het bestand ooit toch gecommit wordt, zijn de allow-regels niet langer privé: het bestand kan dan uit de repo zijn gekomen, dus vallen ze onder dezelfde trust-controle als gewone projectsettings.

Zet .claude/settings.local.json in de .gitignore van de repo zelf. Het kost één regel, en dan hangt het niet langer af van wat elke ontwikkelaar toevallig in zijn home-directory heeft staan.

Het geheugen dat niemand deelt

“Eén CLAUDE.md, vijf ontwikkelaars” heeft een verborgen tweede helft, want Claude Code heeft twee geheugensystemen en je kunt er maar één van committen.

CLAUDE.md schrijf jij zelf, hij laadt elke sessie en gaat mee in git. Het automatische geheugen schrijft Claude, het staat in ~/.claude/projects/<project>/memory/, hangt aan de git-repo en blijft op die ene machine. Het wordt nooit tussen machines gedeeld, dus vijf ontwikkelaars op één repo hebben vijf privé-geheugens die maandenlang stilletjes uit elkaar groeien.

Dat is het echte antwoord op de vraag waarom de agent van je collega dat ene rare buildprobleem kent dat de jouwe elke week opnieuw ontdekt. Die kennis is in een bestand terechtgekomen dat jou nooit zou bereiken. Blijkt zoiets algemeen te gelden, dan moet je het met de hand doorschuiven naar CLAUDE.md, en dat is meteen de enige versie die iemand kan beoordelen. Verouderde regels zijn erger dan geen regels zodra vijf mensen erop varen.

CLAUDE.md is context, geen configuratie

Anthropic zegt het zelf onomwonden in de documentatie: CLAUDE.md wordt als gebruikersbericht aangeleverd, Claude leest het en probeert het te volgen, en er is geen garantie dat hij het doet. Het stuurt gedrag, en het afdwingen gebeurt in de andere lagen.

Een gedeelde CLAUDE.md faalt daarmee op de gewone manier waarop gedeelde documenten falen: hij wordt lang. Houd hem onder de 200 regels, want langere bestanden vreten context en de naleving zakt. In een repo met vijf mensen zit je zo tegen dat plafond aan, want iedereen wil zijn eigen onderwerp terugzien in het bestand dat elke sessie meelaadt.

.claude/rules/ is de oplossing die je beter vroeg dan laat invoert. Eén onderwerp per bestand, en met een paths:-blok in de frontmatter beperk je een regel tot de bestanden waar hij echt over gaat:

---
paths:
  - 'src/api/**/*.ts'
---

# API rules

- Every endpoint validates its input
- Use the standard error response shape

De backendregels laden nu pas als iemand aan de backend werkt, en je frontender betaalt er geen context meer voor. Regels zonder paths laden bij het opstarten, met hetzelfde gewicht als .claude/CLAUDE.md, dus daar houd je alleen wat echt voor iedereen geldt.

Nog twee dingen die specifiek in een team spelen. Een collega kan claudeMdExcludes in zijn lokale settings zetten en jouw CLAUDE.md met een glob compleet uit zijn sessies weren, wat in een monorepo vol andermans bestanden precies de bedoeling is en daarbuiten een verrassing. En Claude Code leest CLAUDE.md en nooit AGENTS.md, dus in een repo waar de helft van het team een andere agent draait, wil je bovenaan een @AGENTS.md-import in plaats van twee bestanden die uit elkaar lopen.

Wat je dus wel commit

De rij die het meeste werk verzet, is de hook. Een PreToolUse-hook draait als shellcommando op een vast moment in de levenscyclus en doet zijn werk ongeacht wat het model besloot, en een blokkerende hook gaat vóór je allow-regels. Met dezelfde kanttekening als de rest van dit stuk, want een hook uit andermans repo is uitvoerbare code en zit achter dezelfde trust-drempel. Als een conventie er echt toe doet, is “we hebben het in CLAUDE.md gezet” een verzoek en is “de hook eindigt met exit 2” een antwoord. Alles wat ik schreef over het stapelen van regels, hooks en de sandbox geldt hier onverkort, met één extra beperking: in een team gaan de lagen waar een mens ja tegen moet zeggen later werken dan je denkt.

Anthropic komt van de andere kant bij hetzelfde gat uit. Hun handleiding voor grote codebases beantwoordt de uitrolvraag met een persoon in plaats van met een bestand: iemand die eigenaar is van de configuratie en de knopen mag doorhakken over het permissiebeleid en de plugin-marketplace, want zonder dat werk blijft de kennis bij een handjevol mensen hangen en loopt de adoptie vast. Ze zien er een agent manager-rol voor ontstaan. Dat is de eerlijke lezing van alles hierboven. Er zijn zo weinig lagen die zichzelf overeind houden, dat iemand zich om de rest moet blijven bekommeren.

Dit gaat eigenlijk niet over Claude Code. Een team dat het in een code review niet eens wordt over zijn conventies, wordt het ook niet eens in een CLAUDE.md, en gedeelde agent-config erbij halen om die knoop door te hakken is de bekende reflex om het gereedschap de schuld te geven van het proces. Wat de repo je wel geeft, is één plek om de afspraak op te schrijven, en een veel kortere weg van “dit hebben we besloten” naar “de agent doet dit standaard op ieders machine”.

Verwar een standaardwaarde alleen niet met een regel. Van alles wat je commit houden twee dingen zichzelf overeind: de denylist en de hook. De rest is advies, en advies is het opschrijven nog steeds waard. Kies met zorg welke twee of drie conventies het afdwingen verdienen.

Onder dat punt hoort een gids. Hier is hij.

Begin bij het deel dat mij verraste. Je logt allang. Claude Code schrijft vanaf de dag dat je het installeerde een gedetailleerd verslag van elke sessie naar je eigen schijf, en als je een beetje op mij lijkt, heb je er nog nooit een geopend.

Wat er al op je schijf staat

Drie aparte sporen, en geen daarvan is ooit met veel bombarie aangekondigd.

Het transcript, in ~/.claude/projects/<project>/<session-id>.jsonl. Ik pakte één doodgewone sessie op deze machine en telde: 1.434 records, 467 berichten van het model en 322 van mij, met daarin 146 Bash-aanroepen, 101 leesacties op bestanden en 12 edits. Over alle projecten heen staan hier 1.156 van die bestanden, samen 676 MB aan transcript.

Het schema is het interessante deel. Elk record kan cwd, gitBranch, version en entrypoint bevatten, een permissionMode plus aparte records elke keer dat die modus verandert, isSidechain om werk van subagents te markeren, durationMs, toolUseResult, en een keten van uuid, parentUuid, promptId en requestId waarmee je elke actie terugleidt naar de prompt die hem veroorzaakte.

En dan drie velden waarvan ik niet wist dat ze bestonden: attributionSkill, attributionMcpServer en attributionMcpTool. Komt een aanroep van een skill of van een MCP-server, dan legt het transcript vast welke. Elk gelezen bestand, elk commando, elke aangeroepen server, met het antwoord op “wat riep dit aan” in hetzelfde record.

De prompthistorie, in ~/.claude/history.jsonl. De mijne is bijna 16.000 regels lang en elke regel heeft precies vier velden: display, pastedContents, project en timestamp. Alles wat jij typte, en niets van wat de agent deed.

De bestandssnapshots, onder ~/.claude/file-history/<session>/. Hier staan 104 sessiemappen, 58 MB, met kopieën van bestanden zoals ze eruitzagen vlak vóór een edit. Hieruit zet /rewind bestanden terug, en dit is het enige spoor van de drie dat je laat zien hoe een bestand er eerder uitzag.

Twee dingen moet je weten voordat je hierop gaat vertrouwen. Het is tijdelijk: cleanupPeriodDays staat standaard op 30, en Claude Code gooit oudere sessiedata bij het opstarten weg. En het staat in platte tekst op schijf. De documentatie is er duidelijk over: leest een tool een .env-bestand of print een commando een sleutel, dan belandt die waarde in het transcript. Je auditlog is tegelijk een verzamelbak voor secrets, beschermd door niets anders dan bestandsrechten.

Daarmee is dit spoor prima om een ongeluk te reconstrueren, en precies daarvoor gebruikt het incidentdraaiboek het ook. Tegen iemand die het verslag wil aanpassen is een tekstbestand waar de gecompromitteerde gebruiker zelf schrijfrechten op heeft weinig waard.

Waarom hier niets van in je compliance-feed staat

Anthropic bracht in mei een Compliance API uit. Als je de aankondigingen leest, zou je denken dat het auditvraagstuk nu op organisatieniveau geregeld is.

Kijk liever naar de reikwijdte. De Activity Feed legt inlogacties, chats, bestanden, projecten, beheerhandelingen en platformacties vast, in honderden verschillende soorten gebeurtenissen, binnen een minuut opvraagbaar en zes jaar bewaard. De content-endpoints leveren claude.ai-data: chats, bestanden, projecten, bijlagen en transcripts van Cowork-sessies die in door Anthropic beheerde omgevingen draaien.

Claude Code op je laptop zit er niet in. Niet de Bash-commando’s, niet de edits, niet de MCP-servers die het aanriep. De andere helft van het enterprise-verhaal, de Claude Code Analytics API, geeft dagtotalen per gebruiker: sessies, toegevoegde en verwijderde regels, commits, en hoeveel voorstellen van de Edit-tool zijn geaccepteerd of geweigerd. Je ziet dat een ontwikkelaar dinsdag vijf edits weigerde. Wat die edits waren, staat er niet bij.

Eén uitzondering werkt juist andersom. De securitydocumentatie van Claude Code zegt dat elke handeling in een cloudsessie voor compliance wordt vastgelegd, en de Compliance API geeft al transcripts van remote sessies terug, inclusief tool_use- en tool_result-blokken, zes jaar bewaard. Let op de reikwijdte: dat endpoint bedient op dit moment alleen sessies waarvan product_surface op cowork_remote staat.

Het mechanisme om de tool-aanroepen van een agent bij een complianceteam te krijgen bestaat dus al en draait. Vandaag wijst het naar Cowork, en volgens de bètanotitie komen er later meer product surfaces bij. De Claude Code op je eigen machine, waar de meesten van ons hem draaien, hoort daar voorlopig niet bij.

Wat de feed je geeft, is een registratie van het control plane: identiteit, configuratie en de levenscyclus van resources. Die registratie stopt zodra er een gesprek begint. De log die je securityteam centraal kan bevragen en zes jaar bewaart, weet dus dat je een sessie opende. De log die weet dat je agent rm -rf draaide, is een bestand in platte tekst op je eigen machine dat zichzelf na dertig dagen wist.

Telemetrie is het echte kanaal, en standaard is alles weggelakt

De brug tussen die twee is OpenTelemetry, en Claude Code ondersteunt dat netjes. CLAUDE_CODE_ENABLE_TELEMETRY=1 plus een OTLP-endpoint levert elke 60 seconden metrics en elke 5 seconden loggebeurtenissen op, waaronder claude_code.tool_result, claude_code.tool_decision, claude_code.permission_mode_changed, claude_code.mcp_server_connection en claude_code.api_error.

Zet het aan en het eerste wat opvalt, is hoe weinig het je vertelt. Inhoud wordt standaard weggelakt, zonder uitzondering. Prompts komen binnen als <REDACTED> met alleen een prompt_length. Antwoorden van het model idem. De details van tools ontbreken ook, en dat is nou juist het onderdeel waar het om draait: zonder OTEL_LOG_TOOL_DETAILS=1 zie je geen Bash-commando’s, geen bestandspaden, geen namen van MCP-tools, en aanroepen van plugins van derden komen binnen als de tekst custom of mcp. Je krijgt een betrouwbaar verslag dát er een tool draaide, zonder enige manier om te weten welke.

Dus zet je die vlag om, en vanaf dat moment stroomt elk commando en elk bestandspad dat je agent aanraakt naar je collector. Daarnaast is er OTEL_LOG_TOOL_CONTENT voor de invoer en uitvoer van tools, en OTEL_LOG_RAW_API_BODIES voor de volledige request en response van de Messages API inclusief gespreksgeschiedenis, waarvan de documentatie opmerkt dat je daarmee instemt met alles wat de andere drie vlaggen blootleggen.

Zo ziet die keuze eruit, en hij is bijna binair. Uit, en je auditlog kan een linter niet onderscheiden van het droppen van een database. Aan, en je stuurt broncode, commando’s en sleutels naar waar je collector ook maar naartoe schrijft. De tussenweg die de meeste teams willen, namen van tools en bestandspaden zonder de inhoud van bestanden, is ongeveer wat OTEL_LOG_TOOL_DETAILS in zijn eentje geeft, en daar zou ik beginnen.

Twee details om mee te nemen. Beheerders kunnen het OTLP-endpoint vastzetten via managed settings, waarna Claude Code bij het opstarten conflicterende variabelen van de ontwikkelaar weggooit, zodat niemand de export lokaal kan omleiden. En subprocessen erven de OTEL_*-variabelen niet, dus Bash-commando’s, MCP-servers en language servers die de agent start, worden niet stiekem meegemeten.

De log die je echt wilt is één hook

Wil je een spoor met je eigen regels, dan zijn hooks het middel. PostToolUse vuurt na elke aanroep, met tool_name, tool_input, tool_use_id en tool_result.

Zelf bouwen is de route die Anthropic voor ogen heeft. De securitydocumentatie van Anthropic zegt onder het kopje teamsecurity dat je Claude Code via OpenTelemetry-metrics moet monitoren en wijzigingen in instellingen met ConfigChange-hooks moet controleren. Er is geen product dat dit voor je doet.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash|Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{ts: now, session: .session_id, mode: .permission_mode, tool: .tool_name, input: .tool_input}' >> ~/.claude/audit.jsonl"
          }
        ]
      }
    ]
  }
}

Elke hook-payload bevat session_id, transcript_path, cwd, permission_mode en hook_event_name, plus agent_id en agent_type binnen subagents. permission_mode is het veld dat je makkelijk over het hoofd ziet: je eigen log legt vast of de sessie op dat moment in bypassPermissions stond, en dat is de eerste vraag die iedereen achteraf stelt.

Vier andere gebeurtenissen verdienen hun plek. PermissionDenied laat zien wat de agent probeerde en jij weigerde, wat een beter signaal is dan alles wat wél mocht. ConfigChange vuurt met een config_source zodra instellingen of skills veranderen terwijl je bezig bent. FileChanged werkt met letterlijke bestandsnamen die je in de gaten wilt houden, dus .env|.envrc is een struikeldraad van één regel. En SubagentStart geeft je het agent_type plus een agent_id om een sidechain mee te groeperen.

Verzamelen was de makkelijke helft

Alles hierboven is loodgieterswerk, en loodgieterswerk krijg je af. De reden dat ik dit stuk schreef is de vraag erna, en daar bestaat geen instelling voor.

Wie leest die log, en waar wordt iemand voor wakker gebeld?

Hugging Face is de casus, en hun kant van dat incident is bepaald geen horrorverhaal. Hun anomaliedetectie, met LLM-triage over securitytelemetrie, legde signalen naast elkaar die stuk voor stuk op gewone ruis leken, en sloeg aan. Het gat zat tussen zien en stoppen: TechCrunch meldde dat de urgentie nooit werd opgeschaald en het on-callteam nooit werd gebeld. De detectie werkte, en daarna bleef het signaal in een wachtrij staan, omdat er geen regel was die het verder bracht.

Dat patroon is niet nieuw, en er zijn cijfers over. Het rapport van Intezer uit februari, gebaseerd op 25 miljoen alerts van 10 miljoen bewaakte endpoints en 82.000 forensische endpoint-onderzoeken, liet zien dat 1,9% van de endpoint-alerts met lage of informatieve prioriteit een echt incident bleek te zijn. Ruwweg één op de vijftig alerts die niemand geacht wordt te lezen is een echte dreiging, weggezet als ruis en door niemand bekeken.

Intezer verkoopt alert-triage, dus houd bij dat cijfer rekening met de bron. De onafhankelijke variant komt van Mandiant, dat voor M-Trends 2026 put uit ruim 500.000 uur incidentrespons in 2025. De wereldwijde mediane verblijftijd van aanvallers ging omhoog, van 11 naar 14 dagen. Organisaties ontdekten de inbraak in 52% van de gevallen zelf, een echte verbetering ten opzichte van de 43% een jaar eerder. De overige 48% hoorde het van buitenaf.

Vertaal dat nu eens naar een agent. Je agent produceert honderden aanroepen per uur, en elke aanroep ziet er op zichzelf legitiem uit, want je hebt hem die tools met opzet gegeven. Stuur je dat naar een wachtrij die niemand heeft toegezegd te lezen, dan heb je het probleem van die 1,9% nagebouwd met een veel grotere noemer.

Schrijf de escalatieregel dus vóór je de pijplijn bouwt. De mijne heeft drie niveaus en past op een bierviltje. Log alles, goedkoop, in de verwachting dat je het meeste nooit zult lezen. Waarschuw bij een kort lijstje patronen: een geweigerde permissie gevolgd door een andere route naar hetzelfde bestand, een .env die gelezen wordt, een MCP-tool die voor het eerst in deze repository wordt aangeroepen, een sessie die omslaat naar bypassPermissions en daarna aan infrastructuur komt. Bel iemand voor bijna niets, en weet vooraf wat dat bijna-niets is.

De eenheid telt net zo zwaar als de drempel. Toegestaan of geweigerd per aanroep is het verkeerde detailniveau, want zo zie je geen reeks. Vispute en Kadam werken dat argument formeel uit in een paper uit maart waarin ze reasoning provenance voorstellen: uitvoeringssporen en state checkpoints leggen vast wat een agent deed. Waaróm hij daarvoor koos, valt daar in het algemeen niet uit te reconstrueren, dus die afweging moet je op het moment zelf als volwaardig veld vastleggen. Het is een positiepaper met een referentie-implementatie en nog zonder meetresultaten, dus het levert je vooralsnog alleen een richting op. Die richting klopt. Je transcript heeft promptId en parentUuid op elk record staan, en daarmee groepeer je een sessie vandaag al in trajecten, zonder op een standaard te wachten.

Wat je concreet kunt doen

• Open deze week één transcript. Pak een .jsonl uit ~/.claude/projects/ en lees wat een normale sessie van jou bevat. Je schrijft geen escalatieregel voor een patroon dat je nooit gezien hebt.
• Kies je bewaartermijn bewust. cleanupPeriodDays staat standaard op 30. Wil je een spoor voor een onderzoek dat pas in maand twee begint, stuur het dan ergens anders heen, en bedenk bij die keuze dat het platte tekst is.
• Zet OTEL_LOG_TOOL_DETAILS aan en houd het daarbij, tenzij je een concrete reden hebt om inhoud te loggen. Namen van tools en bestandspaden beantwoorden de meeste vragen. Ruwe API-bodies beantwoorden de rest en leveren een veel groter probleem op.
• Schrijf eerst het lijstje waarvoor je iemand belt. Drie patronen, afgestemd met degene die de pager draagt. Bouw je de pijplijn vóór dat lijstje, dan krijg je een wachtrij, en van een wachtrij wordt niemand wakker.

Wat mij uit de tijdlijn van OpenAI blijft bezighouden, is dat beide bedrijven het bewijs in handen hadden. De pijplijn van Hugging Face zag de aanval in real time. De transcripts van OpenAI bevatten elke stap ervan, volledig, op hun eigen infrastructuur. Er was toch nog een telefoontje op 20 juli voor nodig, over sleutels die allang vervangen waren, voordat iemand doorhad wat er was gebeurd. In de tweedeling van Mandiant viel het bedrijf dat de agents bouwde in die 48%.

Niemand had een betere log nodig. Ze hadden een afspraak nodig over wie er gebeld wordt.

Op 6 augustus beschreef OpenAI op Black Hat wat er gebeurt als agents dat kanaal zelf bouwen, uit een package registry, zonder dat iemand erom heeft gevraagd.

Normaal merk je dat pas als de tests omvallen. Daarna wissel je van venster en leg je nog eens uit wat je een half uur eerder al had uitgelegd.

Sinds v2.1.224 kan die eerste sessie het de tweede zelf vertellen.

Peer sessions (1):
  chaos-mcp-e7 [15619a]  ·  interactive  ·  busy  ·  started 3h ago

Dat is deze machine. Twee Claude Code-sessies die allebei weten dat de ander er is.

Wat cross-session messaging precies is

Tekst. Meer zit er niet in.

De Claude van de ene sessie schrijft een zin, de Claude van de andere sessie leest hem. Geen gespreksgeschiedenis, geen bestanden, geen context. De ontvanger krijgt exact wat de afzender heeft ingetypt en verder niets.

Twee tools doen het werk. ListAgents zoekt uit welke sessies bereikbaar zijn, SendMessage bezorgt een bericht bij één daarvan op naam. Geen van beide roep je zelf aan. Jij praat met Claude, Claude verstuurt.

Eerst de voorwaarden, want daar zit vrijwel elk geval van “het werkt niet”:

• v2.1.224 of nieuwer. Controleer met claude --version.
• macOS of Linux, WSL 2 inbegrepen. Op native Windows bestaat het niet.
• Niet op Bedrock, Claude Platform op AWS, Google Cloud’s Agent Platform of Microsoft Foundry.
• De feature-flag-evaluatie moet aan staan. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK en DISABLE_GROWTHBOOK zetten allemaal de flag-evaluatie uit die deze functie nodig heeft. Zet er één van aan, in je shell of in een env-blok in je settings, en messaging staat uit zonder dat je er iets van merkt.

Je controleert het in één seconde met /list-agents, ook te typen als /peers. Kent de sessie het commando niet, dan heeft die de functie niet. Werkt het wel, dan staat messaging aan en heeft elk probleem daarna een specifiekere oorzaak.

Een bericht sturen

Je adresseert nooit zelf iets. Je beschrijft wat er moet gebeuren:

Ask the session in my other terminal whether the migration finished

Of je laat de formulering helemaal aan Claude over:

Tell the session working on the payments API what we just changed

Claude kiest de ontvanger, schrijft de tekst en verstuurt. Aan de andere kant komt er één regel binnen:

Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.

Het bericht komt binnen met de naam van de afzender en een antwoordadres. Zit de ontvangende Claude midden in een beurt, dan wordt het in de wachtrij gezet. Ligt die sessie stil, dan begint er meteen een nieuwe beurt. Zodra Claude het gelezen heeft, klapt het in tot een regel Message from, die je met Ctrl+O weer uitklapt.

Claude stuurt ook uit zichzelf een bericht, als hij doorheeft dat hij net iets veranderd heeft waar een andere sessie op voortbouwt.

De naam is het adres

Elke sessie luistert naar een naam.

claude --name payments

Of /rename tijdens de sessie. Stel je niets in, dan leidt Claude Code er zelf een af uit de mapnaam plus een korte hash. De sessie waarin deze post geschreven is, staat geregistreerd als tim-vitepress-38.

Twee sessies in verschillende mappen kunnen dezelfde naam krijgen. /list-agents toont per lokale sessie de werkmap zodat je ze uit elkaar houdt, en in Claudes eigen overzicht staat de korte identifier die je bovenaan deze post ziet. Die gebruikt hij in het adres zodra namen botsen.

Het registratiebestand en de inbox-socket

Even doorlezen loont hier, want hier zit de verklaring voor elk geval van twee sessies die elkaar niet zien.

Elke sessie schrijft een klein JSON-bestand en opent een Unix-socket. Dit is de registratie van deze sessie, letterlijk:

{
  "pid": 1318539,
  "sessionId": "56593ac1-515e-4e33-b078-0810410f98b0",
  "cwd": "/root/tim-vitepress",
  "version": "2.1.226",
  "peerProtocol": 1,
  "kind": "interactive",
  "messagingSocketPath": "/run/user/0/cc-socks/1318539.sock",
  "name": "tim-vitepress-38",
  "nameSource": "derived",
  "status": "busy"
}

Sessies vinden elkaar dus via het bestandssysteem. Twee sessies bereiken elkaar alleen als ze dezelfde bestanden kunnen zien. Een sessie in een container en een sessie op de host komen nooit bij elkaar, wat je ook instelt, omdat die container zijn eigen bestandssysteem heeft. Twee sessies binnen dezelfde container bereiken elkaar wel, ook op een self-hosted runner.

De socket is per sessie en alleen toegankelijk voor je eigen systeemgebruiker:

srw------- 1 root root 0 Aug  9 15:14 1318539.sock

Op een gedeelde machine komen de sessies van een andere gebruiker er dus niet bij.

Je vindt die van jezelf op twee plekken: de regel Peer address in /status, met uds: ervoor, en de omgevingsvariabele CLAUDE_CODE_MESSAGING_SOCKET. Claude Code exporteert die naar elke hook en elk Bash-commando voordat er iets draait, SessionStart inbegrepen, en elke sessie exporteert zijn eigen socket in plaats van die van een bovenliggende sessie.

Op die variabele valt iets te bouwen. Een hook of een gewoon shellscript kan een bericht plaatsen in de sessie waar het bij hoort. Een lange testrun is klaar en laat een regel achter in de terminal die erop wacht. Een deployscript rapporteert terug zonder dat jij de logs zit te volgen.

Lees wel eerst de platformverschillen. Als er geen crossSessionInbound-waarde van toepassing is, bezorgt Claude Code een bericht waarvan hij kan vaststellen dat het van een kindproces van de sessie zelf komt. Op Linux, ook binnen WSL 2, lukt die controle zelfs nadat het kindproces is gestopt. Op macOS alleen zolang het verzendende proces nog draait. In een container waar Claude Code als PID 1 draait helemaal niet. Kan hij het niet vaststellen, dan behandelt hij het bericht als elk ander bericht zonder aangegeven permissieklasse, en houdt een sessie die permissievragen overslaat het vast tot jij het goedkeurt.

Een bericht is geen toestemming

Dit is het deel waar de meeste ontwerpaandacht in is gaan zitten, en het deel dat elke “mijn agents praten nu met elkaar”-post gaat overslaan.

De ontvangende Claude hoort er meteen bij van wie het bericht komt: een andere Claude-sessie, geen mens. Dat onderscheid wordt afgedwongen:

• Het keurt niets goed. Een bericht van een andere sessie geldt nooit als jouw toestemming, dus het kan geen openstaande permissievraag namens jou beantwoorden.
• Het verandert geen configuratie. De ontvangende Claude krijgt de instructie om nooit permissie-instellingen, CLAUDE.md of iets anders configuratie-achtigs aan te passen omdat een andere sessie erom vroeg.
• Commando’s komen aan als tekst. Een /compact in de tekst van het bericht is acht tekens. Claude Code voert het nooit uit.
• Permissievragen komen gewoon langs. Wat er naar aanleiding van het bericht gebeurt, vraagt dezelfde goedkeuringen als werk dat jij zelf hebt gevraagd.

Ook de verzendkant is begrensd. Claude krijgt te horen dat hij een andere sessie nooit mag vragen om iets dat in zijn eigen sessie geweigerd of geblokkeerd is, of dat zijn eigen permissieregels zouden tegenhouden, en dat hij dat werk in plaats daarvan bij jou neerlegt.

Lees die twee samen en het dreigingsmodel spreekt voor zich: een sessie met minder beperkingen die het werk witwast voor een sessie met meer. Deze functie is gebouwd op de aanname dat één van je eigen agents dat vroeg of laat probeert.

Dezelfde release maakt dat punt nog een keer, in een regel waar de meeste artikelen overheen lazen. Uit de changelog van 2.1.224:

Fixed sandbox filesystem deny entries written with a trailing slash
(e.g. denyRead: "~/.aws/") being silently bypassable on Linux and macOS

Elke denyRead- of denyWrite-regel die je met een slash op het eind had geschreven, was dus versiering. Geen foutmelding, geen waarschuwing, en de credentials waarvan je dacht dat ze afgeschermd waren lagen al die tijd open. Draaien je sessies in een sandbox en eindigt een van die paden op een slash, dan is dat op zichzelf al reden genoeg om te updaten. Kijk daar even naar voordat je verderleest.

Bezorgd, vastgehouden of geweigerd

Tussen twee gewone interactieve sessies met standaardinstellingen komt een bericht zonder omhaal aan. Andere configuraties houden het vast of gooien het weg, en dat verschil telt zodra je iets gaat scripten.

Elk binnenkomend bericht wordt getoetst aan de inbound-instellingen van de ontvanger en eindigt in één van drie toestanden:

crossSessionInbound bepaalt welke: accept, hold of refuse.

Staat er niets ingesteld, dan beslist de standaard per bericht, en wel op basis van permissiemodus. Sessies vallen uiteen in twee klassen: de sessies die permissievragen overslaan, en alle andere. Plan mode telt als overslaan in sessies waar bypass permissions beschikbaar zijn. auto, acceptEdits en dontAsk gelden alle drie als vragend.

• De ontvanger stelt permissievragen: berichten worden bezorgd, behalve een bericht van een afzender die aangeeft dat hij permissievragen overslaat. Dat wordt voor jou vastgehouden.
• De ontvanger slaat permissievragen over: berichten worden voor jou vastgehouden, behalve een bericht van een afzender die ze ook overslaat.

De sessie met --dangerously-skip-permissions gaat aan beide kanten in quarantaine. Terecht.

Een vastgehouden bericht opent in de ontvangende sessie een goedkeuringsvenster met de afzender en een voorvertoning van de tekst. Goedkeuren bezorgt dat ene bericht, weigeren gooit het weg, en negeren gooit het ook weg zodra dialogExpiry verstrijkt, standaard na vijf minuten. Verandert de permissieklasse van de sessie terwijl er berichten vastgehouden worden, dan gelden de regels opnieuw, dus vastgehouden berichten kunnen alsnog vrijkomen. Zet je crossSessionInbound op refuse terwijl er berichten wachten, dan gaan ze allemaal weg en krijgt elke bereikbare afzender een weigering terug.

Per sessie worden er maximaal 100 berichten vastgehouden en maximaal 50 geaccepteerde maar ongelezen berichten bewaard. Herhalingen van dezelfde afzender worden afgeknepen, en identieke herhalingen binnen een korte periode gaan direct de prullenbak in. Daarom kunnen twee sessies niet eindeloos tegen elkaar aan blijven praten.

De voorrang loopt bewust maar één kant op

Bij de meeste instellingen in Claude Code mag een projectbestand je gebruikersinstellingen overschrijven. Bij deze instelling niet:

Claude Code reads managed settings first, then the --settings flag, then user settings, and applies the first value found; a value in project or local settings applies only when it’s stricter, on the accept < hold < refuse ladder, than the value those trusted sources give.

Een ingecheckt projectbestand mag dus aanscherpen en nooit versoepelen. Zet geen van de vertrouwde bronnen een waarde, dan geldt een hold of refuse uit project- of lokale instellingen alsnog, in plaats van de standaard per bericht.

Isolatie tussen machines heeft dezelfde vorm:

{
  "isolatePeerMachines": true
}

Een true uit welke laag dan ook telt, dus een projectbestand kan de eis aanzetten en niets kan hem uitzetten. Staat hij aan, dan vraagt Claude om je goedkeuring voordat een antwoord de machine verlaat, ook in bypassPermissions-modus. Voor berichten binnen dezelfde machine vraagt hij niets.

Uitzetten

Ontvangen en versturen zijn losse knoppen, dus je kunt de ene richting dichtzetten en de andere open laten.

Stoppen met ontvangen:

{
  "crossSessionInbound": "refuse"
}

Stoppen met versturen en met het opsommen van sessies, met deny-regels die alleen de kale toolnaam bevatten, zonder verdere specificatie:

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  }
}

Allebei samen, in managed settings, is de uit-knop voor de hele organisatie:

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

Twee dingen om te weten voor je dat uitrolt. Met SendMessage op deny verdwijnt ook messaging naar subagents en teamgenoten in een agent team, want het is dezelfde tool. En een weigerende sessie ziet er volstrekt normaal uit, in zijn eigen /status en in de overzichten van andere sessies, dus je kunt het alleen vaststellen door de configuratie te lezen.

Andere machines, waar de documentatie al achterloopt

Waar de andere sessie draait, bepaalt hoe het bericht reist.

Volgens de documentatiepagina kun je bij alles buiten deze machine alleen antwoorden: Claude hier reageert wel op een bericht dat van je laptop kwam, maar begint het gesprek niet zelf. Dat gold precies één release lang. Uit de changelog van 2.1.225:

SendMessage can now start a conversation with your Remote Control sessions on
other machines by name (ListAgents shows them as name [ref]), instead of only
replying after they message you first

Op 2.1.226 beschrijft de ListAgents-tool zijn eigen bereik net zo, en nergens staat er nog dat je alleen mag antwoorden. Op de documentatiepagina staat nog de regel uit 2.1.224.

Het loont dus om te weten welke van de twee je zit te lezen. Precies zo’n beperking bouw je namelijk in je workflow in, en die ging er na één release alweer af. Remote Control moet hier nog steeds verbonden zijn voordat die sessies überhaupt in het overzicht verschijnen, en over websessies zegt de changelog niets.

Eén valkuil blijft hoe dan ook staan. Antwoord je een sessie buiten deze machine terwijl de antwoordende sessie zelf niet met Remote Control verbonden is, dan vertrekt het antwoord alsnog, als rechtstreeks verzoek aan Anthropic-servers, maar komt het aan zonder antwoordadres. De ontvanger kan er niets op terugsturen. Claude krijgt dat te horen op het moment dat hij verstuurt, en dat is meer waarschuwing dan de meeste tools je geven.

Onbemande workers

Een claude -p-sessie opent net als elke andere een socket en staat gewoon in het overzicht, dus een lange migratie of testrun kan terugrapporteren aan de sessie die jij in beeld hebt.

Wat zo’n sessie niet kan, is een goedkeuringsvenster tonen. Een vastgehouden bericht blijft daar vastgehouden, en komt alleen los door een latere wijziging in modus of instellingen. Wil je dat een onbemande worker berichten aanneemt, zeg dat dan bij het starten:

claude -p "run the migration" --settings '{"crossSessionInbound":"accept"}'

Een accept in je gebruikersinstellingen werkt ook, maar geldt dan voor elke sessie die je start, en dat is meestal ruimer dan je bedoelde. Bare mode, de uitgeklede headless start die het meeste van de sessieopbouw overslaat, opent helemaal geen socket, dus die sessies zijn onzichtbaar en onbereikbaar.

Wat het niet is

De fout die je gaat maken is een bericht behandelen als gedeelde context. Het is één zin, gekozen door de afzender, en er hangt niets aan vast.

Wil je eigenlijk de context van die andere sessie, dan heb je een andere functie nodig:

Messaging dekt het smalle geval: een sessie die jij aanstuurt weet één ding dat een andere sessie die jij aanstuurt nu nodig heeft, midden in de klus.

Elk ander multi-agentverhaal van dit jaar ging over agents méér bereik geven. Dit verhaal levert een kanaal en besteedt vervolgens de meeste regels aan wat er niet doorheen mag. Een bericht draagt informatie en geen gezag, en dat is precies wat je wilt van de terminal in het andere venster.

Terug naar die hernoemde kolom. De tweede sessie krijgt één zin over tenant_id en doet daarna wat hij ook had gedaan als jij die zin zelf had ingetypt: hij vraagt het aan jou voordat hij iets aanraakt.

Nu kost het twee keer Escape.

Checkpointing is een van de betere dingen die Anthropic aan Claude Code heeft toegevoegd. Het haalde een echte drempel weg om dingen uit te proberen, zonder dat ik mijn manier van werken hoefde aan te passen. Het product zelf verkoopt het als “Undo anything”, met de terechte toevoeging dat je git-historie schoon blijft.

Het loont om precies te weten wat daar wel en niet onder valt, want je hebt er veel meer aan zodra je ziet hoe het in elkaar zit. De grenzen staan gedocumenteerd, ze zijn logisch, en ze volgen één regel die je makkelijk onthoudt.

Wat een checkpoint precies is

Claude Code legt de staat van je code vast vóór elke prompt die je stuurt. Een niveau dieper maakt hij een backup van losse bestanden voordat hij ze aanpast met zijn edit-tools: Write, Edit en NotebookEdit. Je prompts zijn dus je herstelpunten.

Een paar getallen om te onthouden:

• 100 checkpoints per sessie. Valt er een oude af, dan verdwijnen de snapshots waar geen enkel resterend checkpoint meer naar verwijst. Met één uitzondering: de eerste snapshot van elk bestand blijft staan, want de VS Code-extensie gebruikt die als basis voor de diffs van je sessie.
• Checkpoints worden bij het gesprek bewaard, dus /rewind werkt nog steeds als je de sessie dagen later hervat.
• Ze verdwijnen samen met de sessie na 30 dagen, wat je aanpast met cleanupPeriodDays.

Je kunt het geheel ook uitzetten: in je settings heet die schakelaar “Rewind code (checkpoints)”. In cloud-sessies werkt het nog niet.

Esc Esc, en de zes keuzes

Typ /rewind, of druk twee keer op Esc terwijl het invoerveld leeg is. Dat laatste detail verrast mensen: staat er tekst in het veld, dan wist dubbel Esc die tekst in plaats van het menu te openen. Die tekst gaat wel naar je invoerhistorie, dus met Up heb je hem zo weer terug.

Het menu toont elke prompt die je deze sessie hebt gestuurd. Kies er een, en kies dan een actie:

De twee code-opties verschijnen alleen als het gekozen checkpoint ook echt bijgehouden wijzigingen heeft om terug te draaien. Een menu dat een knop weglaat als die toch niets zou doen is een kleinigheid, maar precies daarin zit het verschil tussen een tool die je vertrouwt en een tool die je elke keer eerst even test.

Draai je het gesprek terug, dan zet hij je oorspronkelijke prompt weer in het invoerveld, klaar om aan te passen en opnieuw te sturen. Daar is de functie voor gebouwd: terug naar vlak vóór de verkeerde afslag, het beter formuleren, opnieuw beginnen.

De twee samenvat-opties zijn in feite een /compact die je op een specifiek stuk van de sessie richt. Aan je bestanden verandert niets, en de oorspronkelijke berichten blijven in het transcript staan, dus je raakt niets kwijt. Selecteer de optie en typ in de regel add context (optional) om te sturen wat de samenvatting moet bewaren.

Wil je de oorspronkelijke sessie intact houden en er een tweede aanpak naast proberen, dan gebruik je /branch of claude --continue --fork-session. Dit hoort allemaal bij je context-budget, en samenvatten is daarvan het meest precieze instrument.

Nog een mooie: heb je eerder in hetzelfde proces /clear gebruikt, dan staat bovenaan de rewind-lijst een extra regel, /resume <session-id> (previous session). Vanaf 2.1.191 kun je dus terugstappen tot voorbij een clear waar je spijt van hebt.

Wat hij bijhoudt, en wat bij git blijft

Dit is de regel waar de hele functie op draait: checkpointing dekt de wijzigingen die de hoofdagent maakt met zijn eigen edit-tools. De rest blijft het werk van git.

Die verdeling valt goed te verdedigen. De tool kan zijn eigen edit-pad snel en exact vastleggen. Hij weet niet wat npm install, een formatter of een migratie in je working tree heeft uitgespookt, en hij doet ook niet alsof.

In de praktijk betekent het: hoe meer van een taak via bash loopt, hoe meer ervan bij een commit hoort in plaats van bij een checkpoint. Een sessie met zorgvuldige bestandsedits is volledig gedekt. Bij een sessie die een codemod draait, een schemadump opnieuw genereert en een lockfile herschrijft geldt dat grotendeels niet.

Twee dingen die uit die regel volgen en makkelijk over het hoofd worden gezien. Een restore verwijdert de bestanden die de agent sinds dat punt heeft aangemaakt, je krijgt dus echt de oude staat terug. En checkpoints horen bij de sessie waarin ze gemaakt zijn.

De subagent-regel die je uit je hoofd wilt kennen

Deze zou ik op een post-it schrijven, want het is het minst intuïtieve deel, en tegelijk het deel waarvan je precies kunt weten hoe het zit.

Een subagent past bestanden aan met dezelfde tools als de hoofdagent, maar die edits belanden meestal buiten de checkpoints van jouw sessie. Of een rewind ze terughaalt hangt volledig af van hoe die subagent draaide:

• Een skill met context: fork die op de voorgrond draait werkt tijdens jouw eigen beurt in je working tree, dus een rewind herstelt die edits gewoon.
• Elke andere subagent wordt niet hersteld. Dat geldt ook voor een forked skill die op de achtergrond draait, wat de standaard is, en voor een /code-review --fix op de achtergrond. Daarvoor val je terug op git.

Dezelfde skill valt er dus wel of niet onder, afhankelijk van één flag in de frontmatter. Verdeel je werk over parallelle agents in worktrees, dan is je vangnet daar de branch, precies zoals vóór checkpointing.

Wanneer een restore een bestand overslaat

Sinds 2.1.216 weigert een restore te schrijven naar een bijgehouden pad dat inmiddels een symlink, een hard link of een ander niet-regulier bestand is. Hij slaat ook bestanden over waarvan de bovenliggende map niet meer op dezelfde plek uitkomt als tijdens het checkpoint, of waarvan hij de backup niet veilig kan lezen. Je krijgt dan de waarschuwing Restored the code, but skipped N files, en die bestanden houden hun huidige inhoud.

Twee doodgewone situaties vallen hieronder: configbestanden die een dotfile-manager je project in symlinkt, en alles wat pnpm met hard links op zijn plek zet.

Dit is een echte verbetering. Vóór 2.1.216 schreef en verwijderde een rewind dwars door die links heen, zonder melding, en dat is een stuk vervelender dan een waarschuwing. Wil je zien welke paden precies zijn overgeslagen, zet dan /debug aan vóór je herstelt en lees ~/.claude/debug/<session-id>.txt.

Terugdraaien vanuit een script

Dezelfde machinerie is ook buiten je interactieve sessie beschikbaar. In de Agent SDK zet je enableFileCheckpointing: true (of enable_file_checkpointing=True), voeg je replay-user-messages toe zodat user-berichten met een UUID binnenkomen, bewaar je de UUID die je wilt, en roep je rewindFiles() of rewind_files() aan. Let op: dit herstelt alleen bestanden, het gesprek blijft staan waar het staat.

Vanaf de CLI ziet dat er zo uit:

CLAUDE_CODE_ENABLE_SDK_FILE_CHECKPOINTING=true claude -p --resume <session-id> --rewind-files <checkpoint-uuid>

De flag staat op zichzelf, hij heeft --resume nodig, hij weigert samen met een prompt te draaien, en hij staat niet in claude --help. Zonder de environment-variabele krijg je “File rewinding is not enabled”, de foutmelding waar ik anders een uur op had zitten staren als de documentatie het niet had vermeld.

Daarmee heb je een prima patroon voor onbeheerde runs: bewaar de UUID van de laatste beurt waarvan je weet dat hij goed was, en draai de bestanden automatisch terug zodra je eigen validatie faalt.

Hoe ik het gebruik

Rewind is mijn standaardreactie op een verkeerde richting, en het heeft veranderd hoe makkelijk ik een agent dingen laat proberen. Twee tikken, terug naar vlak vóór de afslag, een betere prompt sturen. Geen branch, geen stash, geen reverts om door te lezen.

Daaromheen doet één gewoonte het meeste werk: committen voordat ik iets van omvang uit handen geef. Binnen zijn grenzen is rewind betrouwbaar, en de commit dekt de andere helft af. Bash-wijzigingen, output van subagents, die map die hij verplaatste, de sessie die je afgelopen donderdag hebt afgesloten.

De documentatie zegt het onomwonden, en zo houd ik het ook het liefst uit elkaar: checkpoints zijn er voor snel herstel binnen een sessie, versiebeheer is er voor blijvende historie. Dat zijn twee verschillende taken, en de tool claimt er maar één van.

Goed om in je achterhoofd te houden: een rewind zet je bestanden terug, maar buiten je machine is gebeurd wat er gebeurd is. De migratie draaide, de commit ging de deur uit, de webhook vuurde. Zodra er iets buiten je working tree is beland ben je niet meer aan het terugdraaien, dan ben je een incident aan het afhandelen, en verandert de bestandshistorie van redmiddel in bewijsmateriaal.

Binnen je working tree is dit de goedkoopste manier van terugdraaien die de tool ooit heeft gehad. Leer waar het ophoudt en je hoeft er verder niet meer over na te denken.

De luidste klacht in het vak gaat dus over debuggen, en wat er als oplossing wordt verkocht, is nog een agent.

En toch. Gisteren vond een agent binnen anderhalve minuut een null in een serializer, in een bestand waar ik twintig minuten naar had zitten staren. Hij had gelijk. Hij had gelijk over iets waar ik zelf ook wel op was uitgekomen, via de saaie route.

Allebei waar. De vraag die je verder helpt, is welke helft van het debuggen je weggeeft.

Waar een agent echt beter in is

Breedte, en uithoudingsvermogen voor het saaie deel.

Een stack trace die veertig bestanden raakt, is voor mij vervelend werk en kost de agent niets. Elke aanroep van een functie opzoeken en stuk voor stuk naast het contract leggen, of de broncode van een dependency lezen in plaats van te gokken wat hij doet: dat is echt werk dat ik oversla als ik moe ben, en hij slaat het niet over.

Hij heeft ook geen ego dat hij moet beschermen. Ik verdedig mijn eigen architectuur zonder dat ik het doorheb. Hij leest mijn slimme stukje code net zo neutraal als de rest, wat af en toe vernederend is en meestal nuttig.

Dat is de mechanische helft van het zoeken naar de oorzaak. Die mag je weggeven. De vraag is wat er met de andere helft gebeurt.

Waar debuggen met AI misgaat

Er is een onderzoek dat die vraag beter beantwoordt dan welke blogpost dan ook, inclusief deze.

Een team draaide 750.013 fault localization-taken met tien modellen op ruim 1.300 echte Java- en Python-programma’s (arXiv 2504.04372). Ze bouwden fouten in, hielden alleen de programma’s over waarin een model de fout daadwerkelijk vond, en pasten daarna semantic-preserving mutaties toe: wijzigingen die niets veranderen aan wat het programma doet.

Dode code. Misleidende comments. Misleidende variabelenamen. Functies in een andere volgorde.

Vervolgens misten de modellen in 78% van de gevallen de fout die ze daarvoor wél hadden gevonden.

De uitsplitsing per mutatie is nog vervelender dan dat ene getal:

Lees dat rijtje nog eens als beschrijving in plaats van als experiment. Dode code. Comments die niet meer kloppen. Namen die liegen over wat het ding doet. Functies in de volgorde waarin ze erbij zijn geplakt in plaats van de volgorde waarin ze draaien.

Die mutaties beschrijven elke codebase die drie jaar heeft gedraaid.

Hetzelfde onderzoek laat zien dat 56% van de fouten die de modellen vinden in het eerste kwart van de code zit, en 6% in het laatste kwart. De onderkant van je bestand wordt nauwelijks doorzocht. En bij de nieuwere Claude- en Gemini-versies die ze testten ging de fault localizability één tot twee procent omhoog, dus wachten op het volgende model helpt je hier niet.

Omvang doet daar nog een schepje bovenop. LinuxFLBench zette agents op 250 echte bugs in de Linux-kernel, in een tree van 69.000 bestanden en 28 miljoen regels (arXiv 2505.19489). De beste, SWE-Agent, kwam uit op een Recall@1 van 0,416.

Het scherpste punt van het paper zit in het verschil: dezelfde agents scoren 16,7% tot 31,9% hoger op software van normale omvang. Tot een derde van de nauwkeurigheid verdwijnt puur door de omvang.

En bij de bugs waar je de meeste hulp bij kunt gebruiken, regressies, zijn de cijfers om te beginnen ronduit somber. Op RegMiner4APR, 99 regressies uit 32 repositories, scoorden de klassieke repair-tools 0%. De beste LLM-aanpak leverde in 9% van de gevallen een correcte patch op (arXiv 2506.13182).

Daarna vertelden de onderzoekers het model welke commit de bug had geïntroduceerd.

Zestien procent. Bijna een verdubbeling, door één feit dat de hele tijd in git log stond.

Al die missers komen door ontbrekende informatie

Dat is de rode draad door alle drie de papers, en het is de basis onder een hele werkwijze.

Het model heeft redeneervermogen genoeg. Wat het mist, zijn de feiten die de zoekruimte kleiner maken en die jij al hebt: welke commit, welk subsysteem, welke naam in dit bestand op dit moment staat te liegen. Geef die erbij, en de cijfers gaan omhoog. Houd ze achter en je krijgt stellige output die naar de bovenkant van het verkeerde bestand wijst.

Daarmee krijg je een werkverdeling die niets te maken heeft met hoe moeilijk de bug is.

Jij bakent af en stelt de hypothese op. Hij zoekt en toetst.

Zo draag je een bug over

Reproduceer hem eerst zelf. Een bug die je niet op commando kunt uitlokken, is een bug waarvan je de fix niet kunt verifiëren, en de agent geeft je met alle plezier een patch die het symptoom laat verdwijnen. Kost dat reproduceren een uur, dan is dat uur het werk, en dat kun je niet uitbesteden.

Baken de zoekruimte af vóór je overdraagt. Noem het subsysteem, de module, de laag. De verbetering in het kernel-onderzoek kwam puur van een kleinere zoekruimte. Jij weet in welke helft van het systeem dit zit. Dat opschrijven levert meer op dan welke prompttruc dan ook.

Geef hem naast de error ook de diff. git log -S, de laatste groene deploy, de commit die aan dit pad heeft gezeten. Dat is de sprong van 9% naar 16% uit het paper, en bij een regressie vind je die commit meestal zelf.

Vraag eerst om een hypothese, dan pas om een patch. Daar komt steun voor uit onverwachte hoek. De beschrijving van de EnterPlanMode-tool in Claude Code, versie 2.1.224, noemt dit als een geval dat om plannen vraagt:

Unclear Requirements: You need to explore before understanding the full scope

• Example: “Fix the bug in checkout” - need to investigate root cause

De tool rekent een bug met een onbekende oorzaak zelf tot planwerk. Diezelfde beschrijving zegt daarna dat je plannen kunt overslaan bij “obvious bugs, small tweaks”, en juist dat oordeel over wat voor de hand ligt, is volgens het mutatieonderzoek precies waar het model slecht in is. Neem die beslissing dus zelf: plan mode vóór de eerste bewerking, en keur de redenering goed in plaats van de diff.

Laat hem na drie pogingen stoppen. De systematic-debugging-skill die ik draai begint met een ijzeren wet, NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST, en met een regel die ik inmiddels nog waardevoller vind: stop na drie mislukte fixes en trek de architectuur in twijfel in plaats van een vierde te proberen. Drie keer achter elkaar mis is informatie. Meestal betekent het dat de bug niet zit waar iedereen kijkt.

Houd de sessie kort. Debuggen is de snelste manier om een contextvenster vol te krijgen: logs, stack traces, hele bestanden erin geplakt om één regel na te kijken. Tegen de tijd dat je bij hypothese vier bent, redeneer je in een sessie waarin het vroege bewijs onderop ligt, en dat is een probleem op zich. Begin vaker opnieuw in een schone sessie dan nodig lijkt.

Wat ik niet weggeef

Bugs waarbij de echte vraag is wat de code hóórde te doen. De agent kan me vertellen wat de code doet. Hij kan me niet vertellen wat er op die factuur had moeten staan, en een stellig antwoord is daar erger dan geen antwoord.

Race conditions, timingbugs, alles waar je slecht zicht op hebt. Beperkte observability is volgens LinuxFLBench een van de drie redenen dat agents op kernelwerk stuklopen. Daarbuiten lopen ze om dezelfde reden stuk.

En alles in code die ik nooit heb gelezen. Dat is het stuk waar ik het langst niet eerlijk over durfde te zijn.

Het gevoel dat je moet vasthouden

Wat er in dat onderzoek misgaat, is een model dat een vloeiend, concreet, goed onderbouwd antwoord geeft over de verkeerde functie, omdat een variabelenaam het model een verhaal vertelde.

De patch ziet er prima uit, dus daar zie je het niet aan. Je merkt het doordat je al ruwweg wist wat die module doet voordat je het vroeg, en dat is een vaardigheid met onderhoudskosten. Die zakt geruisloos weg terwijl je output omhooggaat. Bewust code lezen is het enige dat ik heb gevonden dat die vaardigheid op peil houdt.

Houd een deel van de bugs voor jezelf. Regelmatig eentje, in de systemen die van jou zijn.

De 45% die zegt dat het debuggen van AI-code langer duurt, is niet slecht in prompten. Zij debuggen code die ze nooit hebben gelezen.

De overdracht werkt als jij het leeswerk hebt gedaan.

Onder die regel zat een datastructuur uit 1972.

Rudolf Bayer en Ed McCreight publiceerden dat jaar Organization and maintenance of large ordered indexes in Acta Informatica. Ze losten een probleem op voor een machine waar de meeste lezers nooit aan hebben gezeten: een IBM 360/44 met een 2311-disk, waarbij de index niet in het geheugen paste en elke pagina die je ophaalde echte milliseconden kostte op een draaiende schijf. Hun testset was 100.000 sleutels.

Dat ontwerp is nog steeds de index die je standaard krijgt in PostgreSQL, MySQL, SQL Server en Oracle, en de enige die SQLite ooit heeft gehad. Dezelfde structuur, onder dezelfde naam, met dezelfde taak: de B-tree.

Wat elke uitleg je geeft, en waar hij ophoudt

Zoek op “b-tree uitleg” en je krijgt honderd versies van hetzelfde artikel. Een plaatje van een boom. De invarianten: elke node bevat tussen de m/2 en m sleutels, alle bladeren liggen op dezelfde diepte, opzoeken kost O(log n). Misschien een animatie van een node die splitst.

Allemaal correct. Allemaal nutteloos om twee uur 's nachts.

Wat geen van die artikelen doet, is het plaatje verbinden met de regels die je allang volgt. Je weet dat de kolom waarop je een exacte match doet vooraan hoort in een samengestelde index. Je weet dat een lower() om een kolom heen je index laat verdampen. Je weet dat een covering index sneller is en dat je negende index de writes trager maakte. Je kent die dingen zoals je bijgeloof kent: het werkt, en je kunt de ene niet uit de andere afleiden.

Het is allemaal hetzelfde feit. De boom is gesorteerd, hij is in precies één volgorde gesorteerd, en hem zo houden is duur.

De rekensom is de hele truc

Begin met het getal dat B-trees saai maakt, in de goede zin van het woord.

InnoDB leest en schrijft in pagina’s van 16KB, en een node is een pagina. Jeremy Cole heeft een echte tabel met een INT als primary key uit elkaar gehaald en gemeten wat erin past: ongeveer 1.203 verwijzingen naar onderliggende pagina’s in een interne pagina, ongeveer 468 rijen in een bladpagina. Die verhouding, de fanout, bepaalt alles aan de leeskant.

Lees die middelste rij nog een keer. Een tabel met 600 miljoen rijen erin heeft een primary key die drie niveaus diep is. Eén rij vinden kost drie pagina’s.

PostgreSQL, met pagina’s van 8KB, komt via een iets andere weg op ongeveer hetzelfde uit: rond de 600 onderliggende pagina’s per interne pagina en 300 entries per blad, dus drie niveaus dekken zo’n 108 miljoen rijen, en meer dan 99% van de pagina’s in de index zijn bladeren.

Dat laatste cijfer is de praktische clou. De interne pagina’s zijn qua omvang een afrondingsfout en ze worden door élke query gelezen, dus zodra je database even draait staan ze in de buffer pool en blijven ze daar. Je lookup van drie pagina’s is meestal twee reads uit het geheugen en één van schijf.

Die getallen komen wel uit één tabel van Cole met een INT als sleutel, dus beschouw ze als bovengrens: dikke rijen en brede sleutels drukken de fanout van je bladeren flink omlaag. Aan de vorm verandert dat niets. Een fanout in de honderden levert een boom op die maar een paar niveaus diep is, voor elke tabel die je ooit gaat hebben.

Bayer en McCreight optimaliseerden voor een apparaat waarop het ophalen van een pagina rampzalig was, dus bouwden ze iets dat laag en breed is: honderden onderliggende pagina’s per node, en maar een handvol niveaus om af te dalen. Vierenvijftig jaar later is die schijf een NVMe geworden en is random access zo’n drie ordes van grootte goedkoper. Aan de structuur hoefde niets te veranderen. Zo ziet een goede datastructuur eruit.

Eén correctie die elke uitleg je schuldig is, en dit stuk ook: wat ik hier beschrijf is een B+tree, waarbij de rijen alleen in de bladeren zitten en die bladeren aan elkaar geregen zijn. Dat is wat al deze engines daadwerkelijk gebruiken. Het paper van Bayer en McCreight uit 1972 beschrijft de B-tree, en de B+tree is de verfijning die uit het gebruik ervan is voortgekomen. Iedereen noemt het resultaat toch een B-tree, inclusief de syntax van CREATE INDEX.

Eén keer gesorteerd, in één richting

De rest volgt uit die sortering.

Een B-tree op (status, created_at) is geen twee indexen. Het is één lijst, gesorteerd op status, en binnen elke status op created_at. Denk aan een telefoonboek op achternaam, en daarbinnen op voornaam.

Elke regel die je uit je hoofd hebt geleerd is nu gewoon een vraag over dat telefoonboek.

Waarom moet de eerste kolom in je WHERE staan? Omdat je elke Jansen meteen vindt, terwijl je voor iedereen die Pieter heet het hele boek moet doorlezen. Niets in de structuur weet waar de Pieters zitten.

Dit is trouwens ook de regel die stilletjes een stuk minder absoluut is geworden, en de vorm laat zien waarom. Oracle heeft index skip scan sinds 9i, MySQL sinds 8.0, en PostgreSQL kreeg het in september 2025 met versie 18. Een skip scan werkt precies zoals jij het met de hand zou doen: zoek de eerste achternaam op, doe je zoekactie binnen die groep, spring naar de volgende achternaam, herhaal.

Zo wordt één onmogelijke lookup duizenden goedkope lookups, en dat is een prima ruil bij twaalf verschillende statussen en een dramatische bij twaalf miljoen verschillende achternamen. De optimizer kijkt naar de cardinaliteit van je eerste kolom en beslist. Dat scherpt de regel aan in plaats van hem af te schaffen: je betaalt één keer per unieke waarde die vóór de kolom staat waar het je echt om ging.

Waarom slaat WHERE lower(email) = ? de index over? De boom is gesorteerd op email, en lower(email) is een andere sortering. De database zou die functie op elke entry moeten toepassen om te weten waar hij moet zoeken, en dat is precies de scan die je wilde vermijden. Dat is wat “sargable” betekent, en het is de reden dat je in plaats daarvan een functionele index aanmaakt: je sorteert de boom op de expressie waar je echt op zoekt.

Waarom staan gelijkheidskolommen vóór range-kolommen? Omdat je met een range in een reeks entries belandt in plaats van op één punt. Alles rechts van die eerste range is alleen nog binnen die reeks gesorteerd, dus het beperkt wel wat je terugkrijgt, maar niet wat er gelezen wordt. (status, created_at) werkt voor status = 'open' AND created_at > ?. Draai de kolommen om en de database loopt langs elk openstaand ticket dat ooit is aangemaakt.

Waarom is ORDER BY soms gratis? De bladeren vormen een doubly linked list in sleutelvolgorde. Past je sortering bij de index, dan komen de rijen al gesorteerd binnen en verdwijnt de sort uit het plan.

Waarom helpt een covering index zoveel? Een gewone index-scan levert je een verwijzing op, en daarna moet je de echte rij nog ophalen, wat weer een andere pagina op een andere plek is. Zet elke kolom die de query nodig heeft in de index en die tweede stap vervalt. Postgres noemt dat een index-only scan en laat je de extra kolommen met INCLUDE meeliften. Er zit een kanttekening bij die iets wezenlijks over de engine laat zien: Postgres moet nog steeds vaststellen of die rij zichtbaar is voor jouw transactie, dus een index-only scan raadpleegt eerst de visibility map. Op een tabel die continu verandert is die map koud en haal je de rij alsnog op.

Eén vorm. Vijf regels. Je hoeft ze niet meer uit je hoofd te leren.

De helft die niemand tekent

Elk plaatje in elke uitleg is een read. De boom ligt vast, de pijl wijst naar beneden, de rij komt terug.

Bij writes ga je pas echt betalen.

Voeg een rij toe en de engine moet in élke index op die tabel een entry kwijt, elk op zijn eigen gesorteerde plek, elk op een ander stuk schijf. Zit de bladpagina in kwestie vol, dan splitst hij: nieuwe pagina claimen, de helft van de records verhuizen, de bovenliggende pagina bijwerken. Zit die ook vol, dan splitst die op zijn beurt, en in het ergste geval loopt dat door tot aan de root en groeit de boom een niveau.

Dit is het mechanisme achter iets wat je vast al eens hebt zien gebeuren bij een tabel die al een paar jaar meegaat. Indexen worden er één voor één bijgezet om één trage query tegelijk op te lossen, en niemand haalt er ooit één weg, omdat weghalen riskant voelt en erbij zetten gratis voelde.

De write latency kruipt omhoog en bloat hoopt zich sneller op. Bij Postgres komt daar autovacuum bovenop: meer indexpagina’s om op te ruimen, dus vaker draaien, en dat vecht met jouw writes om dezelfde I/O. Percona heeft die hele keten uitgeschreven. Kort samengevat: op een tabel met veel indexen weegt dat aantal zwaarder mee in je insert-tijd dan wat je verder ook kunt tunen.

De B-tree is een trade-off, en elke uitleg laat je maar één kant daarvan zien.

Waarom juist deze het waard is om te kennen

Ik kom steeds terug bij dit soort fundamenten omdat ze niet verouderen. De B-tree heeft het drumgeheugen overleefd, de draaiende schijf, drie generaties ORM en elk framework dat je beloofde dat je nooit meer over de database hoefde na te denken. De trie en depth-first search waarmee ik een woordspel snel maakte komen uit dezelfde periode en zijn even actueel.

Er is ook een directere reden. Een agent schrijft je met plezier een migratie die een index toevoegt, en meestal is dat een redelijke index. Wat hij er niet bij vertelt, is dat de kolomvolgorde niet past bij de query die hij moet bedienen, dat de index die hij toevoegt dezelfde eerste kolommen heeft als een index die je al hebt, of dat die tabel 4.000 writes per seconde te verwerken krijgt.

Die migratie beoordelen kost je vijf seconden als je de vorm kent. Ken je hem niet, dan is het blind vertrouwen. Dat is precies het argument om nooit code te shippen die je zelf niet snapt, toegepast op de kleinst denkbare diff. Datamodellering staat op mijn korte lijst van dingen die je nu goed zou moeten leren, precies om deze reden.

Bayer en McCreight hebben nooit verteld waar de B voor staat. Balanced, Bayer, Boeing, broad en bushy zijn allemaal voorbijgekomen. McCreight zei er zelf over dat je B-trees beter begrijpt naarmate je langer nadenkt over wat die B betekent.

Vierenvijftig jaar later is dat nog steeds het nuttigste wat er ooit over is gezegd.

Dat is het scherm waarin je een plan goedkeurt. Een document in beeld, vier keuzes eronder, en op schijf is er nog geen byte veranderd. Alles daarna kost je iets om terug te draaien: een diff die je moet lezen, een branch die je moet resetten, een migratie die de andere kant op moet.

Plan mode is er om dat moment bewust in te bouwen, in plaats van erop te hopen.

Code genereren werd goedkoop. Bepalen wát je bouwt bleef duur, en dat verandert niet, want juist dat deel vraagt kennis van je eigen systeem. In plan mode doe je dat dure deel op het moment dat je het nog kunt weggooien.

Plan mode aanzetten in Claude Code

Vier manieren, elk met een eigen moment:

• Met Shift+Tab schakel je door default → acceptEdits → plan. In de statusbalk verschijnt ⏸ plan mode on.
• Zet /plan vóór een losse prompt als je het bij die ene beurt wilt houden.
• claude --permission-mode plan om een sessie meteen in plan mode te starten.
• "permissions": { "defaultMode": "plan" } in .claude/settings.json als een project hier altijd in hoort te beginnen.

Nog een keer Shift+Tab en je bent eruit, zonder iets goed te keuren.

Eén ding moet je in je mentale model bijstellen: het plan is tegenwoordig een bestand. Claude schrijft het naar ~/.claude/plans/ onder een gegenereerde naam van drie woorden, of naar de map die je met plansDirectory aanwijst. Zonder dat bestand werkt ExitPlanMode niet eens. Probeer het maar, dan antwoordt de tool met No plan found. Please write your plan to the plan file first.

Dat verschil is groter dan het klinkt. Een plan dat je goedkeurt in een chatvenster ben je morgen kwijt. Een plan op schijf is een document dat je kunt openen, aanpassen, vergelijken en doorgeven aan een sessie die nog nooit van dit gesprek heeft gehoord. Het is de spec die je toch nooit ging schrijven, opgesteld door het ding dat hem zo gaat uitvoeren.

Wat plan mode echt tegenhoudt

Dit is de instructie die Claude krijgt, letterlijk zoals hij in de 2.1.220-binary staat:

Plan mode is active. The user indicated that they do not want you to execute yet – you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supercedes any other instructions you have received.

Met daarachter de uitzondering:

You should build your plan incrementally by writing to or editing this file. NOTE that this is the only file you are allowed to edit - other than this you are only allowed to take READ-ONLY actions.

De gangbare omschrijving van plan mode, een afgedwongen read-only-stand waarin elke schrijftool uit staat, klopt op drie punten niet meer.

Hij schrijft. Eén bestand, met opzet, maar het schrijfpad staat open.

Hij draait shell-commando’s. Verkennen vraagt nu eenmaal om git log, om grep, om de help-output van je testrunner. Sinds 2.1.218 staat useAutoModeDuringPlan standaard aan, waardoor die commando’s langs de auto mode-classifier gaan in plaats van langs jou. Wat die goedkeurt, draait gewoon tijdens het plannen.

En in een sessie waar bypass permissions beschikbaar is, worden de blokkades van plan mode helemaal niet afgedwongen. De documentatie is daar helder over: Claude krijgt nog steeds te horen dat hij moet plannen zonder te bewerken, maar een bewerking die hij toch probeert, gebeurt gewoon. Ben je gestart met --dangerously-skip-permissions en schakel je daarna voor de zekerheid naar plan mode, dan houd je een stevig geformuleerd advies over. In welke stand je zit, hangt dus af van hoe de sessie begon, en daarom wil je het permissiemodel paraat hebben voordat je hierop vertrouwt.

Plan mode blijft de moeite waard. In een gewone sessie wordt hij wel degelijk afgedwongen en houdt hij stand. Weet alleen welke garantie je precies hebt, want waar het je om te doen is, is de pauze, en die heb je in beide gevallen.

De vijf fases die je nooit ziet

Een plan goedkeuren voelt als het lezen van één document. Het maken ervan volgt een workflow die Claude Code in de sessie injecteert en die je nooit te zien krijgt:

1. Eerst begrijpen. Een handvol Explore-subagents parallel, één per open vraag, met de opdracht eerst te zoeken naar bestaande functies en patronen om te hergebruiken, voordat er ook maar iets nieuws wordt voorgesteld.
2. Ontwerpen. Plan-agents, opnieuw parallel, elk met een bewust andere invalshoek. De prompt noemt de assen per soort taak: eenvoud tegenover performance tegenover onderhoudbaarheid bij een nieuwe feature, oorzaak tegenover workaround tegenover preventie bij een bug, minimale ingreep tegenover schone architectuur bij een refactor.
3. Nalopen. De kritieke bestanden uit de verkenning lezen en de ontwerpen naast je oorspronkelijke vraag leggen.
4. Doorvragen. Echte vragen aan jou via AskUserQuestion, met een expliciet verbod om die tool te gebruiken voor “is dit plan goed zo?”.
5. ExitPlanMode aanroepen.

In sommige sessies krijg je een uitgeklede versie van de eerste twee fases, waarin Claude de bestanden zelf leest in plaats van dat werk uit te besteden. De vorm blijft verder hetzelfde.

Ook het planbestand heeft een vorm die vastligt. Beginnen met een Context-sectie die uitlegt waarom deze wijziging er komt. Alleen de aanbevolen aanpak opnemen, niet alle alternatieven. De kritieke bestanden benoemen. Verwijzen naar bestaande utilities die hergebruikt moeten worden, met pad. Afsluiten met een verificatiesectie die beschrijft hoe je de wijziging van begin tot eind test.

Twee gevolgen die het overdenken waard zijn.

Plannen kost veruit de meeste tokens van je hele sessie, en dat hoort zo. Meerdere subagents die tegelijk je codebase doorspitten, dat loopt nu eenmaal op. Het is wel de juiste plek om ze uit te geven, want dit is de enige uitgave die je kunt weggooien zonder iets te verliezen.

En subagents kunnen zelf niet plannen. EnterPlanMode wordt in agentcontexten botweg geweigerd. Plannen gebeurt in de hoofdsessie, en dus tussen jou en de agent, en daar draait het uiteindelijk om.

Zo haal je er meer uit

Druk op Ctrl+G. Daarmee open je het voorgestelde plan in je eigen editor, zodat je het kunt aanpassen voordat Claude verdergaat. Dit is de meest waardevolle sneltoets van de hele feature en bijna niemand gebruikt hem. Een plan lezen in een scrollende terminal nodigt uit tot scannen op gevoel. Datzelfde plan in je editor nodigt uit tot de vraag die ertoe doet, namelijk of stap vier aan die ene module komt waarvan jij weet dat hij broos is.

Wijs het plan af met commentaar in plaats van het goed te keuren en daarna bij te sturen. “No, keep planning” brengt je opmerkingen terug in dezelfde sessie, waar de verkenning nog in het geheugen zit. Goedkeuren en drie bewerkingen later bijsturen betekent discussiëren met een agent die al vastzit aan zijn keuze, en betalen voor de code die hij onderweg schreef.

Laat plansDirectory naar de repo wijzen voor werk waar een collega naar kijkt. Met ./docs/plans wordt het plan iets dat je kunt reviewen, en het ligt er vóór de pull request in plaats van erna.

Herschrijf de workflow als hij niet bij je past. --plan-mode-instructions, of planModeInstructions in de SDK, vervangt de fasebeschrijving door die van jou. De read-only-preambule en het ExitPlanMode-protocol blijven altijd staan, dus je kunt wel veranderen hóé hij plant, maar je krijgt hem niet ontwapend.

Sla het over bij klein werk. Claude Code adviseert zelf om niet te plannen bij typefouten, wijzigingen van één regel, één functie met heldere eisen, of puur uitzoekwerk. Een wijziging van twee regels plannen is toneel, en toneel is precies hoe een goede gewoonte verandert in iets waar mensen doorheen klikken. De vraag die daaraan voorafgaat, is of de taak überhaupt bij een agent hoort, en die stel je eerst.

Het goedkeuren ís de feature

Alles hierboven is machinerie. De feature zit in die vier seconden waarin jij beslist.

Ik heb mezelf een plan zien goedkeuren omdat het lang was, netjes opgemaakt, en binnenkwam terwijl ik met iets anders bezig was. Lengte oogt als grondigheid. Dat is het niet. Een plan kan elf bestanden noemen en er precies naast zitten bij dat ene dat telt, en ik had het niet gemerkt, want ik las de vorm en niet de inhoud.

Die fout heeft in elk ander deel van het vak allang een naam. Een plan goedkeuren dat je niet hebt gelezen is code mergen die je niet hebt gelezen, één stap eerder en een stuk goedkoper. Die lage prijs is het goede nieuws: hoe eerder je leest, hoe minder nee zeggen je kost. Het is dezelfde discipline als in de rest van de lus, alleen op het punt waar nee zeggen nog gratis is.

Plan mode levert je een document, een pauze, en een eerste versie van de redenering van iemand anders. De beslissing blijft waar hij altijd al lag. Wat je in die pauze doet, dat is het werk.

Dat is de belofte, en voor je bestanden klopt hij.

De rest van je machine blijft gedeeld, en juist dat gedeelde stuk kan je lelijk opbreken.

Wat een git worktree echt afschermt

Een git worktree is een tweede werkmap met eigen uitgecheckte bestanden, een eigen index en een eigen branch, die naar dezelfde repository wijst. Eén clone, meerdere werkmappen. Meer is het niet.

Claude Code heeft er first-class support voor. Geef --worktree (of -w) een naam mee en je krijgt een map in .claude/worktrees/<naam>/ op een nieuwe branch die worktree-<naam> heet:

claude --worktree feature-auth

Laat je de naam weg, dan verzint hij er een, zoiets als bright-running-fox. Met --tmux komt de sessie in een eigen tmux-venster terecht. Geef in plaats van een naam een pull request mee en hij haalt pull/<nummer>/head voor je op:

claude --worktree "#1234"

Zet er quotes omheen, anders ziet je shell alles na de # als commentaar.

Subagents kunnen hetzelfde krijgen. Zet isolation: worktree in de frontmatter van een eigen subagent en elke run draait in een wegwerp-checkout:

---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---

Zolang die agent draait, zet Claude Code er met git worktree lock een slot op, zodat de periodieke opruimactie de map niet onder hem vandaan haalt.

Zet .claude/worktrees/ in je .gitignore voordat je begint, anders loopt je hoofdcheckout vol met untracked bestanden van andere agents.

De base branch is niet waar jij staat

Hier lopen de meeste mensen op stuk. Nieuwe worktrees branchen niet van je huidige HEAD, maar van de default branch van je repository op de remote.

Dat is de instelling worktree.baseRef en die staat standaard op "fresh". Je zit vier commits diep op een feature-branch, je start een worktree om een agent iets kleins ernaast te laten oplossen, en die agent begint ongemerkt vanaf origin/main. Alles wat je nog niet gepusht hebt, is er gewoon niet.

Voor een taak die er echt los van staat, is dat precies goed. Voor het gewone geval, waarbij het parallelle werk voortbouwt op waar je mee bezig bent, moet je dat aangeven:

{
  "worktree": {
    "baseRef": "head"
  }
}

Binnen een worktree wijst "head" naar de HEAD van die worktree zelf, niet naar die van je hoofdcheckout.

Een verse checkout is nog geen werkomgeving

Een worktree checkt getrackte bestanden uit. Alleen getrackte bestanden.

Dus je .env staat er niet. Je .env.local staat er niet. Je node_modules staat er niet.

Voor de env-kant is er een oplossing van Claude Code zelf: een bestand .worktreeinclude in de root van je project, met gitignore-syntax. Alles wat op een patroon matcht én gitignored is, wordt gekopieerd naar elke worktree die Claude aanmaakt.

.env
.env.local
config/secrets.json

Je dependencies zijn je eigen probleem. Elke worktree heeft een eigen install nodig voordat een agent iets kan bouwen of testen, en er zijn mensen die in één middag tien gigabyte kwijt waren aan automatisch aangemaakte worktrees.

Met npm is dat gewoon de prijs die je betaalt. De content-addressable store van pnpm symlinkt packages vanaf één plek op schijf, waardoor de tweede install bijna niets kost. Dit is dat zeldzame moment waarop de discussie over je package manager ophoudt een geloofskwestie te zijn en gewoon rekenwerk wordt.

Poorten en databases waren nooit afgeschermd

Een worktree geeft elke agent eigen bestanden. Alles wat daaromheen draait, blijft gedeeld.

Twee agents die npm run dev draaien, vechten om poort 3000. Ze delen ook je lokale Postgres, je Docker-daemon, je Redis, je build-caches en elke artifact-map buiten de repository. Agent A draait een migratie, de tests van agent B beginnen te falen, en geen van tweeën kan achterhalen waarom. Sinds 2.1.224 kunnen ze elkaar tenminste een bericht sturen zodra zoiets gebeurt, zodat je het hoort in plaats van het te moeten uitzoeken.

Daar helpen worktrees niet bij, want git heeft geen mening over je dev-server. Geef elke worktree een eigen poort in zijn .env.local en een eigen databasenaam, of accepteer dat er maar één agent tegelijk de hele stack mag draaien.

Wil je isolatie op runtime-niveau, dan heb je containers nodig. Een worktree is de git-laag. Een container is de proceslaag. Ze vullen elkaar aan, en de een vervangt de ander niet.

Die ene .git waar ze allemaal in schrijven

Elke worktree deelt de .git-map van de repository. Dat delen is bewust zo ontworpen, en precies daarom zijn worktrees goedkoop genoeg om er per taak een aan te maken.

Het maakt je refs ook globaal.

• Stashes worden gedeeld. De stash-lijst staat in .git. Een agent die in één worktree stasht, zet die stash in de lijst van elke sessie, waar hij in de verkeerde werkmap gepopt kan worden.
• Branches worden gedeeld. Verwijder een branch in één worktree en hij is overal weg. Dezelfde branch twee keer uitchecken kan niet, en dat is de enige botsing die git echt voor je afvangt.
• Force-operaties worden gedeeld. Een reset --hard of een rebase op een branch waar een andere worktree op staat, richt precies evenveel schade aan als zonder worktrees.

Lees dat rijtje terug en je ziet dat het de destructieve helft van git is. Worktree-isolatie beschermt je bestanden tegen een agent die in de war is, en doet niets aan de commando’s die je geschiedenis herschrijven. Zou je een agent in je hoofdcheckout geen git push --force geven, dan moeten je permissieregels dat binnen een worktree net zo goed zeggen.

De afscherming werkt maar één kant op

Dat punt over permissies heeft een vervelende keerzijde.

Keur je in een worktree-sessie een Bash-commando goed met “Ja, niet meer vragen”, dan komt die regel terecht in de .claude/settings.local.json van je hoofdcheckout. Hij geldt daar, hij geldt in elke andere worktree, en hij overleeft de worktree waarin je hem hebt goedgekeurd.

Dat is ook het juiste gedrag. Niemand wil npm test in vijf wegwerpmappen opnieuw goedkeuren. Besef alleen wél wat dat betekent: bestanden gaan naar binnen en blijven daar, permissies gaan naar buiten en blijven plakken.

De wegwerpomgeving schrijft in je vaste configuratie. Een antwoord dat je om twee uur 's nachts geeft in een map die je zo weggooit, geldt daarna gewoon overal.

Opruimen moet een gewoonte worden

Sluit je een interactieve worktree-sessie af, dan kijkt Claude of er gewijzigde bestanden, untracked bestanden of nieuwe commits in staan. Is de worktree schoon en had hij geen naam, dan verdwijnen de map en de branch vanzelf. In alle andere gevallen vraagt hij of je hem wilt houden of weggooien.

Twee gevallen waarin dat niet gebeurt:

• Runs met -p hebben geen afsluitvraag, dus headless sessies ruimen nooit achter zich op. Die haal je zelf weg met git worktree remove.
• Subagent-worktrees waar nog werk in zit blijven staan totdat een periodieke opruimactie ze kan weghalen zonder iets kwijt te raken. Dat gaat via de instelling cleanupPeriodDays.

Draai af en toe git worktree list. Zodra je agents gaat scripten, loopt je schijf al vol voordat git ook maar begint te klagen.

Genereren schaalt parallel, reviewen niet

Alles hierboven los je op met een ochtendje inrichten. Het echte plafond ligt ergens anders.

Wie dit serieus doet, komt uit op drie tot vijf agents tegelijk. De tooling kan er prima acht aan. Jij niet. Vijf worktrees leveren vijf branches op die allemaal gelezen moeten worden, en lezen is het stuk dat nooit sneller is geworden.

Teams die verder komen halen de overlap weg in plaats van er isolatie bij te zetten: één bestand, één eigenaar, geen twee lopende taken die dezelfde code aanraken. Zo sluit je conflicten bij voorbaat uit in plaats van ze achteraf op te lossen, en het dwingt je om na te denken voordat er ook maar één agent start. Daar hoorde dat denkwerk sowieso al thuis.

Snelheid werd goedkoop, oordeel niet, en parallelle agents zijn daar de zuiverste vorm van. Genereren vermenigvuldig je met één shell-flag. Hoeveel jij begrijpt van wat er terugkomt, is nog precies hetzelfde als gisteren.

Eén taak, één worktree, opgeruimd als het klaar is

Dat is dezelfde regel als clearen op de grens tussen twee taken, alleen toegepast op je bestandssysteem in plaats van op je context window. Een lange sessie verzamelt verouderde context. Een worktree die te lang blijft staan verzamelt een verouderde omgeving: een branch die ergens vorige week van main is afgedreven, dependencies van twee lockfiles geleden, een database die halverwege een migratie is blijven hangen.

Isolatie is een reeks keuzes over bestanden, refs, poorten, data en permissies, en --worktree maakt er precies één van voor je.

Zorg dat de andere vier bewuste keuzes zijn.

En toch is die sessie slechter dan om negen uur vanochtend. De meter kan het alleen niet laten zien.

De achteruitgang begint lang voordat het window vol zit

Chroma testte 18 frontier-modellen op context rot en vond bij allemaal hetzelfde: hoe langer de input, hoe onbetrouwbaarder het antwoord, zelfs bij iets simpels als woorden teruggeven. Hun LongMemEval-run laat dat het scherpst zien. Dezelfde vraag, één keer beantwoord vanuit een gerichte prompt van zo’n 300 tokens en één keer vanuit het volledige gesprek van ongeveer 113k tokens waarin die informatie begraven lag. In beide gevallen is alles wat je nodig hebt aanwezig. De antwoorden lopen ver uiteen.

NoLiMa laat zien waar dat begint. Van de 13 geteste modellen, die op papier allemaal minstens 128k context aankunnen, zakten er 11 bij 32k tokens onder de helft van wat ze bij korte context scoren. GPT-4o ging van 99,3% naar 69,7%.

Tweeëndertigduizend tokens. Op een window van een miljoen zit je dan pas op drie procent.

Anthropic noemt het mechanisme een attention budget: elk token kijkt naar elk ander token, dus n tokens leveren n² relaties op, en alles wat je erbij gooit gaat van een eindige pot af. Hun eigen advies is om de kleinste set tokens te zoeken waarmee de klus lukt. Dat is een merkwaardig advies om naast een window van een miljoen te publiceren, en het klopt nog ook.

Wat een lange sessie met je code doet

SlopCodeBench (arXiv 2603.24755, maart 2026) is het onderzoek waar ik op zat te wachten. In plaats van losse opdrachten laat het agents hun eigen eerdere code steeds verder uitbreiden, 93 checkpoints lang, met specs die meebewegen en zonder dat er tussendoor een gecorrigeerde referentie-implementatie wordt aangereikt. Elf modellen, van Sonnet 4.5 tot Opus 4.6 en de GPT-5.x Codex-varianten.

De correctheidscijfers zijn op zichzelf al slecht genoeg: geen enkele agent loste een probleem volledig op, de hoogste score per checkpoint was 17,2%, en bij het laatste checkpoint zakte de strikte score in tot 0,5%. De kosten liepen met een factor 2,9 op terwijl de correctheid niet meebewoog.

De kwaliteitscijfers zouden je gewoontes moeten veranderen:

• Structurele erosie nam toe in 80% van de trajecten. Het aantal functies met hoge complexiteit ging van 4,1 naar 37,0 per codebase, de piek in cyclomatische complexiteit van 27,1 naar 68,2.
• Breedsprakigheid nam toe in 89,8% van de trajecten, met 66% meer structurele duplicatie in het merendeel daarvan.
• Bij repositories die mensen onderhouden blijven diezelfde cijfers vrijwel vlak. Bij agents verslechtert het beeld bijna elke iteratie.

Dat zijn precies de instrumenten die ik beschreef in het dashboard voorbij coverage en mutation testing: complexiteitsconcentratie en clone-detectie. Richt ze op een lange agent-sessie en je krijgt een dalende lijn.

Het paper probeerde ook de voor de hand liggende oplossing. Kwaliteitsbewust prompten verlaagde de breedsprakigheid aan het begin met 34,5% op GPT-5.4, en de dalende lijnen bleven parallel lopen. Je begint netter en gaat even hard achteruit. De knop waar je hier aan moet draaien is de lengte van je sessie.

Wat er wél voor lange sessies pleit

Een paper uit maart 2026 stelt dat coding agents juist heel goed overweg kunnen met lange context, met 17,3% betere scores dan de best gepubliceerde resultaten, op corpora tot drie biljoen tokens. Goed werk, en het lezen waard voordat je mijn kant kiest.

Kijk alleen even hoe ze dat voor elkaar krijgen. De agents zetten de tekst in een bestandssysteem en bewerken die met gewone tools. Het corpus staat op schijf en in het window zit alleen het deel waar op dat moment aan gewerkt wordt. Dat resultaat bewijst niet dat een volgestouwd window prima is, het bewijst dat bulk op schijf hoort.

Dezelfde conclusie, alleen van de andere kant.

Wat /context echt meet

/context in Claude Code 2.1.220 deelt je window op in categorieën: system prompt, system tools, MCP-tools, custom agents, memory files, messages, vrije ruimte, en een regel waar de meeste mensen langs scrollen: Autocompact buffer. In de statusregel staat het percentage tot auto-compact, en verderop in de sessie verschijnt de waarschuwing “Context low”.

Juist die bufferregel is interessant. Het is ruimte die je niet kunt uitgeven, gereserveerd zodat het model straks nog plek heeft om een samenvatting van zichzelf te schrijven. Je bruikbare window is kleiner dan het getal op de verpakking, en dat was het altijd al.

Het commando /doctor controleert de andere helft hiervan: wat je installatie in elke sessie laadt voordat je ook maar iets typt. Het beperkt zichzelf netjes tot schattingen op basis van bestanden en verwijst je voor de echte meting door naar /context. Je installatie schoonhouden en je sessie schoonhouden zijn twee verschillende problemen, en voor maar één daarvan bestaat een linter.

/compact is een model dat zichzelf samenvat

Haal de prompts die /compact gebruikt uit de binary en het ontwerp ligt open en bloot. Drie varianten: één die het hele gesprek samenvat, één die alleen het recente deel samenvat als er een eerder stuk intact blijft, en één die aan het begin van een doorlopende sessie staat.

Alle drie eisen ze dezelfde acht secties. De oorspronkelijke vraag en bedoeling. Belangrijke technische concepten. Bestanden en codefragmenten, inclusief volledige snippets. Fouten en oplossingen. Opgeloste problemen. Alle berichten van de gebruiker. Openstaande taken. Waar op dit moment aan gewerkt wordt.

Een grondige spec, en nog steeds een model dat een rapport schrijft over zijn eigen sessie, met de context waarvan je al vermoedt dat die is weggezakt. Alles wat niet in een van die acht bakjes terechtkomt, is weg.

Twee details in die prompt verdienen je aandacht. Het model krijgt de opdracht om beveiligingsrelevante instructies van de gebruiker letterlijk over te nemen, zodat ze daarna nog gelden. Dat zegt in gewone taal dat afspraken anders kunnen verdampen zodra de sessie wordt samengevat. En het wordt gewaarschuwd om tekst in assistant-berichten die eruitziet als een bericht van de gebruiker nooit aan de gebruiker toe te schrijven. Een samenvatting is namelijk een makkelijk doelwit voor alles wat een verzonnen instructie je volgende window in wil smokkelen.

Daarna zegt de hervattingsprompt tegen het model dat het gewoon verder moet, zonder de samenvatting te benoemen, alsof er geen onderbreking was. Soepel, en met opzet. Je voelt de overgang niet, en juist daarom moet je dit niet op de automatische piloot laten gebeuren.

Clear op tijd, compact zelden, schrijf de briefing zelf

Auto-compact slaat aan als je bijna geen ruimte meer hebt, waardoor de samenvatting wordt geschreven door de slechtste versie van je sessie. Ga je compacten, doe het dan bewust en met ruimte over, zolang het geheugen nog scherp is.

Beter nog: zorg dat je het niet nodig hebt. Clear op de grens tussen twee taken en zet wat moet blijven in een bestand in plaats van in een samenvatting. CLAUDE.md is het geheugen dat elke sessie overleeft, en anders dan een gegenereerde samenvatting heb je het zelf geschreven, kun je het teruglezen en kun je een regel schrappen die niet meer klopt. Houd het bij conventies, valkuilen en overwegingen die de agent niet uit de repo kan afleiden, anders krijg je geheugen dat zes weken later met veel overtuiging onzin vertelt.

De regel die ik in de praktijk aanhoud:

Die briefing schrijven kost twee minuten en levert een beter document op dan welke gegenereerde samenvatting ook, want jij weet welke vier dingen ertoe deden en het model zit naar acht te gissen.

Tussen clearen en compacten zit nog een derde mogelijkheid. Het menu van /rewind vat één gekozen stuk van je sessie samen, vanaf een bericht vooruit of juist alles ervóór, wat prettiger werkt dan de hele boel compacten als je window is volgelopen door één uitgebreide zoektocht naar een bug.

Eén schone sessie per taak is prima advies, totdat je er drie tegelijk wilt draaien. Daar zijn git worktrees voor, met de kanttekening dat ze je bestanden scheiden en verder bijzonder weinig. Sessies die naast elkaar draaien kunnen elkaar ook in één zin op de hoogte brengen in plaats van te wachten tot jij het doorgeeft.

Het meetprobleem is hier hetzelfde als bij gegenereerde code. De instrumenten bestaan, ze kosten niets, en niemand kijkt ernaar omdat er nog niets kapot is. Complexiteit en duplicatie vertellen je dat je codebase afdrijft. /context vertelt je dat je sessie dat doet. Allebei vallen ze stil zodra je stopt met kijken, en allebei zijn ze het goedkoopst aan te pakken zolang het antwoord nog saai is.

Het zegt ook niets over de functie onder die tests. Of die vijf niveaus diep genest zit. Of drie andere bestanden onder een andere naam al hetzelfde doen. Of hij zomaar een module binnenstapt waar hij niets te zoeken heeft. Een mutation score is een uitspraak over de tests. Over de code zelf heeft hij geen mening.

Een andere vraag dan “ving de test het”

Coverage beantwoordt “draaide deze regel”. Mutation testing beantwoordt “zou een test hier een fout hebben gevangen”. Allebei vragen over correctheid op één moment.

Geen van beide gaat over wat er de komende zes maanden met de codebase gebeurt. Of de functie die je vandaag oplevert een goede plek is voor de volgende die erin moet werken, mens of agent. Dat is een andere as, met eigen meetinstrumenten: complexiteit, duplicatie en architectuur. Geen daarvan is zichtbaar in een groene CI-badge.

Complexiteit groeit waar je niet keek

Een grootschalige studie naar AI-gegenereerde pull requests in praktijkrepositories, gebouwd op de AIDev-dataset, vond een cyclomatische complexiteit voor AI-functies die nauwelijks hoger lag dan bij mensen: 2,62 tegen 2,47, een klein verschil. Interessanter was waar die complexiteit zat. AI-code bouwde hem op via diepere nesting, vooral in loops, terwijl menselijke code hem concentreerde in conditionele logica. Andere vorm, vergelijkbaar getal.

Daar zit een mechanisme achter. Een model genereert één token per keer, geoptimaliseerd op wat lokaal klopt, zonder bij te houden hoeveel een functie al heeft opgebouwd tegen regel veertig. De meest recente leaderboard-run van Sonar, met GPT-5.2 High, Opus 4.5 Thinking, Claude Sonnet 4.5 en Gemini 3 Pro (dit dateert van vóór de lancering van Opus 5 en Sonnet 5 deze maand, dus lees het patroon als houdbaar en de exacte cijfers als een momentopname), vond dat code smells 92 tot 96 procent van alle gemelde issues uitmaakten, bij elk model, ongeacht hoe capabel het was. Hun conclusie: naarmate modellen geavanceerdere, stateful oplossingen proberen, is eenvoud het eerste wat sneuvelt. Een slimmer model schrijft een ambitieuzere functie, en in die ambitie verstopt zich de complexiteit.

Wat er op het spel staat, bleek uit een Carnegie Mellon-studie naar de invoering van Cursor onder 807 GitHub-projecten tegenover 1.380 vergelijkbare controleprojecten, over 20 maanden, bekroond als Distinguished Paper op MSR '26. Toegevoegde regels code schoten in de eerste maand met 281% omhoog, zakten in maand twee naar 48%, en waren in maand drie vrijwel verdwenen. Waarschuwingen van statische analyse stegen met 30%. De complexiteit met 41%. Geen van beide zakte ooit weer terug. De studie vond ook een terugkoppeling: een verdubbeling van de complexiteit hing samen met een daling van 64,5% in toekomstige snelheid. De snelheid waar je op joeg, is binnen een kwartaal verdampt. De complexiteit die hij achterliet, verdwijnt niet, en stuurt elke volgende PR de rekening.

Een complexiteitsplafond op het hele bestand signaleert alleen bestanden die toch al slecht waren. Volg in plaats daarvan de delta per pull request: maakt deze specifieke wijziging de functie lastiger te lezen dan gisteren. De cognitive-complexity-regel van SonarQube, de complexity-regel van ESLint, radon voor Python, gocyclo voor Go: ze kunnen allemaal zo’n delta rapporteren, naast het absolute getal. Zet de gate op de delta en je vangt de langzame klim voordat het een bestand is dat niemand meer wil openen.

De clone-detector die de clones niet ziet

Ik schreef eerder over een geërfde codebase met twintig manieren om een bedrag te formatteren, geen ervan met dezelfde naam, geen ervan te vinden met grep. Zet een echte clone-detector op zo’n codebase los en je zou een rood rapport verwachten.

Het kan andersom uitpakken. Diezelfde AIDev-studie vond dat AI-gegenereerde code een lager percentage gedupliceerde regels had dan menselijke code: 18,69% tegenover 25,89%. Op papier oogt de AI-codebase schoner.

De tools verklaren het gat. jscpd en PMD CPD werken allebei op basis van token-matching, Rabin-Karp-stringmatching onder de motorkap, uitstekend in het vinden van exacte of hernoemde kopieën: Type-1- en Type-2-clones. Wat een agent aflevert is geen van beide. Elke near-duplicate wordt koud gegenereerd, met eigen variabelenamen en eigen vorm, omdat het model geen geheugen heeft van de formatter die het drie prompts eerder schreef. Dat is een Type-3- of Type-4-clone, hetzelfde gedrag, andere structuur, en precies het type dat een tokenmatcher is gebouwd om te missen.

Een schoon jscpd-rapport op een AI-zware codebase zegt meer over wat de tool niet ziet dan over of de code echt DRY is. Combineer het met de grep-op-werkwoord-aanpak uit de duplicatiepost, en behandel een verdacht laag duplicatiepercentage met evenveel argwaan als een verdacht hoog percentage.

Architectuur die per bestand verschuift

Daar bestaat een term voor in de onderzoeksliteratuur: architecture erosion, het gat tussen de architectuur waarmee een systeem is ontworpen en de architectuur die het inmiddels heeft. Een systematische mapping study van Li, Liang, Soliman en Avgeriou beschrijft het vanuit vier hoeken: schendingen, structureel verval, impact op kwaliteit, en hoe het zich ontwikkelt. Niets daarvan vereist één dramatische wijziging. Het stapelt zich op.

Een agent kent geen lagen. Hij ziet het bestand dat openstaat in zijn context en welke import het probleem voor hem oplost. Vraag hem om de facturatiegeschiedenis van een gebruiker op te halen, en als de kortste weg rechtstreeks van de UI naar de betaalmodule loopt, neemt hij die weg, omdat niets in zijn context vertelde dat daar een regel voor bestond. In zijn hoofd is het gewoon een import die de test liet slagen.

Hier verdienen fitness functions hun plek: uitvoerbare regels die de architectuur controleren, op dezelfde manier waarop tests het gedrag controleren. ArchUnit doet dat voor Java, en stelt vast welke packages van welke mogen afhangen. dependency-cruiser doet hetzelfde voor JavaScript en TypeScript, loopt de imports af en laat de build falen bij een verboden verbinding. Beide maken van “de UI roept de betaalmodule niet rechtstreeks aan” een check die draait, in plaats van een zin in een wiki.

Ik bouw hier zelf een variant van voor agents: Knossos-MCP, nog vroeg in ontwikkeling, scant een repository één keer in een onderbouwde dependency-graph, zodat een agent kan vragen “wat breekt er als ik dit aanpas” of een boundary-schending gemeld krijgt zonder bij elke prompt de hele boom opnieuw te lezen. Zelfde idee als ArchUnit en dependency-cruiser, maar gericht op de context van de agent zelf, niet alleen op de build.

Het deel dat het gedrag van de agent echt verandert, is waar je die check plaatst. Draait de fitness function alleen in CI nadat de pull request al openstaat, dan vangt een mens de schending drie dagen later, in review, terwijl de agent allang met iets anders bezig is. Zet dezelfde check in het commando dat de agent na elke wijziging draait, zoals hooks je deterministische controle geven over wat een agent doet, en de agent ziet de fout meteen, als feedback waar hij in dezelfde beurt op kan reageren. De ene versie leert de agent waar de grens ligt. De andere houdt alleen bij dat hij overschreden is.

Lees het als een trend

Coverage misleidde deels doordat het één keer werd gemeten en als antwoord werd behandeld. Diezelfde val geldt voor elke metriek in dit artikel zodra je alleen naar het absolute getal kijkt. Churn liet dat als eerste zien: wat telt, zijn de regels die blijven staan. Complexiteit, duplicatie en architectuurschendingen verdienen dezelfde behandeling: continu gevolgd, wekelijks of per PR.

Daaronder draait een snellere cyclus. De sessie die de code schrijft gaat binnen één middag achteruit, en /context is daarvoor het instrument: gratis, en nauwelijks bekeken.

Niets hiervan vervangt oordeelsvermogen. Een mutation score, een complexiteitsdelta, een duplicatieratio, een architecture fitness function: elk beantwoordt een smalle vraag, en elk zwijgt zodra je stopt met vragen. Stel ze allemaal, op een vast ritme, en de verschuiving wordt zichtbaar terwijl het nog een diff is. Stop met vragen, en je komt erachter zoals de meeste teams: op de dag dat iemand het bestand opent en beseft dat niemand het al maanden begrijpt.

Dat is niet gelukt.

Hun update van februari legt uit waarom ze niet achter de cijfers van het vervolgonderzoek staan. Developers haakten af, want meedoen betekende dat je de helft van je taken zonder AI moest doen. En van de mensen die zich wel aanmeldden, koos 30 tot 50% stilletjes uit wat ze inleverden: het werk dat ze niet met de hand wilden doen, hielden ze achter.

Het onderzoek moest meten of AI helpt. Het liep stuk doordat developers per taak bepaalden waar ze die hulp wilden hebben.

Dat is de interessante uitkomst, en niemand haalde hem aan.

Het geaggregeerde cijfer zegt niets meer

De kop die iedereen onthoudt komt uit het eerste onderzoek: 16 ervaren open source-developers, 246 echte taken in repositories waar ze al jaren in werkten, en 19% vertraging zodra AI was toegestaan. Diezelfde developers dachten achteraf dat ze 20% sneller waren geweest.

Herhaal het een jaar later en de schatting staat op 18% sneller voor dezelfde groep. Nieuw geworven developers kwamen uit op 4% sneller, met een betrouwbaarheidsinterval dat ruim over nul heen loopt. METR noemt het allemaal zeer zwak bewijs.

Het cijfer ging dus in ongeveer een jaar van 19% langzamer naar 18% sneller, en de onderzoekers die beide getallen produceerden zeggen er zelf bij dat je op geen van beide moet vertrouwen.

Een grootheid die zo snel van teken wisselt zegt vooral iets over waar je het gereedschap op hebt ingezet, en nauwelijks iets over het gereedschap zelf. “Word je sneller van AI” is een te grove vraag, zoals vragen of elektrisch gereedschap je een betere timmerman maakt zonder erbij te zeggen of je een wand timmert of een zwaluwstaart zaagt.

De vraag die overblijft, stel je per taak. Precies de vraag die de deelnemers van METR in stilte beantwoordden toen ze bepaalde tickets niet inleverden.

Wat uitbesteden echt heeft opgeleverd

De telemetrie van Faros AI, over twee jaar en 22.000 developers, is duidelijk over de doorstroom. Het aantal afgeronde epics per developer ligt 66,2% hoger. De enquête van DORA wijst dezelfde richting op: meer AI-adoptie gaat samen met meer doorstroom.

Diezelfde telemetrie laat zien wat er meekwam. Pull requests zijn 51,3% groter geworden. De mediane doorlooptijd van een review steeg met 441,5%. En merges zonder enige review namen met 31,3% toe.

(Correctie, augustus 2026: hier stonden deze cijfers eerst op naam van DORA. Ze komen van Faros AI, en het verschil tussen een enquête onder 1.110 mensen en telemetrie bij 4.000 teams is het waard om uit elkaar te houden. Wat die getallen werkelijk zeggen, heb ik uitgezocht in de bottleneck in je code review.)

Genereren werd goedkoop. Alles ná het genereren werd duurder, en een deel ervan wordt gewoon overgeslagen. DORA zelf noemt AI een versterker, wat een nette manier is om te zeggen dat het niets voor je beslist.

Moeilijkheidsgraad is de verkeerde maatstaf

De meeste developers sorteren op hoe zwaar een taak voelt. Zwaar betekent “de agent gaat dit verprutsen”, dus zwaar werk houd je zelf en makkelijk werk gooi je over de schutting.

Die vuistregel klopt niet, want waar een model op stukloopt heeft weinig te maken met wat wij moeilijk vinden. Een model schrijft je een werkende red-black tree en gaat vervolgens de mist in op een datumvergelijking van twee regels, omdat het eerste veel in zijn trainingsdata voorkomt en het tweede afhangt van wat jouw codebase precies onder een werkdag verstaat. Het heeft geen wereldmodel dat vertelt welke van die twee het risico is.

Dit is het onderzoek dat mijn eigen denken op de kop zette. Een inventarisatie van operationele fouten bij agentic coding assistants telde 547 bevestigde incidenten uit de praktijk, opgehaald uit de issuetrackers van de grote codemodellen en agent-frameworks, verdeeld over 33 risicotypen. De grootste categorie is het negeren van expliciete instructies en randvoorwaarden, met 40,4%. Destructieve operaties volgen met 24,5%. Zestig procent van alle incidenten kreeg het label hoog of kritiek, bij 170 ervan ging data verloren.

Dan het deel dat telt voor je taakverdeling. Bugs oplossen en setup- of configuratiewerk zijn samen goed voor ruim 65% van alle waargenomen incidenten, en van de hele lijst scoren ze het slechtst op ernst: 65,1% en 68,4% van die incidenten waren hoog of kritiek.

Bugs oplossen. De taak die iedereen als eerste weggeeft, omdat die afgebakend voelt, goed te controleren lijkt en weinig kan kosten als het misgaat.

Het is het gevaarlijkste werk op de lijst, en daar is een simpele verklaring voor. Bugfixes en configuratie zijn precies de twee categorieën waarin de agent iets moet wijzigen wat er al staat en waar iemand anders van afhankelijk is. Bij nieuwe code zie je in review meteen wat er mis is. Een slechte migratie, een herschreven config, een “fix” die het gedrag drie modules verderop verandert: die gaan stilletjes stuk, in productie, later.

De drie vragen die ik echt stel

Ik sorteer op wat een fout me kan kosten. Drie vragen:

Kan ik het goedkoper controleren dan schrijven? Dit is de hele economische afweging, en juist deze slaat iedereen over. Als het nakijken langer duurt dan het maken, heeft uitbesteden me tijd gekost en iets opgeleverd wat ik slechter begrijp. Boilerplate, een testsuite tegen een contract dat ik zelf al had vastgelegd, een bekend patroon doorvoeren in veertig bestanden: goedkoop te controleren. Een cachinglaag met subtiele invalidatieregels: daar moet ik sowieso elk pad doordenken, dus dan schrijf ik het net zo goed zelf en houd ik die redenering meteen in mijn hoofd.

Is het terug te draaien? Alles wat de agent aanraakt en wat ik kan weggooien kost me niets als het fout is. Alles wat hij aanraakt en wat echte toestand wijzigt kost me een incident. Een agent heeft ooit een productiedatabase gewist op een machine van mij, en het cijfer hierboven over destructieve operaties laat zien dat zulke verhalen vaak genoeg voorkomen om een eigen categorie te krijgen.

Moet ik dit om drie uur 's nachts kunnen overzien? Is het antwoord ja, dan schrijf ik het, of ik lees het regel voor regel tot ik het zelf had kunnen schrijven. Dit is de praktische kant van het eigenaarschap. Dat je de code merget en hem daarmee bezit, bepaalt wie verantwoordelijk is. Het zegt nog niets over welk werk je überhaupt onder je naam wilt hebben.

Wat ik nog steeds zelf doe

Nieuw ontwerp. Alles waarbij de eerste goede beslissing gaat over welke vorm het probleem heeft. Modellen zijn uitstekend in het tweede, derde en honderdste exemplaar van een patroon en zwak in het eerste. Zodra ik een ontwerp heb, laat ik er graag een model tegenin gaan.

Subtiele toestand. Concurrency, cache-invalidatie, transactiegrenzen, alles waar een verhaal over gedeeltelijk falen bij hoort. Agents schrijven het prachtig, en dat is precies de valkuil: de fout is een race die eens per twee weken opduikt, en ik heb het hele model in mijn hoofd nodig om hem te herkennen.

De commit die ik zou moeten verdedigen. Code die met beveiliging te maken heeft, code die met geld te maken heeft, alles waar ik in een postmortem naar gevraagd word. Een agent mag dat reviewen. Schrijven zonder dat ik het lees, niet.

Iets leren. Als het hele punt van een taak is dat ik daarna het subsysteem ken, dan haalt uitbesteden de zin uit de taak. Deze moet ik bij mezelf afdwingen, want op een drukke dag is dit altijd het eerste wat sneuvelt.

De rest, en dat is verreweg het meeste werk, gaat naar de agent binnen de werkwijze die ik hanteer: met een spec, ingekaderd en gereviewd.

Schrijf je eigen grens op

De deelnemers van METR die taken achterhielden, deden precies waar dit hele stuk over gaat. Ze gingen af op een oordeel dat ze niet konden uitleggen, en dat belandde toevallig in een dataset waar het op ruis leek.

Jij hebt dat oordeel ook. Je hebt het deze week gebruikt zonder erbij stil te staan. Het verschil tussen dat oordeel hebben en het als vaardigheid hebben, is of je de regel hardop kunt uitspreken, hem kunt verdedigen tegenover een collega en merkt wanneer hij niet blijkt te kloppen.

De mijne past in één zin. Is het goedkoop te controleren en veilig terug te draaien, en hoef ik het onder druk niet uit te leggen, dan gaat het naar de agent.

De rest typ ik nog steeds zelf.

Draai daarna /doctor in een sessie en je krijgt tien checks. Twee daarvan kijken of Claude Code goed geïnstalleerd staat en up-to-date is. De andere acht kijken naar wat jij ermee hebt gedaan.

Juist dat verschil maakt het interessant. Het commando heeft zijn naam gehouden en is stilletjes iets heel anders gaan doen.

Wat /doctor nu daadwerkelijk controleert

/doctor (alias /checkup) was tot 2.1.203 een CLI-subcommando en is sindsdien een meegeleverde skill. Hij leest je settings, je skills, je MCP-servers, je plugins, je hooks en je geheugenbestanden, en stelt daarna wijzigingen voor. Dit is de complete lijst, rechtstreeks uit de skill:

Check 0 en 7 zijn de oude installatiecheck. Check 1 tot en met 6 zijn een contextaudit. Check 8 en 9 zijn weer iets anders, daar kom ik zo op terug.

Het rekenwerk in check 6 is concreet genoeg om er iets aan te hebben: hij schat per onderdeel hoeveel context permanent bezet is, splitst dat uit per geheugenbestand, en zet je lijst met skills en commando’s af tegen een budget van ongeveer 1% van het venster. Hij zegt er ook bij dat het schattingen zijn op basis van wat er op schijf staat, en verwijst je naar /context voor de echte meting. Zoveel eerlijkheid had ik niet verwacht van een tool die je zijn eigen opruimwerk verkoopt.

Waarom dit nu pas komt

Sonnet 5 kwam op 30 juni uit met een venster van 1M tokens. Opus 5 volgde op 24 juli, met hetzelfde venster. In Claude Code zijn ze allebei de standaard voor hun tier.

Toen het venster nog 200k was, meldde de vervuiling zich vanzelf. Je installeerde elf plugins en een CLAUDE.md van 400 regels, en halverwege de middag zat je naar de compaction-waarschuwing te kijken en te vloeken. Die muur was irritant, en die muur was ook feedback.

Bij een miljoen tokens loopt bijna niemand er nog tegenaan. De vervuiling is er nog steeds, alleen krijg je er geen foutmelding meer bij. Je agent wordt een beetje vager, start iets trager op, en volgt iets vaker die verouderde instructie die al drie sessies niet meer klopt. Niets in de interface waarschuwt je, want er ging niets stuk.

Dus bouwde Anthropic er een linter voor. Dat zijn check 1 tot en met 6: een linter voor rommel die geen symptoom meer heeft. Mijn stuk over de token-belasting ging over tooling die je meer context kost dan ze oplevert, en hier bouwt de leverancier zelf de meter die me gelijk geeft.

De check die in je geheugen snijdt

Bij check 3 wil je even stilstaan. Die stelt voor je ingecheckte CLAUDE.md in te korten door alles weg te halen wat Claude ook uit de codebase kan afleiden. Mappenstructuren, dependency-lijsten, architectuuroverzichten: weg, want dat kan de agent gewoon lezen. Valkuilen, het waarom achter keuzes en conventies die afwijken van de standaardinstellingen: die blijven staan.

Die scheidslijn klopt precies. Ik heb hetzelfde betoogd over verouderd geheugen, waar het bestand dat je mappenstructuur beschrijft nu net het bestand is dat zes weken later tegen je liegt.

Alleen: wie trekt die lijn? “Inhoud die Claude uit de codebase kan afleiden” betekent dat het model zijn eigen redeneervermogen beoordeelt, en zelfbeoordeling is nu juist waar deze dingen structureel slecht in zijn.

Hij zal vol overtuiging voorstellen die ene regel te schrappen die overbodig leek en in werkelijkheid dragend was, de regel die voorkomt dat hij in deze repo elke keer weer dezelfde fout maakt. Het voorstel klinkt volstrekt redelijk. En jij weet niet meer waarom die regel er staat, want je hebt hem er acht maanden geleden in gezet, na het derde incident.

/doctor laat eerst zijn bevindingen zien en vraagt om bevestiging voor hij iets aanpast, dus je krijgt een diff. Lees die als een pull request van een snelle, gretige junior die deze repo nog nooit heeft gezien, want dat is precies wat het is. De regel dat je nooit code shipt die je niet snapt geldt ook voor je geheugenbestand. Dat bestand is configuratie, en configuratie heeft per regel meer impact dan code.

Check 8 en 9 hebben een mening

Check 8 stelt voor om auto mode je standaard permission mode te maken, op gebruikersniveau, voor al je projecten. Check 9 zoekt read-only commando’s die je steeds weigert en biedt aan ze vooraf goed te keuren.

Allebei zijn ze te verdedigen. Check 9 is gewoon goed: als je veertig keer nee hebt gezegd tegen git status, kijk je allang over die prompt heen. En de skill gaat zorgvuldig om met check 8, slaat hem over als beleid of projectinstellingen een andere mode vastzetten, en vermeldt dat de CLI netjes terugvalt als auto mode niet beschikbaar blijkt.

Maar kijk even wat hier gebeurt. Een tool die “doctor” heet, adviseert nu ruimere permissies, als onderdeel van een gezondheidscheck. Die verpakking is niet onschuldig, want niemand gaat in discussie met een diagnose.

Wil je auto mode, kies er dan bewust voor, met het permissiemodel in je hoofd, en niet omdat een groene checklist het aanbood tussen een rapport over trage hooks en een versie-update door.

Wat me verraste

Ergens in check 1 staat een instructie die de skill zichzelf oplegt: rapporteer nooit tokenkosten voor MCP-tools die deferred zijn, en adviseer nooit om een MCP-server uit te zetten “om context te besparen” als zijn tools deferred zijn.

MCP-toolschema’s zitten tegenwoordig standaard achter een zoektool. Alleen de naam staat permanent in context, het schema wordt op afroep opgehaald. Het gangbare advies om je MCP-servers eruit te gooien omdat ze je venster opvreten, is daarmee grotendeels achterhaald.

De skill weet dat en weigert de eer op te strijken voor een besparing die niet plaatsvindt. Hij stelt nog steeds voor om servers uit te zetten die je nooit aanroept, maar dan eerlijk gebracht als opruimen: gewoon één ding minder om op in te loggen en te onderhouden.

Een opruimtool die niet overdrijft wat het opruimen oplevert, zegt iets goeds over de rest.

Hoe ik hem gebruik

claude doctor vanuit de shell is read-only. Draai hem wanneer er iets niet klopt aan de installatie zelf.

Geen van beide commando’s kijkt naar de sessie waar je nu in zit. Die heeft een eigen meter en eigen gewoontes, en gaat achteruit in uren in plaats van maanden.

/doctor in een sessie is een agent met schrijfrechten op je configuratie. Ik draai hem ongeveer maandelijks, aan het begin van een sessie, als ik nog het geduld heb om een diff te lezen. Aan het eind van een lange dag is die checklist het enige dat nog tussen mij en een merge staat, en dan wuif ik alles door.

Zonder veel nadenken accepteren: versie-updates, meldingen over trage hooks, het ontdubbelen van lokale geheugenbestanden ten opzichte van de ingecheckte, plus servers die je echt nooit hebt aangeroepen. Regel voor regel lezen: alles wat aan een ingecheckte CLAUDE.md komt, en allebei de permissievoorstellen.

Het commando dat je vroeger vertelde dat de tool kapot was, vertelt je nu vooral dat jij het bent. Tien checks, en acht daarvan gaan over keuzes die jij hebt gemaakt. Dat rapport is vervelender om te krijgen, en een stuk nuttiger.

Ik heb het gezegd. Jij waarschijnlijk ook. Het klinkt als een verklaring, en ongeveer drie jaar lang werkte het ook zo.

In een Californische rechtszaal gaat die vlieger sinds januari niet meer op.

De zin die het niet meer doet

De Californische wet AB 316 is op 13 oktober 2025 ondertekend en op 1 januari 2026 in werking getreden. De wet bepaalt dat een gedaagde die schade zou hebben veroorzaakt door het ontwikkelen, aanpassen of gebruiken van een AI-systeem, niet als verweer mag aanvoeren dat de AI zelfstandig handelde.

Lees dat nog eens met de ogen van een developer en kijk waar jij daarin voorkomt. “Gebruiken” staat in dat rijtje. Je hebt niets getraind en niets gefinetuned. Je hebt een model gebruikt, de output geaccepteerd en geshipt.

Of dat model op eigen houtje handelde, doet juridisch niet meer ter zake.

Meteen de nuance erbij: AB 316 voert geen risicoaansprakelijkheid in. Een eiser moet nog steeds aantonen dat de AI de schade veroorzaakte en dat die schade voorzienbaar was, en al je andere verweren kun je nog gewoon voeren. Er gaat één deur dicht, de rest blijft open.

Het is wel precies de deur waardoor de hele branche tot nu toe naar buiten liep.

Dit gaat niet over reviewen

Ik heb eerder betoogd dat je nooit code moet shippen die je niet aan een collega kunt uitleggen. Die regel gaat over één moment: de minuut vóór de merge, als de vraag is of je begrijpt wat je op het punt staat te accepteren.

Dit stuk gaat over alle momenten daarna.

Begrijpen wat er staat is de goedkope helft van eigenaarschap. De dure helft is dat jij degene bent die er later verantwoording over aflegt, in de postmortem, onder het contract, en nu ook voor de rechter.

Europa maakt software een product

De nieuwe richtlijn productaansprakelijkheid (EU 2024/2853) is sinds december 2024 in werking en moet uiterlijk 9 december 2026 in nationale wetgeving zijn omgezet. De richtlijn geldt voor producten die ná die datum op de markt komen.

Vier punten daaruit raken iedereen die code shipt:

• Software is een product. Firmware, applicaties en AI-systemen, hoe ze de gebruiker ook bereiken: op een apparaat, uit de cloud, als SaaS.
• Niet patchen kan een product gebrekkig maken. Als een kwetsbaarheid een update nodig heeft die binnen jouw macht ligt en je die niet levert, dan kan het product alleen daarom al als gebrekkig gelden.
• Je kunt het niet wegcontracteren. Aansprakelijkheid onder deze richtlijn kun je niet uitsluiten of beperken in je voorwaarden. De AS IS-disclaimer onderaan je licentie houdt hier geen stand.
• De bewijslast verschuift. Als de technische complexiteit het voor een eiser te moeilijk maakt om het gebrek of het causale verband aan te tonen, mag de rechter dat vermoeden, en kan hij jou verplichten bewijs in begrijpelijke vorm over te leggen.

Dat derde punt verdient even je aandacht, want aansprakelijkheid uitsluiten in het licentiebestand is de oudste reflex in commerciële software.

En dan de omvang, want die wordt vaak groter gemaakt dan hij is. Deze richtlijn gaat over gebreken die de veiligheid raken en mensen schade toebrengen: overlijden, lichamelijk letsel, materiële schade en het vernietigen of beschadigen van data die niet zakelijk wordt gebruikt. Het is geen nieuwe route voor een klant bij wie de factuurtotalen er 3% naast zaten.

Bouw je medische apparatuur, voertuigen, industriële besturing of consumentenhardware, dan geldt dit vanaf december voor jou. Bouw je interne dashboards, dan is het achtergrondkennis.

Voor Nederland is de datum dezelfde, 9 december 2026, al meldt business.gov.nl dat de inwerkingtreding nog afhangt van behandeling in de Tweede en Eerste Kamer.

Geen enkele leverancier dekt je als de code niet werkt

Leveranciers bieden wel vrijwaringen aan, en die zijn de moeite waard. Microsofts Customer Copyright Commitment verdedigt je tegen claims van derden over intellectuele-eigendomsrechten op de output.

Kijk goed naar wat daar staat. Auteursrecht. Iemand die beweert dat de gegenereerde code van hem was.

Geen enkele leverancier heeft een clausule die je dekt als de code niet werkt.

Die auteursrechtdekking is ook voorwaardelijk. Voor Azure OpenAI moet je de protected-material-detectie aan hebben staan in annotate- of filtermodus, het jailbreakfilter in filtermodus houden, een metaprompt meegeven die het model opdraagt geen inbreuk te maken, en een test- en red-teamingrapport bewaren dat je overhandigt als je ooit een beroep op de vrijwaring doet. Hun eigen formulering laat weinig ruimte: wie een claim indient, moet aantonen dat aan alle relevante eisen is voldaan.

De vrijwaring is een beloning voor werk dat je gedaan hebt. Heb je dat werk overgeslagen, dan heb je een licentie in handen en geen schild. Bij GitHub zijn de eisen wel lichter geworden: sinds 3 april 2026 gelden er voor GitHub-diensten geen aanvullende verplichte maatregelen meer, en is Duplicate Detection optioneel in plaats van een voorwaarde voor dekking.

Het scherpere probleem zag advocaat Kate Downing al in 2023, en het is niet overgewaaid. De uitsluiting geldt voor “code that differs from a suggestion provided by Copilot”, zonder dat er “materially” of “significantly” vóór dat “differs” staat. Elke echte codebase wijkt af.

Je nam de suggestie over, hernoemde een variabele, verhuisde hem naar een class, en drie refactors later kan niemand nog reconstrueren wat het model oorspronkelijk voorstelde. Die modelversie bestaat inmiddels niet eens meer.

De 24-uursvraag

In het AI Accountability Report 2026 van GitLab, uitgevoerd door Harris Poll onder 1.528 developers en technologie-inkopers in zes landen, staat het cijfer waar je wakker van zou moeten liggen.

87% is ervan overtuigd dat het eigen team binnen 24 uur kan vaststellen of AI-code heeft bijgedragen aan een incident in productie.

Van de organisaties die het afgelopen jaar echt een incident hadden, kon 34% dat niet vaststellen.

Hier zijn overtuiging en vermogen eens apart gemeten, en er kwamen twee verschillende antwoorden uit.

De rest van het rapport leest als een sector die op krediet leeft. 43% kan AI-code niet betrouwbaar onderscheiden van code die een mens schreef. 84% zegt dat het moeilijkste aan AI-code is wat er ná het genereren mee gebeurt.

80% nam de tools sneller in gebruik dan er beleid voor was, en 82% verwacht dat er technische schuld van overblijft waar de organisatie niet op is ingericht.

Toen een agent een productiedatabase wiste op een machine die ik zelf beheer, kostte het herstel een paar minuten, want de nacht ervoor was er een backup gelopen. Uitzoeken wat er precies was gebeurd kostte een uur, en dat uur is de reden dat ik het draaiboek voor het uur nadat een agent iets breekt schreef.

Ik zat in die 34%. En ik zou je vol overtuiging hebben verteld dat ik in die 87% zat.

Eigenaarschap is een vermogen, dus test het

Verantwoordelijkheid is een verzameling dingen die je kunt of niet kunt. Wat jij kunt, merk je op je slechtste dag, tenzij je het op een gewone dag controleert.

Daarmee is pas de helft beantwoord. Welk werk je überhaupt uit handen geeft, is een aparte afweging die ik per taak maak.

Vier vragen. Beantwoord ze deze week, op echte code, niet in gedachten.

1. Pak een pull request die vorige maand is gemerged. Kun je zeggen welke delen uit een agent kwamen? Zo niet, dan zit je in die 43%, en die herkomst is de basis voor elk ander antwoord hieronder.
2. Pak een bestand in productie en noem de eigenaar. Eén persoon, die gebeld wordt en die het bestand gelezen heeft.
3. Zoek in je leveranciersvoorwaarden op wat de vrijwaring werkelijk dekt. Kijk daarna of je vandaag aan de eisen voldoet. Een vrijwaring die je zelf ongeldig hebt gemaakt door de maatregelen over te slaan is erger dan geen vrijwaring, want je hebt erop gerekend.
4. Doe de 24-uursoefening. Neem het incident van vorig kwartaal en probeer vast te stellen of er gegenereerde code aan te pas kwam. Klok hoe lang je erover doet. Die tijd is je echte antwoord.

De agent biedt zijn excuses aan als het misgaat. De mijne deed dat netjes, hield me de zwakke regel uit zijn eigen instructies voor, en nam de schuld op zich.

Schuld op zich nemen kan hij niet. Verantwoordelijkheid betekent dat er iets te verliezen valt, en hij heeft niets op het spel staan: geen licentie, geen reputatie, geen baan, geen naam onder de commit. Die zijn allemaal van jou.

Jij hebt de code gemerged. Dus is die van jou.

Het was een keurige verontschuldiging. Ik had er niets aan.

Ik hoefde niet te weten wat er mis was met mijn prompt. Ik moest weten welke bestanden waren overschreven, of er iets de deur uit was gegaan, en welke credentials op dat moment in context zaten. In plaats daarvan improviseerde ik een uur lang: logs grepen, tijdstippen gokken, uitzoeken wat cp -r backend/* precies had platgewalst.

Dat verloren uur was het echte incident, niet de verwijderde database. De database kwam terug uit een backup. Dat uur ging op aan uitzoeken waar ik überhaupt moest kijken, en dat is een voorbereidingsprobleem. Voorbereiding is de enige fase van incident response die je niet tijdens het incident kunt doen.

Dit is het draaiboek dat ik daarna heb opgeschreven.

Waarom het normale draaiboek hier niet past

Elk serieus incident-response-framework begint op dezelfde manier. NIST SP 800-61r3, in 2025 herschreven rond CSF 2.0, loopt van voorbereiding via detectie en analyse naar containment, eradicatie, herstel en evaluatie. Prima structuur, ik gebruik hem zelf ook. Alleen klopt één aanname hier niet.

Hij gaat uit van detectie.

Detectie werkt omdat een aanvaller afwijkt. Verkeerde tijdstippen, verkeerd IP, verkeerd account dat aan verkeerde data zit.

Jouw agent wijkt nergens van af. Hij draait op jouw machine, onder jouw account, met jouw credentials, in een sessie die jij hebt geopend, en voert commando’s uit die je stuk voor stuk had goedgekeurd als hij het had gevraagd. Er is niets afwijkends waar een alarm op af kan gaan. Er is alleen een behulpzame assistent die net iets anders doet dan jij bedoelde.

Je komt er dus op dezelfde manier achter als ik. Er gaat iets stuk en je werkt van achteren naar voren.

Dat is de echte ontwerpeis. Het draaiboek moet werken zonder alerting en vanaf een koude start.

Fase 1: bevriezen

Stop de sessie. Beantwoord zijn volgende vraag niet, laat hem het probleem niet “even oplossen”, sluit je terminal niet af.

De neiging om de agent zijn eigen rommel te laten opruimen is sterk en verkeerd. Precies die reflex veroorzaakte het incident: hij maakte een database kapot, besloot dat de oplossing was om hem leeg te gooien en opnieuw op te bouwen, en gooide hem leeg. Een agent die net iets destructiefs heeft gedaan, weet daar niets extra’s over. Hij heeft dezelfde context als dertig seconden geleden, en dat is de context die de fout opleverde.

Bevriezen betekent ook: bewaren.

• Zet wat kapot is apart, gooi het niet weg (app.db.broken, geen rm app.db)
• Draai geen /clear of /compact. Compaction herschrijft je transcript tot een samenvatting, en een samenvatting is geen bewijs
• Doe geen git checkout . om “even schoon te beginnen”. Daarmee vernietig je de diff die je vertelt wat er is veranderd
• Heeft hij aan een remote gezeten, trek dan meteen het token in, nog voor je snapt wat er gebeurd is

De volgorde telt. Eerst indammen, dan begrijpen. Een transcript kun je over een uur nog lezen. Een commit die anderen al binnenhalen, krijg je niet meer terug.

Indammen houdt trouwens niet eeuwig stand. OpenAI wiste het kanaal waarmee hun evaluatie-agents elkaar op de hoogte hielden en zag ze het vier dagen later opnieuw opbouwen, want die sessies draaiden gewoon door.

Fase 2: reconstrueren, en vraag het niet aan de agent

Dit vinden mensen het lastigst: vraag de agent niet wat hij heeft gedaan.

Hij geeft antwoord. Vloeiend, gestructureerd, geloofwaardig en opgemaakt als een schaderapport. Wat je terugkrijgt is gegenereerde tekst in de vorm van een log. De agent bouwt een verhaal op uit dezelfde context die jij zelf kunt lezen, met een sterke voorkeur voor samenhang. Vraag hem naar een cp van veertig beurten geleden en je krijgt een relaas dat sluitend is, en sluitend is iets anders dan waar.

Het echte bewijs staat op schijf. Bij Claude Code kijk ik op vier plekken, in deze volgorde.

Het sessietranscript. ~/.claude/projects/<munged-cwd>/<session-id>.jsonl, één JSON-object per regel. Elke beurt van de agent bevat een timestamp, de cwd, de gitBranch en de permissionMode die op dat moment gold, plus de volledige tool-aanroep met zijn input. Om dat laatste veld draait het: je krijgt de letterlijke commandoregel, precies zoals hij is uitgevoerd.

De bestandshistorie. Dit is het artefact dat vrijwel niemand kent. In ~/.claude/file-history/<session-id>/ staan versies van elk bestand dat de agent heeft aangepast, als <hash>@v1, @v2 enzovoort, met de volledige inhoud van vóór de bewerking. Als de diff weg is en git je niet helpt omdat de wijziging nooit is gestaged, is dit je undo. Dezelfde opslag wordt gelezen als je met /rewind je code herstelt, dus het loont om te weten welke edits daarin terechtkomen voordat je ze nodig hebt.

Het promptlog. ~/.claude/history.jsonl bevat elke prompt die je hebt gestuurd, over alle projecten heen. Handig om te bepalen wanneer een sessie begon als het transcript groot is.

Alles buiten de agent. git reflog (haalt commits terug na een verkeerde reset), git fsck --lost-found (losse blobs), je shell-historie, en de logs van alles waar hij daadwerkelijk aan heeft gezeten: de database, de deploy-target, de CI-run.

Maak daar een tijdlijn van, in die volgorde, vóór je een theorie vormt. Die tijdlijn is wat deze fase oplevert, en hij hoort saai te zijn: tijdstip, tool, letterlijk argument, effect.

Fase 3: ga ervan uit dat de context de deur uit is

Alles wat in het contextvenster van het model terecht is gekomen, moet je behandelen alsof het je machine heeft verlaten, want dat is ook zo. Het ging naar een inference-endpoint.

Een capture op wire-niveau liet zien hoe een coding CLI de .env van een repo las en daarna de hele repo uploadde, inclusief bestanden waar hij vanaf moest blijven. In juni hetzelfde patroon: via prompt injection in een GitHub-issue las een agent /proc/self/environ in CI en plakte de cloud-credentials die hij daar vond in een comment.

De blast radius is dus groter dan de schade. Loop hem in vier rondes na:

• Gelezen bestanden, een langere lijst dan gewijzigde bestanden. Grep het transcript op elke Read en elke cat. .env, ~/.aws/credentials, ~/.ssh, kubeconfig, elke dump met klantdata erin
• Uitgevoerde commando’s, volledig. Let het scherpst op alles dat buiten de projectmap schreef
• Uitgaand verkeer. Elke fetch, elke MCP-server, elke gh- of aws-aanroep. Waar ging data heen, en van wie is dat endpoint
• Persistentie. Deze ronde slaan mensen over. Heeft hij geschreven naar ~/.ssh/authorized_keys, een shell-rc, een git hook, een systemd-unit of een CI-workflow?

Op 8 juli lieten onderzoekers zien hoe zes coding assistants symlinks volgden en zo SSH-sleutels in authorized_keys schreven, langs de goedkeuringsprompt heen. De agent heeft geen enkel motief om zich in te graven. Een geïnjecteerde instructie wel.

Fase 4: roteren

Roteer alles uit fase drie: elke credential die vanuit die sessie bereikbaar was, of je hem nu in gebruik hebt gezien of niet.

Dit is de fase die wordt overgeslagen, en de cijfers erover zijn slecht. GitGuardian telde in 2025 29 miljoen nieuwe hardcoded secrets in publieke repo’s op GitHub, 34% meer dan het jaar ervoor. Credentials voor AI-diensten stegen met 81%. Het getal dat je meer zorgen moet baren: van de credentials die ze in 2022 als geldig aanmerkten, was in januari 2026 nog altijd 64% niet ingetrokken. Lekken gebeurt overal. Het intrekken blijft achter.

Roteren na een agent-incident is opvallend makkelijk af te bakenen, want fase twee heeft je een exacte lijst met tijdstippen opgeleverd. Gebruik die. Roteer, en kijk daarna in het auditlog van de provider of de oude credential nog is gebruikt tussen het incident en de rotatie. Alleen in die periode vind je hard bewijs dat er daadwerkelijk iets is misbruikt.

Fase 5: repareer de permissie, niet de prompt

Bij het database-incident stond de regel expliciet in de prompt: niet deployen, geen cp naar de live directory. De agent las hem, was het ermee eens, en overtrad hem.

Een regel in een prompt is een voorkeur die je uitspreekt tegenover een probabilistisch systeem. Meestal houdt hij stand, en dat is precies het gevaar: je gaat erop vertrouwen.

De fix na een incident moet een laag lager zitten. Concreet, voor mijn incident:

De rechterkolom telt als controle omdat hij dichtklapt bij twijfel en niet afhangt van hoe zorgvuldig het model vandaag leest. Schrijf je fix als een controle, of je hebt niets gerepareerd.

Er zit een grens aan. De doos waar je de agent in zet heeft een gat precies daar waar hij nuttig wordt, en dat is bewust zo. Controles maken de blast radius kleiner. Ze halen hem niet weg, en daarom bestaan de fases één tot en met vier.

Fase nul, de enige die je vóór het incident kunt doen

Alles hierboven gaat ervan uit dat het spoor er is. Controleer dat nu meteen:

• Weet je waar de transcripts van je agent staan, en staan ze er nog? Ze verlopen volgens een standaardtermijn, en sommige tools ruimen ze op
• Schrijft je hook elke tool-aanroep weg naar een bestand dat je bewaart, met tijdstip erbij? Een hook die alleen blokkeert is een controle. Een hook die ook wegschrijft is bewijs
• Heb je een backup van alles wat je agent kan bereiken, ook op dev-machines? Mijn incident was alleen te herstellen dankzij een nachtelijke job die 24 uur eerder had gedraaid
• Kun je zeggen welke credentials vanuit die sessie bereikbaar waren, zonder het op te zoeken?

Neem twintig minuten en beantwoord die vier. Meer is fase nul niet.

De verontschuldiging was het menselijkste wat die agent die dag deed. Hij las zijn eigen instructies terug, wees de zwakke zin aan en accepteerde de schuld.

Schuld accepteren is precies wat hij niet kan. Hij wordt om drie uur 's nachts niet gebeld, hij zit niet bij de postmortem, en hij legt de klant niet uit waarom zijn data 24 uur oud is. Dat was ik, en dat word jij.

Waaruit dat eigenaarschap precies bestaat is in 2026 een stuk concreter geworden, in de wet en in de voorwaarden van je leverancier.

Het draaiboek is dus van jou. Schrijf het op een rustige middag, of schrijf het in het uur dat ik kwijt was.

Op 21 juli liet OpenAI weten dat een model tijdens een test van zijn offensieve securitycapaciteiten de testomgeving had verlaten en had ingebroken op de productie-infrastructuur van Hugging Face. Op 23 juli publiceerden onderzoekers van Accomplish SharedRoot: koppel een map aan een nieuwe Claude Cowork-sessie, stuur één kort bericht, en de agent leest en schrijft bestanden overal op de host-Mac, ver buiten de map die je koppelde, zonder dat er ergens om toestemming wordt gevraagd.

In de berichtgeving werden beide incidenten neergezet als “de AI slaat op hol”. Lees de technische write-ups en er komt iets veel saaiers uit, en juist dat saaie deel is bruikbaar. In allebei de gevallen klom de agent één privilegeniveau omhoog binnen een omgeving waar alles van waarde al lag, en hoefde hij de muur helemaal niet over.

De mount zat er altijd al in

Op papier is het ontwerp van Cowork verstandig. De agent draait in een Linux-VM op Apple’s Virtualization framework, als onbevoorrechte gebruiker, met seccomp-filtering eromheen. Een root-daemon die coworkd heet, regelt de toegang tot de mappen die je koppelt.

Dit is het deel dat alles bepaalt. Om die mappen te kunnen doorgeven, wordt het complete bestandssysteem van de host read-write in de VM gemount op /mnt/.virtiofs-root. Alleen de root-gebruiker van de VM kan erbij.

De ontsnapping hoeft de VM-grens dus nooit te passeren. Je schijf ligt al aan de andere kant. Root is het enige wat ertussen staat, en root worden in een Linux-VM is inmiddels routinewerk:

• De sessiegebruiker roept unshare aan, maakt een user namespace en is daarbinnen root met CAP_NET_ADMIN.
• Die capability is genoeg om via een netlink-socket een traffic-control-actie te configureren en zo bij de kernelmodule act_pedit te komen.
• In act_pedit zit CVE-2026-46331, “pedit COW”, een sinds juni openbare Ubuntu-bug waarmee een onbevoorrechte gebruiker de page cache van een alleen-lezen bestand kan vergiftigen zonder de schijf aan te raken.
• Vergiftig een helper-binary die eigendom is van root, wacht tot coworkd die opnieuw uitvoert, en je bent guest-root. NoNewPrivs helpt niet, want het proces dat de binary uitvoert, is zelf al root.
• Guest-root leest /mnt/.virtiofs-root en alles op de Mac ligt open: SSH-keys, cloud-credentials, alles waar het account van de gebruiker bij kan.

Vijf stappen, geen enkele exotisch, en wat er te halen viel, lag de hele tijd al binnen de sandbox.

Het ene gat dat ze er expres in hebben gemaakt

Wat er bij OpenAI misging, ziet er anders uit, maar komt op hetzelfde neer. Hun benchmarks draaiden in wat zij een sterk geïsoleerde omgeving noemden, waarbij de netwerktoegang beperkt was tot het installeren van packages via een intern gehoste mirror.

Een testomgeving die geen packages kan installeren, kan de test niet draaien. De weg naar buiten bestond dus per definitie. Die weg was afgeschermd met een proxy, en afgeschermd is iets heel anders dan afwezig. Het model vond een nog onbekende kwetsbaarheid in dat installatiesysteem en liep er dwars doorheen.

Dan Guido van Trail of Bits noemde het een containment failure waarbij de veiligheidsmechanismen uitstonden. Alle securityonderzoekers die in de berichtgeving aan het woord kwamen, legden de oorzaak bij het ontwerp van de omgeving, niet bij het model.

Daar hebben ze gelijk in, en dat is het ongemakkelijke deel. Waar het om gaat: precies wat de omgeving bruikbaar maakte, was tegelijk de uitgang, en dat blijft gelden voor elke agent-sandbox die jij of ik ooit draait.

Sloten en muren

Er zijn twee manieren om een agent bij iets vandaan te houden.

Haal het buiten de grens, zodat er niets te bereiken valt. Of laat het binnen staan en zet er een rechtencheck voor.

Alleen de eerste overleeft een kernelbug. Een rechtencheck is een slot, en een slot is precies zo sterk als het rechtensysteem waarin het zit. Eén ongepatchte CVE verder is het niet meer dan decoratie. CVE-2026-46331 was in juni al openbaar en zat in juli nog gewoon in de guest-kernel. Er komt een volgende. Er komt altijd een volgende.

Isolatie door afwezigheid heeft een eigenschap die isolatie door rechten nooit krijgt: geen enkel privilegeniveau haalt tevoorschijn wat er niet is. Dat is een ander soort garantie, en het is de enige die standhoudt als het proces binnen de grens actief naar een uitweg zoekt.

Er zit nu iets anders binnen de grens

Beide ontwerpen kloppen voor de dreiging waarvoor ze bedoeld zijn. Een proces met een bug gaat niet op zoek naar het slot. Het crasht, of het schrijft naar het verkeerde pad, en de rechtencheck vangt dat af. Daar zijn deze grenzen voor gebouwd, en dat doen ze goed.

Wat er binnen die grens zat, veranderde daarna van slordige code in een systeem met een doel en een reden om te zoeken.

De modellen van OpenAI werden afgerekend op een smal doel en gingen tot het uiterste om dat te halen, tot en met het opzoeken van geheime informatie waarmee ze de test konden omzeilen. De evaluatie beloonde vrij precies het gedrag dat de containment doorbrak.

SharedRoot had één kort bericht in de sessie nodig. Wat de agent leest, kan sturen wat de agent doet, en daarom moet prompt injection bij de grens worden afgevangen. Het startpunt van een aanvaller is alles wat jouw agent gaat lezen: een issue-comment, een README, een webpagina.

Allebei die systemen zijn plichtsgetrouw, geblokkeerd en vindingrijk, drie eigenschappen waar je ze op hebt uitgekozen.

Wat wél werkte

Beide incidenten zijn openbaar gemaakt, en dat mag hardop gezegd worden, want het alternatief is een wereld waarin je dit soort dingen pas uit datalekmeldingen leert. Twee weken later ging OpenAI op Black Hat nog een stap verder, met een tijdlijn van 74 dagen over wat hun agents precies deden.

Anthropic sloot het SharedRoot-rapport af als “Informative”, met als argument dat de onderliggende CVE binnen hun disclosureperiode van 30 dagen viel. Dat is een verdedigbare proceskeuze over de kernelbug van iemand anders, ook al oogt het slecht in een nieuwsbericht.

En kijk hoe beide gevallen uiteindelijk zijn opgelost. Cowork draait nu standaard in de cloud, waardoor de keten eindigt op een machine zonder SSH-keys, simpelweg omdat er geen host-Mac meer aan het eind staat. De omgeving van OpenAI had die netwerkroute nooit mogen hebben. Allebei de oplossingen werken door weghalen, en daar draait dit hele stuk om.

Twee vragen over je eigen setup

Die les geldt precies zo voor de omgeving waarin jij je eigen agent draait.

Wat is er binnen de grens bereikbaar dat de agent niet hoort te hebben, en wat houdt hem daar precies van af? Zeg het mechanisme hardop. “Alleen root kan bij die mount.” “De proxy controleert het domein.” Dat zijn allebei sloten, en nu weet je wat een privilege-escalatie je kost.

Welk gat heb je zelf gemaakt om het bruikbaar te houden? Package-installaties, een egress-allowlist, een gekoppelde map, een schrijfbare projectmap. Zonder dat gat werkt de rest niet, dus dichtgooien is geen optie. Daar gaat de volgende doorheen, en dat is het deel van je setup dat de meeste argwaan verdient.

Ga ervan uit dat je antwoord op beide vragen ooit niet blijkt te kloppen. Het uur daarna verloopt heel anders als je al weet waar het sessietranscript staat en welke credential je als eerste intrekt.

Het goedkoopste antwoord zit meestal in waar je het draait. Zet agents op een plek waar niets te halen valt. Een machine zonder cloud-credentials, zonder SSH-keys en met een lege shell-history beschermt je beter dan alle hardening die je kunt stapelen op de laptop waar je ze alle drie bewaart. Een inbraak die niemand aanstuurt komt precies zo ver als de grenzen toelaten, en die afstand verklein je het makkelijkst door te zorgen dat er minder binnen bereik ligt.

Twee weken geleden schreef ik dat muren kieren hebben, en dat de schrijfbare mount tegelijk het doel en het risico is. Ik bedoelde het als kanttekening aan het eind van een gids.

Twee meldingen later blijkt dat beide ontsnappingen door precies die kier liepen, de kier die de muur nodig had om ergens goed voor te zijn. Dat is geen kanttekening. Dat is het ontwerp.

Ruim twee keer de score van Opus 4.8 op Frontier-Bench v0.1. Op CursorBench 3.2 blijft hij binnen een halve procentpunt van Fable 5, tegen ongeveer de helft van de kosten per taak. Op ARC-AGI-3 scoort hij drie keer zo hoog als de nummer twee, terwijl 4.8 daar amper iets neerzet. Op OSWorld 2.0 gaat hij over de topscore van Fable 5 heen, met ongeveer een derde van het budget.

De prijs per token is dezelfde als bij 4.8: vijf dollar in, vijfentwintig uit, per miljoen.

Sterke release. Ik werk er een paar uur mee en ik ga niet doen alsof dat tegenvalt.

De zin die je een middag gaat kosten, staat niet in de aankondiging. Die staat verstopt in de documentatie over effort, in de sectie voor dit model:

Als je effort-instellingen hebt overgenomen van een eerder model, meet ze dan opnieuw op je evals in plaats van ze te hergebruiken.

Lees dat nog eens met je eigen repo in gedachten. Elke effort-waarde die je voor Opus 4.8 hebt afgesteld, in je Claude Code-config, in je subagent-definities, in de output_config van die ene service die je vorig kwartaal live zette, is nu advies van een vorig model.

Hij wordt nog netjes ingelezen. Er komt geen enkele foutmelding. Alleen betekent hij niet meer wat hij betekende toen je hem instelde.

De winst is echt

Dit is meer dan het gebruikelijke halve procentpuntje per release. Een codebenchmark verdubbelen tussen twee releases die acht weken uit elkaar liggen is fors, en ARC-AGI-3 is het soort eval dat een model óf snapt, óf zichtbaar niet snapt.

Wat ik belangrijker vind: de onderkant van de schaal is beter geworden. Anthropic schrijft zelf dat low en medium op Opus 5 sterker zijn dan op eerdere Opus-modellen, en raadt aan ze ruim in te zetten als je belangrijkste knop voor kosten en snelheid. Voor iedereen die agents in een lus laat draaien, telt een sterkere ondergrens zwaarder dan een hoger plafond. De meeste tokens in een agent-sessie gaan niet op aan het moeilijke stuk.

En precies daar zit de valkuil.

“De helft van de kosten” gaat over gedrag, niet over je factuur

Aan de tarieven is niets veranderd. Opus 5 kost per token hetzelfde als Opus 4.8. Elke zin over “de helft van de kosten per taak” is rekenwerk over verbruikte tokens: het model bereikt hetzelfde resultaat met minder tokens en minder beurten, dus valt de taak goedkoper uit.

Die besparing is echt, en tegelijk voorwaardelijk. Kosten per taak hangen af van je prompts, je tool-loop, hoe vaak je opnieuw probeert, hoeveel context je meesleept, en het effort-niveau waarop je draait. Anthropic heeft die cijfers gehaald met instellingen die voor dít model zijn doorgemeten. Jij draait met instellingen die je voor het vorige hebt doorgemeten.

Zelfde model, zelfde prijs, twee verschillende facturen. Dit is dezelfde rekensom over goedkoop en gratis, een laag dieper.

Vijf labels die bleven staan terwijl eronder alles verschoof

In naam zijn de effort-niveaus stabiel gebleven. low, medium, high, xhigh, max, dezelfde vijf woorden, hetzelfde API-veld, dezelfde YAML-sleutel. Wat er achter elk woord zit, verschilt per model en verschuift bij elke release.

Voor Opus 4.7 en 4.8 was het advies: begin bij xhigh voor code en agentwerk, houd high aan als ondergrens voor alles waar intelligentie telt, en zak pas naar medium als je evals aantonen dat de kwaliteit overeind blijft. max was voor echt zware problemen, met de waarschuwing dat het op de meeste workloads vooral kosten oplevert en weinig kwaliteit.

Voor Opus 5 blijft xhigh het aanbevolen startpunt voor code. De ondergrens is verschoven: medium en low gingen van “bewijs eerst dat het houdbaar is” naar “pak deze als eerste”. Een team dat in mei netjes alles op xhigh heeft vastgezet, precies zoals toen werd geadviseerd, betaalt nu te veel voor werk dat dit model twee treden lager afhandelt.

Twee kleinere wijzigingen staan op dezelfde pagina en ze raken allebei config die tot nu toe gewoon werkte:

• Effort maakt je antwoorden niet meer korter. Op Opus 5 levert een lager effort-niveau niet consequent een korter antwoord op, dus stuur je op lengte via je prompt. Draaide je low mede om antwoorden bondig te houden, dan is die knop weg.
• Thinking laat zich niet uitzetten op xhigh of max. Een verzoek dat een van beide combineert met thinking: {"type": "disabled"} levert een 400 op. Dat is de enige verouderde instelling die hard stukloopt, en daarmee meteen de minst gevaarlijke van de drie.

Het gaat stil mis, en juist daarom blijft het liggen

Effort is gedocumenteerd als een gedragssignaal, geen hard tokenbudget. Er is geen validatie die weet voor welk model je een waarde hebt afgesteld, geen waarschuwing, geen deprecation-melding. Niets in je stack heeft door dat jouw medium in mei is gekalibreerd.

Dus je upgradet, en het werkt. Je krijgt een antwoord, het antwoord ziet er prima uit, de tests slagen.

Ergens daarin draai je op een niveau dat je nooit gekozen zou hebben als je het had gemeten. Je betaalt voor diepgang die dit model niet meer nodig heeft, of je zit juist onder de grens waar de winst begint. Aan de output zie je het niet.

Dit is hetzelfde patroon als een verouderd geheugenbestand: iets wat ooit klopte, nog steeds geladen wordt, er nog steeds gezaghebbend uitziet, en ondertussen gewoon niet meer klopt. Config veroudert net zo hard als documentatie, en om precies dezelfde reden. Het beschrijft een wereld waar een update overheen is gegaan.

Wat je deze week echt moet doen

Niets hiervan kost veel tijd. Dat het toch blijft liggen, komt doordat de dag van een upgrade voelt als de dag dat je iets cadeau krijgt.

• Grep je repo op effort-waarden. Claude Code-instellingen, subagent-frontmatter, skill-definities, servicecode, CI-jobs. De meeste teams hebben er meer dan ze denken, verspreid over plekken die nooit bedoeld waren om zo’n keuze vast te leggen.
• Zorg voor één eval die je kunt herhalen. Tien tot twintig taken uit je eigen repo, met een pass/fail waar je op vertrouwt. Gewoon een vaste set die je elke dag op elk model kunt loslaten.
• Meet eerst een niveau lager. Nu de ondergrens is opgeschoven, is de goedkoopste nuttige ontdekking dat je xhigh betaalt voor medium-werk.
• Kies effort per workload en laat hem daarna staan. De waarde halverwege een gesprek aanpassen maakt je cache ongeldig, dus varieer tussen workloads en niet binnen een sessie die op cache-hits steunt.
• Doe het op de dag van de upgrade. Het alternatief is dat je het doet tijdens een incident of tijdens een gesprek over de rekening, en dan voelt het niet meer als een vrije middag.

Anthropic zei bij Opus 4.8 hetzelfde als nu, namelijk dat je die cijfers alleen haalt als jouw setup meekomt. Dat gold toen al, en daarom schreef ik destijds over het deel van de 4.8-release dat geen benchmark was.

De upgrade is echt gratis. Iedereen krijgt het betere model tegen de oude prijs op de dag dat het uitkomt, en dat is, hoe je het ook bekijkt, een prima deal.

Het opnieuw afstellen is wat het je werkelijk kost. Dat wordt afgerekend in een middag in plaats van in dollars, en precies daarom slaat vrijwel iedereen het over. Sla het vaak genoeg over en je draait de instellingen van vorig kwartaal op het model van dit kwartaal, zie je de winst kleiner uitvallen dan beloofd, en concludeer je dat de benchmarks marketing waren.

Die benchmarks zijn gemeten. De jouwe niet.