Ich habe 4.000 Zeilen meiner eigenen Anweisungen gelöscht, und die Arbeit wurde besser

Sieben Dateien weg, und die Regeln, die geblieben sind.

Ende Juli hatte dieses Projekt 11.100 Zeilen Markdown, die den Agenten erklärten, wie sie arbeiten sollen. Jede Regel, die mir wichtig war, stand irgendwo. Gebrochen wurden sie trotzdem.

Nur Dunkelmodus. Drei Farben. Keine Schrift unter 14 Pixeln. Alles stand in der Datei, und alles kam nach dem Reparieren zurück, mehr als einmal. Eine Regel in einem langen Dokument ist keine Regel. Sie ist ein Satz, an dem jemand vorbeigescrollt ist.

Also habe ich aufgehört zu fragen, welche Regeln wichtig sind, und stattdessen geschaut, welche tatsächlich gebrochen wurden. Das ist eine andere Frage und sie liefert eine andere Antwort. Die Regeln, die immer wieder gescheitert sind, waren alle mechanisch. Mechanisches braucht kein Dokument, sondern eine Prüfung, die läuft, ob sich jemand daran erinnert oder nicht.

Der Rest kam auf zwei Stapel: wird jede Sitzung gelesen, und wird manchmal gelesen. Immer bleibt in der Hauptdatei. Manchmal wird ein Skill, der nur lädt, wenn die Arbeit dazu passt. Sieben Dateien sind ganz verschwunden, darunter 1.075 Zeilen mit der Aufschrift Memory, die seit Wochen niemand geöffnet hatte. In einem Commit 3.963 Zeilen gelöscht. Die Statusdatei ging von 1.754 Zeilen auf 130, die Hauptdatei von 275 auf 170.

Wo eine Regel liegt, entscheidet darüber, wie oft ich sie bezahle. Alles in der Immer-Datei wird zu Beginn jeder Sitzung geladen, ob es zur Aufgabe passt oder nicht. Ein Skill lädt nur, wenn die Arbeit dazu passt. Eine Pfadregel greift nur bei den Dateien, die sie nennt. Und eine Regel, die ein Skript prüfen kann, kostet gar nichts, denn grep braucht kein Modell.

Die Anweisungen sind kürzer als im Juni, und sie werden häufiger befolgt. Das war am Ende ein Problem, nicht zwei.