Context versus continuïteit: waarom grotere geheugens niet werken

Laten we eerlijk zijn. Als je regelmatig met AI coding agents werkt, ken je dit gevoel vast.

Je komt de volgende ochtend terug bij een project. Je opent de chat. Je vraagt de agent om verder te gaan waar je gebleven was. En dan begint het wachten op die onvermijdelijke warboel van verwarring terwijl het probeert te reconstrueren wat er gebeurde, wat faalde, wat werkte, en wat uiteindelijk toch niet.

Herkenbaar?

Het punt waar weinig mensen over praten: het probleem is niet dat deze agents te weinig geheugen hebben. Het probleem is dat hun geheugen het verkeerde type is.

Twee dingetjes die niet hetzelfde zijn

Context is alles wat een agent op dit moment tot zijn beschikking heeft: bestanden, chatgeschiedenis, documentatie, opgehaalde notities. Dat is handig. Continuïteit is wat ervoor zorgt dat je agent morgen exact weet waar je vandaag staat.

Dit klinkt vergelijkbaar. Dat is het niet.

Een groot context-venster stelt een agent in staat om meer informatie tegelijk te verwerken. Maar zodra die sessie eindigt, zodra je van tool wisselt, zodra je de volgende ochtend fris begint, loop je tegen dezelfde muur aan: wat gebeurde er eigenlijk? Wat is er veranderd? Wat faalde? Wat leek alleen maar te werken?

Grotere context-vensters lossen dit niet op. Ze geven je alleen meer tekst om door te spitten terwijl je nog steeds het punt mist.

De rommella-problematiek

De voor de hand liggende oplossing is om meer opslag te bouwen. Langere chatgeschiedenis. Grotere vector databases. Complete archieven van alles wat de agent ooit heeft aangeraakt.

Ik heb teams dit zien implementeren. Het voelt krachtig. Het voelt als vooruitgang.

Maar hier is wat er werkelijk gebeurt: het systeem wordt een heel dure rommella. Samenvattingen worden snel outdated. Mislukte aanpakken staan naast succesvolle met hetzelfde visuele gewicht. De agent haalt iets op dat relevant klinkt, maar niemand weet of het actueel is, bruikbaar, of gewoon een plausibele hallucinatie van vorige week.

Wanneer een agent operationeel betrouwbare informatie nodig heeft—heeft deze commando daadwerkelijk gewerkt? welk bestand is bewerkt?—krijgt het semantisch vergelijkbare ruis in plaats daarvan.

Dat is erger dan helemaal geen geheugen.

Hoe continuïteit er eigenlijk uitziet

Laat me schetsen wat echte continuïteit vereist.

In plaats van een vage notitie zoals "auth-probleem waarschijnlijk opgelost" wil je gestructureerde records die de werkelijke operationele staat bijhouden: welke bestanden zijn bewerkt, welke commando's zijn uitgevoerd, wat het resultaat was, wat nog onopgelost is, en wat de volgende actie zou moeten zijn.

Het gaat niet om alles onthouden. Het gaat om de juiste feiten bewaren in een formaat dat sessiegrenzen overleeft.

Een geheugenitem zegt: "We hebben vooruitgang geboekt met de parser."

Een continuïteitsrecord zegt: "Parser-taak gepauzeerd. tokenizer.py bewerkt. pytest tests/test_parser.py geslaagd. Volledige test suite nog niet uitgevoerd. Volgende stap: volledige parser testgroep draaien voordat scope wordt uitgebreid."

Het verschil is het verschil tussen een collega die een gesprek vaag herinnert en eentje die je gedetailleerde notities overhandigt met duidelijke vervolgstappen.

Wat dit betekent voor jouw workflow

Hier wordt het praktisch. Als je AI-ondersteunde development workflows bouwt—en als je hier bent, is dat waarschijnlijk het geval—dan moet je vanaf dag één nadenken over deze architectuur.

Statische instructies over je repository zijn waardevol. Ze vertellen agents hoe tests te draaien, waar modules zich bevinden, welke conventies te volgen. Maar ze zijn statisch. Ze weten niet dat een taak werd onderbroken, dat validatie faalde, of dat je de scope halverwege een sessie hebt verkleind.

Je hebt zowel stabiele instructies als veranderende werkstaat nodig. Eén zonder het andere is onvolledig.

Dit is waarom de "groter geheugen"-aanpak blijft falen. Het lost het verkeerde probleem op met het verkeerde gereedschap. Vector databases blinken uit in semantische retrieval—gerelateerde documentatie vinden, vergelijkbare eerdere notities, overeenkomende knowledge base-chunks. Maar de belangrijkste vervolgfeiten zijn klein, saai, en operationeel: welk commando faalde, welk bestand werd bewerkt, welke test slaagde, wat nog onafgemaakt is.

De echte kans

Hier is mijn kijk: de volgende frontier in AI-ondersteunde development is niet grotere modellen of langere contexten. Het zijn betere overdrachtssystemen.

We bouwen toe naar een wereld waarin coding agents echt kunnen doorzetten waar ze gebleven waren—niet door meer informatie te hebben, maar door de juiste informatie te hebben, gestructureerd op een manier die sessiegrenzen overleeft.

Dat betekent zorgvuldig nadenken over welke staat te bewaren, hoe het te structureren, en hoe het operationeel betrouwbaar te maken in plaats van alleen semantisch plausibel.

Bij NameOcean, wanneer we nadenken over vibe coding en AI-ondersteunde development, is dit precies het soort infrastructuur dat ertoe doet. Het gaat niet alleen om ontwikkelaars krachtige tools geven—het gaat om tools die daadwerkelijk onthouden wat ze aan het doen waren wanneer je de volgende ochtend terugkomt.

De agents die winnen zullen niet degene zijn met het grootste geheugen. Het worden degene die je nooit twee keer dezelfde orientatiedans laten doen.

De conclusie

De volgende keer dat je merkt dat je je project opnieuw uitlegt aan een AI agent, grijp dan niet naar een groter context-venster. Vraag jezelf af: geef ik het context, of geef ik het continuïteit?

Context is makkelijk. Continuïteit is wat er werkelijk toe doet.