·7m leestijd·1,296 woorden·

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.

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 "de runner sluit soms gewoon af met 1," 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 dragend.

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

Ik wil eerlijk zijn over de feature, want hij is echt goed.

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 loopt binnen terwijl hij ze al kent.

Auto-memory gaat een stap verder. De agent schrijft zijn eigen notities terwijl hij werkt. Build-eigenaardigheden, waar het echte startpunt 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 lost die af.

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

Geheugen legt een moment vast, geen waarheid

Dit is het deel waar iedereen overheen praat. 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 momentopname.

"Tests slagen, exit 1 is nep" was een momentopname. "De staging-DB ligt eruit, gebruik de lokale" net zo goed. "De auth-module zit 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. Niet iets verzinnen, maar volkomen vloeiend een feit herhalen 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 lava-laag 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. "De auth-module zit in legacy/" is een momentopname. "Draai npm run test:unit voor de snelle suite" zit dichter bij houdbaar. Geef 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 voorkeur aan verwijzingen boven momentopnamen. Een notitie die zegt "controleer het exit-gedrag van de testrunner" veroudert beter dan "exit 1 is nep", 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 meegenomen, niet als garantie.
  • 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.

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.

// serie: Claude Pro(8 van 8)