69 Regeln, die ich zweimal geben musste

Diese hier ist technisch, seien Sie gewarnt. Coding-Agenten, die in Ihrem Terminal laufen, schreiben jedes Gespräch, das Sie mit ihnen führen, in eine Datei auf Ihrer eigenen Festplatte. Und danach öffnet sie nie wieder jemand. Monate, in denen Dinge entschieden wurden, liegen in einem Ordner.

Also habe ich etwas gebaut, das sie liest. Ich habe es auf 585 meiner Sessions gerichtet, 1,6 GB, und etwa fünfzehn Sekunden später sah ich eine Liste mit 69 Anweisungen, die ich schon einmal gegeben hatte.

Nicht 69 ähnliche. Dieselbe Regel, noch einmal gegeben, weil sie beim ersten Mal nicht hängen geblieben ist.

Es beantwortet zwei Fragen

Das Werkzeug heisst Paper Trail.

Warum ist diese Datei so, wie sie ist? Zeigen Sie auf eine beliebige Datei, und Sie bekommen das Gespräch, das sie entschieden hat, verbunden mit dem Commit, der sie geändert hat. Nicht das Ticket, nicht die Commit-Nachricht, die jemand hinterher geschrieben hat. Den Satz, den jemand tatsächlich getippt hat.

Was habe ich eigentlich entschieden? Drei Notizen, geschrieben in meinen eigenen Wissensspeicher. Die Dinge, die liegen geblieben sind und die seither niemand aufgegriffen hat, 11 davon. Die Regeln, die ich mehr als einmal geben musste, die besagten 69. Und die Entscheidungen, 117 Stück, jede mit der Begründung und den Commits, die darauf folgten.

Es liest Claude Code und Codex und behandelt ein Projekt, an dem Sie mit beiden gearbeitet haben, als ein Projekt. Python und die Standardbibliothek, also kein Konto, kein API-Schlüssel und nichts zu installieren ausser einem Symlink. (Ja, ein Symlink. Es ist ein kostenloses Werkzeug, kein Launch.) Das Lesen und das Verbinden passieren auf Ihrer Maschine.

Ich habe nach so etwas gesucht, bevor ich es gebaut habe. Es gibt ein Dutzend kostenlose Werkzeuge, die eine Karte Ihres Codes zeichnen, ich habe ein paar davon benutzt, die sind in Ordnung. Ich habe keines gefunden, das statt des Codes das Gespräch liest. Sie alle zeichnen, was Sie gebaut haben. Keines zeichnet, was Sie entschieden haben. Falls es eines gibt, würde ich es ehrlich gesagt lieber benutzen als meines zu pflegen — sagen Sie mir Bescheid, und ich schaue es mir an.

Das zweite Mal zählt niemand

Die 69 ist nicht geschätzt.

Es gruppiert nicht Sätze und erklärt dann zwei Dinge zur selben Regel. Ich habe das gegen meine eigenen Transkripte versucht, und es hat neun voneinander unabhängige Regeln zu einem Klumpen verschmolzen. Eine Wiederholung zählt also nur, wenn mein eigener Satz es sagt. Ich habe dir gesagt. Wir hatten vereinbart. Wie oft noch. Du machst schon wieder.

Was heisst: Jede einzelne dieser 69 ist eine Entscheidung, die bereits getroffen war — und die beim nächsten Mal nicht mehr da war. Das Setup hat sie fallen lassen.

Ich halte das für eine Betriebskennzahl, nicht für eine Gedächtnisfrage.

Alle, die KI in einem Unternehmen einsetzen, messen Ausstoss. Erledigte Tickets, gesparte Stunden, produzierte Entwürfe, die Folie mit dem Pfeil nach oben. Fast niemand misst, wie oft ein Mensch zurückgehen und dasselbe noch einmal sagen musste — und genau diese zweite Zahl sagt Ihnen, ob die Sache gegriffen hat oder ob sie einfach nur eingeschaltet ist.

Meine ist 69, über wenige Monate, bei einer Person, die das hauptberuflich macht und unterwegs repariert, statt CC anzuschreien, weil er denselben «Fehler» zweimal macht.

Wenn Sie ein Team von zehn Leuten sind, ist Ihre Zahl nicht das Zehnfache von meiner. Ich wette, sie ist pro Kopf schlechter, weil eine geklärte Sache weiter zu reisen hat und unterwegs mehr Stellen findet, an denen sie herunterfallen kann. Ich würde mich gern irren, und ich kann es nicht überprüfen, weil das, soweit ich sehe, noch nie jemand gezählt hat.

Dann brach es sein einziges Versprechen

Paper Trail gibt genau ein Versprechen: Es kann nichts lesen, was Sie nicht erlaubt haben. Zwei Listen, beim ersten Start beide leer, und nichts ist lesbar, bevor Sie es einschalten. Sie löschen ein # vor einem Projekt, und dieses Projekt wird lesbar. Vergessen Sie, etwas zu erlauben, passiert nichts — und das ist die richtige Richtung, in die das hier scheitern soll.

Es ging an einem Samstagnachmittag online. Innerhalb von Stunden hatte ich ein Audit darauf, mit der Ansage, Dinge gegen eine laufende Kopie zu reproduzieren statt den Code auf dem Papier zu lesen. Dieses Audit kam aus derselben Modellfamilie, in der das Werkzeug geschrieben wurde, was es aus meiner Sicht halb wertlos machen würde. Es fand die grosse Sache trotzdem.

Ein Projekt wieder aus der Liste zu nehmen, bewirkte bis zum nächsten Scan gar nichts.

Es druckte weiter die Zitate dieses Projekts. Es schrieb sie in eine neue Notiz. Und der Schritt, der Begründungen rekonstruiert, öffnete das Transkript dieses Projekts erneut und schickte es an ein Modell. Die Datei auf meiner Maschine sagte die ganze Zeit «nicht erlaubt».

Das ist der eine Satz, auf dem das Ganze ruht, und er stimmte nicht.

Dann verursachte die Korrektur innerhalb von Minuten einen zweiten Fehler. Den Index zu filtern machte auch die Routine blind, die sich merkt, wann eine Erkenntnis zum ersten Mal auftauchte — alles, was ich je gefunden hatte, wurde also stillschweigend wieder neu. Diesen hier fingen die Tests. Ohne sie hätten die Notizen perfekt ausgesehen und wären falsch gewesen.

Als ich schon einmal drin war, fiel mir auf, dass die README mit «kein Netzwerk» begann, während die mitgelieferte Einstellung Gesprächsauszüge an ein Cloud-Modell schickte. Diesen Satz habe ich selbst geschrieben. Dann ist der Code darunter weitergezogen, und ich habe ihn nie wieder gelesen. Jetzt steht etwas anderes da, und welches Modell antwortet, bleibt Ihre Wahl — das lokale eingeschlossen.

Das war v1.0.1, draussen am frühen Abend.

Dann liess ich einen zweiten Durchgang aus einer anderen Modellfamilie laufen, mit der Anweisung, nichts erneut zu melden, was der erste schon gefunden hatte. Er kam mit sieben weiteren zurück, zwei davon genau auf der Grenze, die das erste Audit bereits verschoben und für geschlossen gehalten hatte.

Eines davon hätte ich für klein gehalten, bis es jemand gemessen hat. Der Index war nach Projekt gefiltert. Die Commits, die an den einzelnen Erkenntnissen hingen, nicht. Ein Repository aus der Liste zu nehmen liess also dessen Betreffzeilen, Hashes und Dateinamen weiter in den Notizen auftauchen — und weiter in den Text wandern, der an ein Modell ging. 474 angehängte Commits vor dem Entzug eines Repositorys. 388 danach. Die Differenz ist das, was die erste Korrektur liegen gelassen hatte.

Zwei seiner Befunde habe ich verworfen, nachdem ich sie selbst überprüft hatte, und über einen lässt sich streiten. Er meinte, dem Werkzeug ginge bei einem grossen Bestand der Speicher aus. Tut es nicht, weil es das behält, was ein Mensch getippt hat, und nicht den Bestand selbst: 2750 Nachrichten aus diesen 1,6 GB. Ich habe da eine Maschine überstimmt — sagen Sie mir also, wenn Sie meinen, ich liege falsch.

v1.0.2 ging etwa vierzig Minuten nach v1.0.1 raus, am selben Abend, jede Korrektur mit einem Test festgenagelt, damit sie nicht zurückkommt.

Nicht alles allerdings, und das sage ich lieber selbst, als dass Sie es finden. Windows habe ich bewusst offen gelassen und stattdessen aufgeschrieben, weil ein halb erledigter Durchgang über sieben Pfad-Annahmen eine Unterstützung behauptet hätte, die niemand je ausgeführt hat. Das ist bis heute offen.

Ich glaube nicht mehr, dass ein Prüfdurchgang reicht, so gut der Prüfer auch ist.

Ich hätte ausliefern und nichts sagen können. Kostenloses Werkzeug, niemand zu Schaden gekommen, geringe Chance, dass in Woche eins jemand dieses Loch findet. Genau deshalb steht es hier.

Es darf sagen, dass es das nicht weiss

Einen Commit mit dem zu verbinden, was zeitlich am nächsten davor getippt wurde, kann jeder. Paper Trail macht das gratis, und es liegt oft genug richtig, um nützlich zu sein. Im Median liegen dreizehn Minuten zwischen einem Commit und dem Letzten, was ich getippt habe.

Wenn Sie mehr wollen, liest es den echten Diff des Commits zusammen mit allem, was im Fenster davor getippt wurde, und sagt dann, welcher Satz diese Änderung ausgelöst hat. Bei einem Commit ging es an zwei näher liegenden Nachrichten vorbei zu einer, die ich neunzig Minuten früher geschrieben hatte. Beim nächsten Commit verweigerte es die Antwort:

Neither message names anything in the diff. The actual cause isn't present in either typed message.

Mir ist lieber, es kommt leer zurück, als dass es rät. Was immer eine Antwort hat, liest eine Uhr und nennt sie einen Grund — und es wird genau bei den Commits am selbstsichersten sein, die Sie erklärt haben wollten.

Was es noch nicht kann

Claude Code und Codex, sonst nichts. Andere Agenten schreiben dieselbe Art von Datei, ich habe sie noch nicht gemacht.

Windows ist ungetestet, aus dem Grund weiter oben. macOS und Linux.

Eine Entscheidung mit Code zu verbinden setzt voraus, dass die Arbeit in Git liegt.

Eines gibt es, das ich von hier aus nicht lösen kann. Zwei Ordner namens my-app und my_app kommen in der Erlaubnisliste unter demselben Namen heraus, einen zu erlauben erlaubt also beide. Es sauber zu machen bräuchte eine zweite, inkompatible Liste. Vorläufig erkennt es die Kollision und druckt beide Ordner, statt Sie das selbst herausfinden zu lassen.

Und eine Verbindung ist ein starker Hinweis, kein Beweis. Wenn eine Zuordnung schwach ist, sagt es das, und es sagt Ihnen, wie lange nach einem Satz der Commit gelandet ist — damit Sie ihm in etwa zwei Sekunden widersprechen können.

Es ist kostenlos und MIT, auf github.com/DetGaao/paper-trail. Keine E-Mail, keine Anmeldung, nichts hinter einem Formular.

Bevor Sie irgendetwas installieren, raten Sie aber zuerst. Wie oft haben Sie diesen Monat einem Agenten etwas gesagt, das ihm bereits gesagt worden war? Sagen Sie die Zahl laut, und gehen Sie sie dann zählen. Der Abstand zwischen diesen beiden Zahlen ist das ganze Argument.

Meine war 69, und ich habe mir die Woche über eingeredet, das sei ein respektabler Wert für jemanden, der das hauptberuflich macht. Ist es nicht. Sagen Sie mir Ihre, dann fühle ich mich besser.