Warum meine KI denselben Fehler zweimal machte, obwohl ich ihn gespeichert hatte

Anfang Juli ging ein Kunden-PDF raus, in dem stand, ein Blog-Post sei mit 400 bis 700 Wörtern optimal. Unsere eigene Recherche zu genau dem Thema lag bei rund 1500. Die Zahl war frei erfunden, klang plausibel, kam aus dem Trainingswissen des Modells, und niemand hatte sie geprüft. Korrigierbar, kein Drama. Aber es war nicht das erste Mal. Zwei Wochen vorher hatte ein Agent bei einer Immobilien-Beschreibung einfach einen Pool dazugeschrieben. Der stand nirgends in den Daten. Auf die Rückfrage kam die ehrlichste Antwort, die eine KI geben kann: erschien mir logisch, dass so eine Immobilie einen Pool hat. Beide Fälle hatten wir vorher schon einmal als Learning ins Memory geschrieben. "Keine Fakten erfinden." "Fehlende Daten nicht plausibel auffüllen." Stand alles da. Und trotzdem passierte es wieder. Das ist der Punkt, an dem die meisten Memory-Setups scheitern, und der Grund für diesen Post. ## Ein Learning ist kein Schutz Wir führen ein internes Register aller Fehlerklassen, die uns aufgefallen sind. Stand heute knapp hundert Muster. Als wir das erste Mal ehrlich draufgeschaut haben, war die unangenehme Erkenntnis simpel: gut zwei Drittel davon hatten wir zwar dokumentiert, aber nirgends durchgesetzt. Sie lagen als nette Notiz im Memory und warteten darauf, dass das Modell im richtigen Moment von selbst dran denkt. Genau das passiert nicht zuverlässig. Ein Learning im Memory ist passiv. Es wird nur wirksam, wenn eine Suche es zufällig hochspült und das Modell es dann auch beachtet. Bei einem Task, der sich logisch anfühlt, denkt niemand an die Suche. Der Pool erscheint plausibel, also kommt der Pool rein. Was uns rausgeholt hat, war ein Umdenken. Nicht "wo speichern wir den Fehler", sondern "auf welcher Ebene erzwingen wir das richtige Verhalten". Wir nennen das intern die Durchsetzungs-Leiter, und sie hat vier Stufen. ## Die vier Stufen Stufe eins ist das Learning. Nützlich als Gedächtnis, schwach als Schutz. Damit fängt alles an, aber hier darf es nicht enden. Stufe zwei ist die Regel. Der Fehler wandert aus dem Memory in eine Datei, die bei jeder Session automatisch mitgelesen wird, bei uns die CLAUDE.md und ein paar Regel-Dateien daneben. Jetzt ist der Hinweis nicht mehr optional abrufbar, sondern immer im Kontext. Das reicht für viele Fälle schon. Stufe drei ist der Skill. Wenn ein Fehler an einen wiederkehrenden Arbeitsschritt gebunden ist, packen wir eine Checkliste in ein Skill-File, das genau bei diesem Schritt greift. Vor jedem echten Mail-Versand läuft bei uns so eine Pre-Flight-Liste ab, weil wir zweimal Test-Mails an echte Adressen geschickt haben, die hart gebounct sind. Stufe vier ist der Hook. Die härteste Stufe. Ein Hook ist Code, der bei einem Lifecycle-Event feuert, egal ob das Modell dran denkt oder nicht. Bei uns blockt ein PreToolUse-Hook jeden rsync-Deploy, seit genau so ein Befehl einmal die SSH-Keys eines Servers gelöscht hat. Kein "bitte dran denken", sondern ein hartes Nein, bevor der Befehl läuft. Der entscheidende Unterschied zwischen Stufe eins und Stufe vier: Das Learning hofft, dass das Modell sich erinnert. Der Hook braucht das Modell gar nicht. ## Die interessanteste Stufe liegt dazwischen Am meisten gebracht hat uns eine Mischform. Ein UserPromptSubmit-Hook, der bei jeder neuen Anfrage kurz im Fehler-Register nachschlägt und die passenden bekannten Fehler direkt in den Kontext schiebt, bevor die Arbeit überhaupt losgeht. Kein Warten darauf, dass das Modell selbst sucht. So sieht der Eintrag in der settings.json vereinfacht aus: ```json { "hooks": { "UserPromptSubmit": [ { "hooks": [ { "type": "command", "command": "~/.claude/hooks/error-recall.sh" } ] } ] } } ``` Das Script zieht die zum Thema passenden Fehler-Muster und hängt sie als Kontext an. Der Effekt ist simpel und stark: Der Fehler steht vor der Arbeit auf dem Tisch, nicht nach dem Schaden im Review. Wichtig, weil ich es selbst erst falsch eingeschätzt hatte: Hooks sind kein Ersatz für die anderen Stufen. Ein Hook, der bei jeder Anfrage feuert, kostet Kontext und Aufmerksamkeit. Für die harten, teuren Fehler lohnt er sich. Für den Rest reicht oft die Regel-Ebene. Wir schützen bewusst nicht jeden der knapp hundert Fälle mit einem Hook, sondern nur die, deren Wiederholung wirklich weh tut. Die Hook-Events und ihre genaue Syntax stehen in der offiziellen Doku unter https://code.claude.com/docs/en/hooks. Bevor du einen produktiv schaltest, teste ihn im Trockenlauf, sonst blockierst du dir aus Versehen legitime Aktionen. ## Was du daraus mitnimmst Wenn deine KI denselben Fehler wiederholt, obwohl du ihn gespeichert hast, liegt das Problem selten am Speichern. Es liegt daran, dass Speichern und Durchsetzen zwei verschiedene Dinge sind. Frag dich bei jedem wiederkehrenden Fehler nur eins: reicht eine Regel, die immer mitgelesen wird, oder braucht es einen Hook, der gar nicht erst fragt. Wie du dein Memory sauber hältst, damit die richtigen Learnings überhaupt gefunden werden, steht in unserer Lektion zu Memory-Hygiene (/levels/4/09-memory-hygiene). Die Grundlagen zu Hooks und Skills gibt es in (/levels/4/04-hooks-und-skills). Und wenn du direkt gegen Halluzinationen absichern willst, ist das Playbook (/playbooks/hooks-gegen-halluzinationen) der schnellste Einstieg.