# Verteidige deinen Burggraben nicht mit Richtlinien (3/5)

Source: https://lodos.md/de/blog/verteidige-deinen-burggraben-nicht-mit-richtlinien
Published: 2026-08-11 · Author: Samet Samyeli · Language: de · Reading time: 9 min

Richtlinien auf Papier verrotten in dem Moment, in dem ein Junior-Entwickler dazukommt oder nachts um zwei ein Refactoring durchgezogen wird. Bei mir laufen zwei harte Prüfungen bei jedem Commit: Die eine lässt den Build scheitern, wenn ein Selbstverbot zurückgedreht wird, die andere das Wiki, wenn eine Lehre verloren geht. Beide sind in derselben HMAC-Kette versiegelt.

---

> Die meisten KI-Produkte verteidigen ihren Burggraben mit Richtlinien auf Papier, und dieses Papier verrottet in dem Moment, in dem ein Junior-Entwickler dazukommt oder nachts um zwei ein Refactoring durchgezogen wird. Ich verteidige meinen mit zwei harten Prüfungen, die bei jedem Commit laufen: Die eine lässt den Build scheitern, sobald ich ausliefere, was ich mir selbst verboten habe. Die andere lässt das Wiki durchfallen, sobald eine teuer bezahlte Lehre sich nicht mehr abfragen lässt oder sich selbst widerspricht. Beide sind in derselben HMAC-Kette versiegelt. So entsteht der einzige Burggraben, der wie eine Ratsche nur in eine Richtung rastet: Mit jedem Verbot lässt sich das System schwerer zurückdrehen, mit jeder Lehre wird es nützlicher.

Ich lasse bei jedem Commit zwei Skripte laufen.

Das erste durchsucht per grep die gesamte Codebasis nach allem, was ich mir selbst verboten habe: nach allem, was Ausdrücke zur Laufzeit auswertet; nach Werkzeugen, die Zugangsdaten im Klartext zurückgeben; nach rohen Provider-Modulen; nach der tödlichen Dreierkombination, mit der ein Agent Daten nach draußen schleust. Taucht auch nur eines davon auf, bricht der Build ab.

![Zwei gespiegelte Spalten über einer gemeinsamen HMAC-Kette: Links läuft der Code durch grep, der auf verbotene Muster prüft, bis hin zum abgebrochenen Build. Rechts läuft das Wiki durch den Lint, der prüft, ob etwas Wichtiges fehlt, bis hin zur gerissenen Integritätsprüfung. Beide Seiten schreiben ihre Ereignisse in dasselbe Log, in dem jede Manipulation sichtbar wird.](/blog/make-your-moat-a-ratchet/2a.webp)

Das zweite geht das Wiki durch und stellt die umgekehrte Frage: Was müsste hier stehen, steht aber nicht? Eine Behauptung ohne Quelle. Eine Konzeptseite, auf die kein einziger Verweis zeigt. Zwei Seiten, die im Abstand von Monaten entstanden sind und sich widersprechen. Das erste Skript verhindert, dass aus dem System ein CVE wird. Das zweite verhindert, dass das System vergisst, was es längst gelernt hat.

lodos habe ich um eine einzige Regel herum gebaut. Jedes Verbot, das zählt, ist ein grep im Build. Jedes Wissen, das zählt, ist eine versionierte Seite, die sich abfragen lässt.

Beide leben in derselben HMAC-Kette, die bei der kleinsten Manipulation sichtbar reißt. Schreib auf, was du niemals bauen wirst. Schreib auf, was du niemals vergessen willst. Und sorg dafür, dass der Build nicht durchläuft, solange nicht beides steht. Die meisten KI-Produkte schreiben auf, was sie sein wollen, und verteidigen es mit Richtlinien. Eine kleinere Gruppe schreibt auf, was sie niemals werden will, und verteidigt es mit Code. Die seltenste Gruppe schreibt zusätzlich auf, was sie niemals vergessen will, und verteidigt es mit einem Wiki, das an seiner eigenen Integritätsprüfung scheitert, sobald eine Seite abdriftet. Nur diese letzte Gruppe baut einen Burggraben, der von allein tiefer wird.

![Burggraben aus Richtlinien gegen Burggraben mit Ratsche: Links wandert ein schriftliches Versprechen durch einen Junior-Entwickler, ein Refactoring und stilles Abdriften, ohne dass es jemand bemerkt, und die Vertrauenskurve fällt gegen null. Rechts scheitern grep und Wiki-Lint bei jedem Commit laut, und dieselbe Kurve steigt über zwölf Monate Stufe für Stufe an.](/blog/make-your-moat-a-ratchet/3a.webp)

## Was zerfällt und was nicht

Burggräben aus Richtlinien sterben leise. „Zugangsdaten schreiben wir nie ins Log.“ „Jede Werkzeugausgabe läuft in einer Sandbox.“ „Wir prüfen die Eingabe, bevor das Modell sie sieht.“ Solche Sätze stehen in SOC-2-Unterlagen, und an dem Tag, an dem sie geschrieben werden, stimmen sie. Dann baut ein Junior-Entwickler einen Debug-Logger ein. Ein Refactoring schiebt den Filter hinter ein Feature-Flag. Der Satz bleibt im Dokument stehen, das System verhält sich nur nicht mehr danach. Nichts schlägt fehl. Niemand merkt es.

Burggräben aus Wissen sterben noch schneller. Ein Gründer versteht nachts um zwei, warum ein Kunde gekündigt hat, wirft die Erkenntnis in einen Slack-Kanal und hat sie eine Woche später vergessen. Die Lehre steht an keiner Stelle, an der sie sich abfragen ließe. Drei Monate später kommt dasselbe Muster zurück, und er zahlt dasselbe Lehrgeld ein zweites Mal. Das ist der teuerste Zerfall von allen, weil der Gründer nicht einmal merkt, dass er stattfindet.

Gegen beides hilft dasselbe Mittel: Häng das, was dir wichtig ist, an eine Struktur, die kaputtgeht, wenn es kaputtgeht. Der Build muss scheitern, wenn ein Selbstverbot zurückgedreht wird. Das Wiki muss an seinem eigenen Lint scheitern, wenn eine Seite verwaist, vom Thema abkommt oder sich selbst widerspricht. Die Lösung ist kein Prozess. Die Lösung ist eine Prüfung, die das System bei jedem einzelnen Durchlauf auf sich selbst anwendet.

![Die Schleife aus drei Operationen: Die Aufnahme macht aus Rohquellen einen Seitenvorschlag, der im Diff-Dialog geprüft wird, bevor er verbindlich wird. Die Abfrage fasst Antworten mit Quellenangaben zusammen, die sich als Seite zurückspeichern lassen. Der Lint sucht nach verwaisten Seiten, Behauptungen ohne Quelle und Widersprüchen. Darunter stehen die drei Stellen, an denen lodos abweicht: verschlüsselte Ablage in SQLite, ein Agent, der nur vorschlagen darf, und ein Prüfprotokoll in einer HMAC-Kette.](/blog/make-your-moat-a-ratchet/4a.webp)

## Das Karpathy-Muster, kommerziell gedacht

Die Wissenshälfte habe ich mir nicht ausgedacht. Andrej Karpathy hat ein LLM-Wiki mit drei Operationen und einer einzigen These beschrieben: Das Wiki ist das fertige Programm, die Rohquellen sind der Quelltext, das Modell ist der Compiler, der Lint ist die Testsuite, und die Abfragen sind die Laufzeit.

Ich habe das Muster übernommen und bin dann bewusst an drei Stellen davon abgewichen.

- **Ablage.** Karpathy nutzt einen Ordner voller Markdown-Dateien und git. Bei mir liegt alles in SQLite, in einem Tresor, dessen Abschnitte einzeln verschlüsselt sind. Der Tausch heißt: Interoperabilität gegen Vertraulichkeit. Ein sauberer Markdown-Export holt mir Obsidian zurück, sobald ich es brauche.
- **Selbstständigkeit.** Karpathy lässt das Modell direkt schreiben. Bei mir läuft jede Änderung durch einen Diff-Dialog, in dem ich sie erst freigebe. Die verbindliche Seite fasst der Agent nie selbst an. Jede Freigabe kostet mich fünf bis zehn Sekunden. Dafür kann der Agent mein Verhalten nicht stillschweigend umschreiben.
- **Prüfprotokoll.** Karpathy führt ein schlichtes Markdown-Log. Ich führe eine HMAC-Kette, signiert mit einem Unterschlüssel, der aus dem Master-Passwort abgeleitet ist. Wurde am Log manipuliert, fällt beim nächsten Start die gerissene Kette auf.

Das sind keine philosophischen Feinheiten, sondern die kommerzielle Anpassung eines Musters, das für persönliches Wissen gedacht war. Der Geist bleibt derselbe, der Preis ist der eines Produkts für Käufer mit Compliance-Auflagen.

## Beide Seiten rasten nur in eine Richtung

Die Seite der Verbote und die Seite des Wissens haben dieselbe Form. Die eine sucht nach Dingen, die es nie geben darf. Die andere sucht nach Dingen, die nie fehlen dürfen. Beide fragen also nach etwas, das nicht da ist, beide scheitern laut, und beide sind in derselben HMAC-Kette versiegelt.

Wenn ich dem Wiki eine Frage stelle und die Antwort taugt, schlägt die Oberfläche mir vor, sie mit einem Klick als Seite zu sichern. Klicke ich zu, ist die Antwort dauerhaft da. Die nächste Sitzung findet sie. Dieselbe Frage muss nie wieder gestellt werden. Die Kennzahl dafür ist die Speicherquote, und sie steigt mit der Zeit. Das Wiki ist der einzige Teil des Systems, der stärker wird, je mehr ich ihn benutze.

Auf der Seite der Verbote läuft es genauso. Jedes neue Feature, das eine Invariante gefährdet, bringt seine eigene neue Invariante ins Prüfskript mit. In acht Monaten ist das Skript von sieben auf zweiunddreißig Prüfungen gewachsen. Jede neue Fähigkeit bringt den grep mit, der ihre Missbrauchsklasse schließt. Mit jedem ausgelieferten Feature kann die Codebasis strukturell eine Sache weniger.

Die meisten Teams halten das für zwei verschiedene Themen. Es ist dieselbe Disziplin, angewandt auf zwei Lücken: auf das, was es nie geben darf, und auf das, was nie verloren gehen darf.

## Was es kostet und warum genau darin der Wert liegt

Tempo verliere ich genau bei den Features, die sich an meinen Verboten reiben, und bei den Umbauten, die das Wiki übergehen würden. Ein erfahrener Nutzer wünscht sich einen Interpreter für Ausdrücke direkt im Editor. Abgelehnt. Ein Kunde wünscht sich ein Werkzeug, das ihm Zugangsdaten im Klartext zurückgibt. Abgelehnt. Mein künftiges Ich wird in Versuchung kommen, die Freigabeschleife herauszureißen, weil sie sich zäh anfühlt. Der Build wird es nicht zulassen.

Meine Release Notes lesen sich anders als die der Konkurrenz. Bei mir stehen die Absagen genauso oft darin wie die Neuerungen. Eine glatte Wachstumsgeschichte, die verschweigt, was ich bewusst nicht gebaut habe, gibt es hier nicht.

Was ich dafür bekomme, passt auf keine Landingpage. Es passt in ein Verkaufsgespräch mit einem regulierten Käufer. Der hört „wir können das nicht“ anders als „wir versprechen, es nicht zu tun“. Ein Compliance-Beauftragter bewertet eine HMAC-Kette, an der jede Manipulation sichtbar wird, anders als ein Markdown-Log. Und der Gründer, der heute ins Wiki schreibt, schreibt für den Gründer, der in sechs Monaten darin sucht. Keinen dieser Leser erreicht man mit einem Marketingversprechen.

![Die fünf Bausteine, erst einzeln als Karten, dann verdrahtet: Das Code-Repository speist das Invariantenskript auf der Seite der Verbote, der Wiki-Lint deckt die Seite des Wissens ab, beide schreiben in dieselbe HMAC-Kette, und jede Änderung in der Vorschlagsschleife läuft durch einen Diff-Dialog, bevor sie verbindlich wird.](/blog/make-your-moat-a-ratchet/5a.webp)

## Fünf Bausteine, die du dir abschauen kannst

Keiner setzt die anderen voraus. Zusammen ergeben sie das Muster.

1. Eine deklarative Workflow-Engine ohne jeden Interpreter für Ausdrücke.
2. Ein Tresor aus zwei getrennten Speichern, aus dem die KI Zugangsdaten im Klartext schlicht nicht herausholen kann.
3. Ein Invariantenskript, das zur Build-Zeit läuft und nach der Disziplin des Negativbeweises geschrieben ist.
4. Ein Wiki, das die drei Karpathy-Operationen umsetzt und sein Log in eine HMAC-Kette legt.
5. Eine Lernschleife, in der der Agent nur vorschlagen darf und sein eigenes Verhalten nie selbst schreibt.

Die Reihenfolge ist egal. Gemeinsam ist ihnen nur die Disziplin: Schreib auf, was du nicht ausliefern willst und was du nicht vergessen willst, verankere beides im Build und beweise die Verankerung, indem du sie absichtlich zu brechen versuchst. Alles Übrige ist Handwerk.

![Die nächste Schleife als sechsgliedrige Kette: Der Agent verfolgt das Gespräch, bemerkt eine Lücke in seinen Fähigkeiten und entwirft einen Vorschlag. Der bleibt an einem Diff-Dialog mit Gegenüberstellung stehen, der als Nadelöhr markiert ist. Dort gibt ein Mensch frei oder lehnt ab, bevor irgendetwas verbindlich wird und ausgeliefert werden kann. Jeder Vorschlag und jede Entscheidung landet in der HMAC-Kette.](/blog/make-your-moat-a-ratchet/6a.webp)

## Was als Nächstes kommt

*Die letzte Schleife hat am längsten gebraucht, bis sie saß. Der Agent verfolgt das Gespräch, merkt, wo sein eigener Katalog an Fähigkeiten besser sein könnte, und schlägt eine Änderung vor. Ich gebe frei oder lehne ab. Die Änderung nimmt denselben Weg durch den Diff-Dialog wie jeder Wiki-Vorschlag. Sein eigenes Verhalten schreibt der Agent nie. Das Nadelöhr zwischen Vorschlag und Freigabe ist der eigentliche Burggraben. Der nächste Beitrag handelt von dieser Schleife und von einer kurzen Passage im Verhaltens-Prompt, die den ganzen Aufwand gerechtfertigt hat.*

[Auf die Warteliste eintragen](https://lodos.md/)