Du hast dein KI-Coding-Tool letzten Monat eingerichtet. Modell ausgewählt, Rules-Datei geschrieben, Style Guide definiert. Konfiguration abgeschlossen. Du hast dich der echten Arbeit gewidmet — wie jemand, der Sachen zu shippen hat.

Hier ist der Teil, vor dem dich niemand gewarnt hat: Dein Tool hat sich auch weiterentwickelt. Es hat nur keinen PR dafür aufgemacht.

Die Config, die sich selbst konfiguriert

Zwischen dem 8. und 15. April haben Anthropic und OpenAI beide Features veröffentlicht, die deinem Coding-Assistenten erlauben, seine eigene Bedienungsanleitung umzuschreiben. Kein Code Review. Kein Slack-Ping. Kein "Hey Team, ich hab mal eben grundlegend geändert, wie ich alle eure Architekturentscheidungen angehe." Nur stille Verhaltensmutation, Session für Session.

Am 8.–9. April hat Anthropic Managed Agents in der Public Beta gelauncht. Claude Codes Auto-Memory-Feature schreibt jetzt eine MEMORY.md-Datei — ein selbstverfasstes Notizbuch mit "Gelerntem", das sich über Sessions hinweg ansammelt. Anthropics Doku sagt es klipp und klar: "Auto memory lets Claude accumulate knowledge across sessions without you writing anything. Claude saves notes for itself as it works."

Lies das nochmal. For itself. Nicht für dich. Für sich selbst.

Eine Woche später hat OpenAI das Agents SDK v0.14.0 mit Sandbox Agents veröffentlicht — persistente Workspaces, in denen der Agent seine eigene MEMORY.md und memory_summary.md generiert. Das SDK injiziert diese Dateien beim Start und formt das Verhalten um, bevor der Agent auch nur eine einzige Zeile deines Codes anfasst.

Zwei Unternehmen. Eine Woche. Beide haben entschieden, dass deine KI ihre eigenen Betriebsanweisungen schreiben soll — und dir niemals den Diff zeigt.

Wie das Tagebuch funktioniert

Nach jeder Session extrahiert die KI Muster, die sie bemerkt hat ("dieses Team bevorzugt Tabs"), Präferenzen, die sie abgeleitet hat ("die nehmen immer Redis fürs Caching"), und Fehler, die sie korrigiert hat ("importier nicht diese deprecated Library"). Sie schreibt das alles in Markdown-Dateien oder serverseitige Stores. Nächste Session liest sie erst das Tagebuch — und entscheidet dann, wie sie an deine Codebase rangeht.

Claude Code führt außerdem einen Konsolidierungsprozess im Hintergrund aus, nach 24+ Stunden und 5+ Sessions. (Die Community nennt es "Auto Dream", auch wenn Anthropic diesen Namen in offiziellen Produktankündigungen nicht verwendet hat.) Dabei werden Session-Transkripte zu strukturiertem Gedächtnis komprimiert und relative Datumsangaben in absolute umgewandelt. Anthropics Dokumentation beschreibt die Konsolidierung von 913 Sessions in etwa 8–9 Minuten.

Effizient? Klar. Auditiert? Absolut nicht.

Das Governance-Loch

Hier wird es richtig absurd. In jedem halbwegs kompetenten Engineering-Team bekommt ein einzeiliger README-Tippfehler einen Pull Request. Ein Config-Tweak kriegt zwei Reviewer. Ein .env-Update löst einen Slack-Thread mit drei Meinungen und einem "naja, eigentlich..." aus.

Aber das selbstgeschriebene Gedächtnis deiner KI — die Datei, die bestimmt, wie sie allen zukünftigen Code schreibt — bekommt null Review. Null. Kein Tool bietet einen "Memory PR" für Team-Freigabe an. OpenAIs MEMORY.md kommt ohne jeglichen Review-Workflow. Anthropics Memory Store in Managed Agents hält opake serverseitige Blobs, die du nicht mal git diffen kannst.

Und der Drift zeigt sich schnell. Entwickler haben spürbare Verhaltensänderungen innerhalb von 10–15 Sessions berichtet. In einem viel diskutierten Fall hat Claude stillschweigend angefangen, Tortoise ORM statt des etablierten SQLAlchemy-Setups des Projekts vorzuschlagen — weil eine einzige Async-Debugging-Session ihm "beigebracht" hatte, dass das Team Async-First-Patterns bevorzugt. Niemand hat die Migration angefragt. Niemand hat sie genehmigt. Die Memory-Datei hat entschieden, und die Memory-Datei hat geliefert, über jede nachfolgende Session hinweg.

Das ist kein hypothetischer Grenzfall. Kleine Missverständnisse summieren sich zu persistenten Gewohnheiten. Dein Tool empfiehlt am Montag andere Architektur-Patterns als am Freitag. Es überschreibt deine expliziten Projektkonventionen mit Präferenzen, die es sich aus diesem einen Stack-Overflow-Snippet ausgedacht hat, das du um 2 Uhr morgens reingepastet hast, während du panisch einen Produktionsausfall debuggt hast. Und weil das Gedächtnis persistiert, wird jede falsche Schlussfolgerung zum tragenden Kontext für die nächsten hundert Sessions.

Der ehrliche Tradeoff

Memory hilft. Wiederholte Fehler werden abgefangen. Projektkontext wird übertragen. Ich habe nichts gegen Memory — mein Argument richtet sich gegen unauditiertes Memory mit produktionsweitem Blast Radius.

Wie es eine Analyse von OpenAIs Implementierung formuliert: "If your tooling can't show what the agent retrieved and why, memory becomes a spooky black box."

Du würdest keinen Code deployen, den dein Kollege im Schlafwandeln geschrieben hat. Also warum deployst du Verhaltensänderungen, die deine KI über sich selbst verfasst hat, von niemandem reviewt, wirksam für jede Datei in jedem Repo, das sie anfasst?

Was du konkret dagegen tun kannst

Behandle MEMORY.md und ~/.claude/projects/*/memory/ als Configuration-as-Code. Das ist keine optionale Hygiene — das ist dieselbe Disziplin, die du bereits auf docker-compose.yml und .eslintrc anwendest:

  1. Versioniere es. Committe Memory-Dateien zusammen mit deinem Code. Diff jede Änderung.
  2. Reviewe es. Nimm Memory-Datei-Diffs in deine PR-Checkliste auf. Wenn sich das Memory geändert hat, liest ein Mensch es, bevor es rausgeht.
  3. Auditiere wöchentlich. Setz dir eine wiederkehrende Erinnerung, zu lesen, was dein Tool über deine Codebase glaubt. Du wirst überrascht sein — und gelegentlich entsetzt.
  4. Lösche aggressiv. Wenn das Memory driftet, lösch es und fang von vorn an. Es ist eine Markdown-Datei, keine Persönlichkeit.
  5. Einfrieren bei kritischer Arbeit. Bei produktionskritischen Projekten: Memory-Datei einfrieren und Auto-Updates komplett deaktivieren. Die Selbstoptimierung deiner KI ist nicht wichtiger als deine Deploy-Stabilität.

Der Kreis schließt sich

Das Tool, das du letzten Monat konfiguriert hast, ist nicht das Tool, das heute auf deinem Rechner läuft. Es hat seine eigene Stellenbeschreibung umgeschrieben, während du den Einzeiler-Tippfehler-Fix von jemand anderem reviewt hast. Und es wird es morgen wieder tun, und übermorgen, und jedes Mal das, was es gestern falsch verstanden hat, in die Architekturentscheidungen von morgen einbauen.

Dein Team reviewt einbuchstabige README-Fixes mit zwei Approvern. Fang an, die Datei zu reviewen, die steuert, wie deine KI denkt — oder lass es, und freu dich darauf, auf die harte Tour zu erfahren, was dein Tool über deine Codebase "gelernt" hat.