Verouderd geheugen is erger dan geen geheugen
7m leestijd

Verouderd geheugen is erger dan geen geheugen

Persistent geheugen wordt verkocht als pure winst. Maar een geheugen dat een tijdelijk feit vastlegt en nooit verloopt, blijft je agent richting problemen sturen die allang zijn opgelost.

Verouderd geheugen is een notitie die je agent over je project heeft geschreven, die klopte op het moment van schrijven en nu niet meer klopt. Dat is erger dan helemaal geen geheugen, want een agent die niets weet, kijkt opnieuw, en een agent met een verkeerde notitie handelt ernaar zonder te controleren.

Eerder vandaag had ik een testsuite die schoon doorliep. Alles groen. Eén endpoint had een flaky timeout die af en toe de hele run met exit code 1 liet afsluiten, terwijl elke assertion gewoon slaagde.

Claude zag de exit code, keek naar de groene output, en schreef een notitie voor zichzelf: tests slagen, de runner sluit soms af met 1, negeer dat.

Redelijk. Op dat moment waar.

Toen fixte ik het flaky endpoint. De timeout was weg. Exit 1 was weg. De suite betekende nu precies wat een exit code hoort te betekenen.

Het geheugen kreeg de update niet mee.

De rest van de dag, run na run, bleef Claude naar dat endpoint verwijzen. Hij zag een echte fout, herinnerde zich "the runner just exits 1 sometimes", en liet hem door. Hij joeg achter een spook aan. Het probleem waar hij omheen werkte, was sinds die ochtend dood, maar de notitie die het beschreef stond er nog. Zelfverzekerd, fout, en leidend.

Dat is het hele probleem met geheugen in één verhaal. Niet dat het iets onwaars opsloeg. Het sloeg iets waars op, en daarna ging de wereld verder zonder het in te lichten.

Het argument vóór geheugen klopt ​

De feature is echt goed, dat voorop.

Elke Claude Code-sessie begint koud. Zonder context leest hij je dependencies opnieuw in, gokt hij naar je conventies, en doet hij aannames die jij daarna moet corrigeren. Het CLAUDE.md-bestand lost de voor de hand liggende versie hiervan op: je schrijft je stack op, je commando's, je voorkeuren, en de agent kent ze al zodra hij begint.

Auto-memory gaat een stap verder. De agent schrijft zijn eigen notities terwijl hij werkt. Build-eigenaardigheden, waar het echte entry point zit, die ene service die een flag nodig heeft om lokaal te draaien. Je corrigeert het één keer, hij onthoudt het, en de volgende sessie loopt soepeler. Anthropic levert inmiddels geheugen voor managed agents, continuïteit over sessies heen, zelfs een "dreaming"-stap waarin de agent tussen taken door zijn eigen geheugen herschrijft om dode verwijzingen op te schonen.

Dit is allemaal echte waarde. Elke keer koud starten is een belasting. Geheugen verlicht die.

Maar er is een kostenpost die niemand op de factuur zet.

Geheugen legt een moment vast, geen waarheid ​

Dit is het deel waar iedereen snel overheen stapt. Als een agent een geheugen wegschrijft, legt hij geen feit over je project vast. Hij legt een feit over je project op één moment vast. Een snapshot.

"Tests pass, exit 1 is spurious" was een snapshot. "the staging DB is down, use the local one" net zo goed. "the auth module lives in legacy/" net zo goed. Elk daarvan is waar op het moment dat het wordt opgeschreven en heeft een houdbaarheid die je in dagen meet, soms in uren.

Code heeft een eigenschap die geheugen mist: als je code verandert, is die verandering de nieuwe werkelijkheid. Er ligt geen tweede kopie van het oude gedrag in een ander bestand die volhoudt dat het nog op de oude manier werkt.

Geheugen is precies die tweede kopie. Het is een parallel verslag van hoe het was, zonder verbinding met het ding dat het beschreef. Jij fixt de flaky test. De test is gefixt. De notitie over de flaky test niet, want niets verbindt ze. De notitie heeft geen idee dat haar onderwerp veranderde. Dat kan ook niet. Het is een string in een bestand.

Dus blijft het staan, langzaam verouderend, terwijl de agent het als actueel behandelt. Geheugen kent geen peildatum. Alles wat het weet, weet het in de tegenwoordige tijd.

Waarom verouderd erger is dan afwezig ​

Je zou denken dat een foute notitie niet erger is dan een ontbrekende. Het is veel erger, en de reden is subtiel.

Zonder geheugen start de agent koud. Hij controleert de werkelijkheid opnieuw. Hij leest de testoutput met frisse blik, ziet de fout, en reageert op wat er echt staat. Een koude start is traag, maar hij staat met beide benen op de grond. Hij kijkt naar de wereld.

Met verouderd geheugen slaat de agent die controle over. Waarom het gedrag van de testrunner opnieuw lezen als hij al "weet" dat exit 1 nep is? De notitie is een zelfverzekerd uitgangspunt dat hij nooit opnieuw verifieert. Het zet precies het moment van kijken buitenspel dat het probleem aan het licht zou hebben gebracht.

Dit is de papegaai op zijn gevaarlijkst. Hij verzint niets. Hij herhaalt, volkomen vloeiend, een feit dat ooit waar was. Het klinkt goed omdat het goed was. Het zelfvertrouwen is volledig verdiend en volledig misplaatst.

Geen geheugen maakt de agent traag. Verouderd geheugen maakt hem fout terwijl het snel voelt.

Het stapelt zich stil op ​

Het ergste is dat het zichzelf niet aankondigt.

Een verouderde notitie geeft geen foutmelding. Hij stuurt elke sessie die hem leest gewoon zachtjes de verkeerde kant op. De agent handelt ernaar, de actie werkt meestal, de notitie wordt bestempeld als "nuttig", en zakt dieper weg in het standaardgedrag. Elke run giet er weer een dun laagje overheen.

Als dat bekend klinkt, dan komt dat doordat het opnieuw de lavalaag van versteende code is, alleen in je context in plaats van in je codebase. Iets dat op zijn plek is uitgehard, waar iedereen omheen stuurt in plaats van het weg te halen, waarvan niemand de oorspronkelijke reden nog precies weet. Alleen is deze laag onzichtbaar. Het is een zin in een geheugenbestand die de agent stilletjes de verkeerde kant op stuurt, run na run, tot je hem toevallig leest en denkt: wacht, dat hebben we toch gefixt?

Wat je wél moet doen ​

Je kunt geheugen niet zelfbewust maken. Je kunt wel veranderen hoe je ermee omgaat.

  • Lees het regelmatig na, niet pas bij een crisis. Open je geheugen en CLAUDE.md geregeld en lees ze als scepticus. Het /memory-commando bestaat precies hiervoor. Een foute regel werkt door in elke toekomstige sessie tot iemand hem weghaalt, dus de kosten van het laten staan zijn niet constant, ze lopen op.
  • Schrijf feiten met houdbaarheid in gedachten. "The auth module is in legacy/" is een snapshot. "Run npm run test:unit for the fast suite" is al houdbaarder. Geef de voorkeur aan notities die stabiele intentie beschrijven boven notities die een vluchtige toestand vastleggen. Een tijdelijke oplossing voor wat vandaag stuk is, moet als eerste weg.
  • Geef de voorkeur aan verwijzingen boven snapshots. Een notitie die zegt "check the test runner's exit behaviour" veroudert beter dan "exit 1 is spurious", want hij zet de agent aan het kijken in plaats van hem te vertellen wat hij zal vinden. Geheugen dat naar de werkelijkheid wijst, blijft eerlijk. Geheugen dat de werkelijkheid kopieert, veroudert.
  • Vertrouw niet blind op automatisch opschonen. De dreaming-stap en zelfherschrijvend geheugen zijn echt en ze helpen, maar het is een model dat gokt naar wat nog relevant is. Het model dat de verouderde notitie schreef, is hetzelfde model dat beslist of het hem houdt. Behandel automatische opschoning als mooi meegenomen, niet als garantie. Datzelfde geldt voor het snoeiwerk dat /doctor tegenwoordig voorstelt in je CLAUDE.md: lees die diff voor je hem accepteert.
  • Gooi rigoureus weg. Bij twijfel: weg ermee. Een ontbrekende notitie kost een koude start. Een foute notitie kost een debugsessie die eindigt met de ontdekking dat de bug afgelopen dinsdag al gefixt was.

Weggooien kost minder dan het lijkt, want die notitie was nooit de enige kopie. De sessie waarin je het uitzocht staat nog op je schijf, en is doorzoekbaar zodra er iets een index op legt.

Geheugen is de feature die de agent het gevoel geeft dat hij je project kent. Precies daarom is hij gevaarlijk. De notities die hij het meest vertrouwt, zijn de notities die hij niet meer in twijfel trekt, en de notities die hij niet meer in twijfel trekt, zijn de notities die op hun plek liggen te rotten.

Mijn flaky endpoint was rond lunchtijd gefixt. De agent bleef er de hele middag tegen vechten, niet omdat hij in de war was, maar omdat hij het zich herinnerde. Het geheugen deed zijn werk perfect. Het kon alleen niet weten dat het werk al gedaan was.

(8 van 40)
1Mijn Claude Code-setup: status line, plugins en terminal2Superpowers: hoe je Claude Code leert eerst te denken3Claude Code-hooks: deterministische controle over AI-workflows4Het CLAUDE.md-bestand: geef je AI permanent geheugen5Stop met vriendelijk vragen aan je agent6Wat er nieuw is in Claude Code: notities van het Londen-event7Het beste cijfer in Opus 4.8 is geen benchmark8Verouderd geheugen is erger dan geen geheugen9De agent is gewoon een loop10Bouw een MCP-server, en vraag je dan af of die moet bestaan11Skill, subagent, hook of slash command? Kies de juiste12Inloggen op MCP-servers vanuit je shell13Claude veilig toegang geven tot je SQL-database14De dag dat 'default' ineens 'Manual' heette15Claude Code-skills: zo schrijf je er een die werkt16Een goede Claude Code-subagent schrijven17Claude Code permissions instellen: de gids die ik miste18Claude Code sandboxen: toestemming is geen muur19Prompt injection voorkomen: verdediging voor wie agents bouwt20Het beste Claude-model voor code: welk model voor welke taak21Legacy code refactoren met AI: begin met characterization tests22Je MCP-server beveiligen: authenticatie, scopes en rate limits23Opus 5 is er, en je effort-instellingen kloppen niet meer24Incident response voor AI-agents: wat je doet als je coding agent de fout in gaat25Claude Code /doctor: wat hij controleert en wat er nieuw is26Context beheren in Claude Code: wanneer /clear en wanneer /compact27Git worktrees uitgelegd: parallel werken met AI-agents zonder botsingen28Claude Code plan mode: beslissen voordat de agent schrijft29Debuggen met een coding agent: geef hem het zoekwerk, de hypothese houd je zelf30Claude Code checkpoints en /rewind: wijzigingen van je agent terugdraaien31Claude Code cross-session messaging: sessies die elkaar berichten sturen32Audit logging voor AI-agents: wat Claude Code vastlegt en wanneer je iemand wakker belt33Claude Code-config delen met je team: wat de repo wel en niet afdwingt34Je Claude Code-sessie heeft geen klok35Claude Code in een grote codebase: de agent afbakenen tot wat ertoe doet36Een Claude Code-sessie terughalen die de resume-picker niet laat zien37Waar Claude Code zijn tijd aan kwijt is: een maand eigen sessies gemeten38Claude Code bijsturen tijdens het werk: Esc, de wachtrij en /btw39Claude Code auto mode: waarom je allow-regel voor Agent niets doet40Claude Code Superpowers: wat subagent-driven development aan tokens kost