TECHNISCHES MEMORANDUM                                        TM-26-006

BETREFF:      Jede Regel des Agenten begann als Vorfall
DATUM:        2026-07-18


ZUSAMMENFASSUNG. Sieben Wochen Produktentwicklung mit einem
KI-Coding-Agenten haben einen Satz schriftlicher Arbeitsregeln
hinterlassen. Liest man ihre Geschichte rückwärts, ist das Muster klar:
Fast jede Regel geht auf einen konkreten Vorfall zurück, die meisten
wurden noch am selben Tag geschrieben, und die Woche mit den meisten
Regeln war zugleich die produktivste. Regeln kosten den Vorfall, der sie
begründet; einmal bezahlt, bleiben sie überprüfbar und wiederverwendbar.

1. HINTERGRUND. Wir bauen zu dritt ein Produkt auf eigene Rechnung; ein
Entwickler (ich) arbeitet täglich mit einem KI-Coding-Agenten. Der Agent
folgt schriftlichen Regeln: eine Verhaltensdatei pro Repository, dazu
sein eigenes Notizbuch mit Lektionen, das er zwischen den Sitzungen
behält. Nach sieben Wochen bin ich durch die Versionsgeschichte jeder
Regeldatei und die aufgezeichneten Sitzungen gegangen, um zu sehen,
woher jede Regel tatsächlich kam.

2. FESTSTELLUNGEN.

   2.1 Fast jede Regel hat einen benennbaren Auslöser. Ein Commit
   landete auf dem falschen Branch, weil der Shell-Zustand zwischen den
   Werkzeugaufrufen des Agenten nicht erhalten bleibt; noch am selben
   Tag eine neue Regel: absolute Pfade in jedem Git-Befehl. Eine
   veraltete Plattform-API rutschte durch ein Review; die nächste Regel:
   Externe Behauptungen werden gegen die offizielle Dokumentation
   geprüft, mit URL und Datum, nie aus dem Gedächtnis.

   2.2 Regeln ändern Verhalten schnell. Das riskante Git-Muster lief 15-
   bis 18-mal am Tag, bevor die Regel kam. Am Tag, an dem sie
   geschrieben wurde, stand die sichere Form 73 zu 9 vorn. Am Tag
   danach: null.

   2.3 Stabile Regeln haben eine Evolution: Gewohnheit, dann
   schriftliche Regel, dann Skript, dann Automatisierung. Unsere
   Ticket-Skripte gingen in der Woche nach ihrer Einführung von 0 auf
   156 Aufrufe pro Woche; von Hand gepflegte Termine verschwanden,
   sobald ein Scheduler sie übernahm.

   2.4 Version 1 einer Regel ist ein Entwurf. Die meistbearbeitete
   Regeldatei wurde an einem Tag sechsmal geändert, bevor sie saß. Das
   ist kein Hin und Her; das ist der angemessene Preis einer Regel, die
   dann auch befolgt wird.

   2.5 Die am ersten Tag gesetzten Regeln (Tests laufen lassen, vor dem
   Commit prüfen) sind die einzigen, die nie einen Vorfall produziert
   haben. Sie hielten in jeder Woche des Projekts stand. Alles später
   Gelernte wurde erst in gleicher Münze bezahlt.

   2.6 Disziplin hat die Entwicklung nicht gebremst. Die menschliche
   Vetoquote blieb bei rund 1 % der Aktionen des Agenten, während das
   Wochenvolumen sich verneunfachte, und die regelreichste Woche war die
   lieferstärkste: elf Arbeitspakete an einem einzigen Tag
   abgeschlossen, ein Produktionsbetrieb in zwei Tagen aufgebaut.

3. ANNAHMEN. Ein Team, sieben Wochen: Korrelation, kein kontrolliertes
Experiment. Aber die Richtung ist über jede Projektphase gleich, und die
beiden Nebenprojekte erzählen dieselbe Geschichte – auch dort lesen sich
die Regeldateien wie Vorfallsprotokolle. Mein Favorit: Eine
Audioaufnahme im Hintergrund ließ das Mikrofonsymbol des Desktops
dauerhaft leuchten, und die Regel „Prüfe alles, was das System jetzt
anders macht, nicht nur das gewünschte Ergebnis“ wurde noch am selben
Tag geschrieben.

4. SCHLUSSFOLGERUNGEN. Regeln kosten den Vorfall, der sie begründet. Die
vorhersehbaren – Prüfung, Hygiene – lohnen sich vor jedem Vorfall zu
schreiben; sie waren die einzigen, die es umsonst gab. Für den Rest
gilt: Die Regel noch am selben Tag schreiben und den Vorfall in die
Regel hineinschreiben, denn das Warum ist es, was sie relevant macht.
Eine neue Regel ist ein Entwurf, Umschreiben eingeplant. Und wenn eine
Regel stabil wird, ausführbar machen; ein Validator vergisst nicht. Der
dauerhafte Gewinn: Was in Regeln und Code wandert, ist konsistent
überprüfbar und lässt sich bei Bedarf anwenden, statt im Gespräch neu
hergeleitet zu werden. Genau das ist der Stand außerhalb der Sitzung,
den die Kostenanalyse (TM-26-005) verlangt und der die ständig
wiederholte Analyse erspart.

5. MASSNAHMEN. Die Erster-Tag-Liste, die wir beim nächsten Projekt
setzen würden: eine Orientierungskarte, die der Agent zuerst liest;
Verhaltensregeln (nicht annehmen, sondern fragen; nicht über das Ziel
hinausplanen, sondern wiederverwenden); Prüfung vor dem ersten Commit;
ein vereinbarter Ort für jede Art von Entscheidung. Den Rest schreiben
dann die Vorfälle – eine Regel pro Narbe, am selben Tag.