Ich habe 5.119 KI-Outputs vermessen. Hier ist, was ich wirklich gelernt habe.
Ich habe zehn Wochen lang jede Datei vermessen, die Claude für mich geschrieben hat. Nicht stichprobenartig – vollständig. 5.119 Datenpunkte über 35 Projekte, automatisch erfasst per Git-Hook nach jeder Session. Edit-Distanz zwischen Claude-Original und dem, was am Ende im Repository steht.
Die Hypothese: Wenn ich Korrekturen als Regeln formalisiere und in den Prompt injiziere, sinkt die Korrekturquote über Zeit. Konvergenz. Messbarer Lerneffekt ohne Fine-Tuning.
Die Hypothese stimmt. Teilweise. Der Rest ist interessanter als das Ergebnis.
Methodik
EPO (Evolutionary Prompt Optimization) ist ein Python-System, das als SessionEnd-Hook in Claude Code läuft. Nach jeder Session passiert automatisch:
- Git-Log scannen nach Commits mit `Co-Authored-By: Claude`
- Für jede Datei im Claude-Commit: Edit-Distanz zum nächsten menschlichen Commit berechnen (Levenshtein-Ratio, normalisiert auf [0, 1])
- Score speichern (SQLite, lokal)
- Gelernte Regeln in `CLAUDE.md` injizieren – die Datei, die Claude bei jeder Session als Systemprompt liest
Edit-Score 0.0 = Datei unverändert übernommen. Edit-Score 1.0 = vollständig umgeschrieben. Der Vergleichspunkt ist immer der nächste Commit, nicht HEAD – sonst würde spätere Weiterentwicklung als Korrektur gezählt.
Rohdaten
| Woche | n | μ (Mean) | Median | P95 | Null-Rate |
|---|---|---|---|---|---|
| W11 | 66 | 3,68% | 0,00% | 35,5% | 81,8% |
| W12 | 371 | 3,52% | 0,00% | 21,6% | 67,1% |
| W13 | 2.409 | 2,47% | 0,00% | 12,0% | 82,0% |
| W15 | 600 | 1,02% | 0,00% | 3,1% | 87,2% |
| W16 | 263 | 0,01% | 0,00% | 0,0% | 98,5% |
| W17 | 391 | 0,74% | 0,00% | 0,1% | 91,8% |
| W18 | 259 | 1,69% | 0,00% | 7,0% | 91,9% |
| W19 | 303 | 0,53% | 0,00% | 1,1% | 94,1% |
| W20 | 101 | 2,99% | 0,00% | 19,1% | 77,2% |
| W21 | 337 | 1,25% | 0,00% | 6,8% | 88,7% |
Drei Beobachtungen, die sofort auffallen:
1. W13 dominiert den Datensatz. 2.409 von 5.119 Datenpunkten (47%) stammen aus einer Woche. Ein einzelnes Großprojekt verzerrt den Gesamtdurchschnitt. Jede aggregierte Aussage über den Datensatz ist im Grunde eine Aussage über diese eine Woche.
2. Der Mittelwert ist nutzlos. Der Median ist in jeder Woche 0,00% – die Verteilung ist extrem rechtsschief: 85% der Dateien werden unverändert übernommen, wenige Ausreißer treiben den Mean hoch. Das 95. Perzentil (P95) ist das bessere Maß: Es fällt von 35,5% in W11 auf unter 7% in W21. Der Trend liegt in den Tails, nicht im Durchschnitt.
3. W20 bricht den Trend – oder doch nicht? Nach vier Wochen sinkender Scores springt W20 auf 3,0%. Bei n=101 und der vorliegenden Varianz lässt sich das nicht sauber von Rauschen trennen – der P95 von 19,1% zeigt, dass wenige Ausreißer den Mean verzerren. Ohne Konfidenzintervalle oder einen Mann-Whitney-U-Test gegen die Vorwochen bleibt offen, ob W20 ein Trendbruch ist oder ein Stichprobenartefakt.
Konfundierungen
Vier Faktoren, die ich nicht kontrolliert habe:
Projekt-Effekt. Die Projekte sind nicht gleichverteilt. Das Projekt mit dem niedrigsten Edit-Score liegt bei 0,08%, das mit dem höchsten bei 8,5%. Wenn ich in einer Woche hauptsächlich an Low-Edit-Projekten arbeite, sinkt der Wochenschnitt – ohne dass EPO etwas dazu beigetragen hat.
| Projekt | n | μ Edit-Score |
|---|---|---|
| Blog (Content) | 443 | 0,08% |
| Website (Frontend) | 828 | 0,75% |
| Plattform (Full-Stack) | 924 | 1,19% |
| Home Automation | 263 | 4,16% |
| Angebotsprojekt A | 149 | 7,70% |
| Dashboard-Prototyp | 172 | 8,48% |
Operator-Effekt. Ich werde besser im Prompting. Über zehn Wochen lernt man, wie man Claude fragen muss. Um das vom System-Effekt zu trennen, habe ich die Edit-Scores innerhalb einzelner Projekte über Zeit verglichen – das eliminiert den Projekt-Effekt. Statt Cherry-Picking (erste vs. letzte Woche) eine Spearman-Rangkorrelation über alle Messwochen pro Projekt:
| Projekt | Wochen | n | ρ (Spearman) |
|---|---|---|---|
| Blog (Content) | 6 | 443 | −0,83 |
| Home Automation | 9 | 265 | −0,68 |
| Backend-Projekt A | 8 | 318 | −0,64 |
| Backend-Projekt B | 8 | 157 | −0,62 |
| Website (Frontend) | 8 | 828 | −0,41 |
| Ops/Tooling | 8 | 222 | −0,16 |
| IoT-Projekt | 6 | 268 | +0,26 |
10 von 12 Projekten mit ≥5 Messwochen zeigen eine negative Korrelation – fallende Edit-Scores über Zeit. 5 davon mit ρ < −0,6 (starker monotoner Zusammenhang). Das ist ein robusteres Signal als die aggregierte Wochenkurve, weil der Projekt-Effekt kontrolliert ist.
Aber: Operator-Effekt und System-Effekt sind auch hier nicht trennbar. Ich lerne das Projekt kennen und EPO sammelt projektspezifische Regeln. Co-Evolution, keine Einbahnstraße.
Es gibt allerdings einen zweiten Datensatz, der den Operator-Effekt stützt. Ich tracke parallel meine Claude-Code-Sessions: Kosten, Token, Tool-Aufrufe. Die Metrik Tools pro Nachricht misst, wie viele Tool-Aufrufe Claude pro User-Message ausführt – ein Proxy dafür, wie autonom Claude arbeiten kann. Über 20 Wochen:
- **KW 10:** 1,5 Tools/Message
- **KW 22:** 7,4 Tools/Message
Das ist ein 5-facher Anstieg. Ich gebe komplexere Aufgaben, formuliere Prompts so, dass Claude mehr eigenständig erledigt. Das ist kein EPO-Effekt – das ist Operator-Lernen. Die Edit-Scores sinken möglicherweise nicht, weil das System besser wird, sondern weil ich besser werde.
Dateityp-Konfundierung. Die höchsten Edit-Scores kommen von Excel-Dateien, HTML-Präsentationen und JSON-Dumps – Dateitypen, bei denen ein geändertes Byte die Distanz explodieren lässt. Diese Dateien sind keine Qualitätssignale, sondern Messartefakte.
Fehlende Baseline. Wie viel übernimmt ein vergleichbarer Claude-Code-Nutzer ohne EPO? Ohne Kontrollgruppe ist 96% Übernahmerate eine Zahl, kein Ergebnis.
Was EPO automatisch lernt
EPO extrahiert Conventions aus den Edit-Daten. Nach 5.119 Datenpunkten hat das System 45 aktive Regeln. Die automatisch generierten:
„Outputs werden selten editiert. Aktuellen Stil und Detailgrad beibehalten.“
Das ist eine Tautologie. Die Daten zeigen niedrige Edit-Scores, also generiert das System die Regel, den Stil beizubehalten. Die Regel hat keinen Informationsgehalt über das hinaus, was die Metrik bereits aussagt.
Das Grundproblem: epo learn korreliert aggregierte Scores mit vorgefertigten Regelschablonen. Es gibt kein Signal dafür, was an einem Output schlecht war – nur dass etwas geändert wurde. Edit-Distanz ist ein skalares Signal. Für nützliche Regeln bräuchte man semantisches Verständnis der Korrektur.
Was tatsächlich funktioniert
Die wertvollsten Conventions sind manuell eingetragen. Nicht extrahiert, nicht gelernt – geschrieben, nachdem Claude den gleichen Fehler wiederholt hat:
Fabrication-Guard. „Keine Zitate erfinden oder realen Personen in den Mund legen, auch nicht wenn es narrativ perfekt passt.“ – Entstanden nachdem Claude einem realen Menschen ein erfundenes Zitat zugeschrieben hat. In einem Blogpost. Kein Edit-Score hätte das gefunden. Der Score der Datei war niedrig, weil nur ein Satz falsch war.
Epistemic Modesty. „Bei Compliance-Argumenten zuerst Reality-Check durchführen.“ – Claude eskaliert Datenschutz- und Sicherheitsbedenken reflexartig. Die Regel zwingt zur Prüfung: Was fließt tatsächlich? Welches Szenario löst den Schaden aus?
Context-Decay-Warning. „Bei längeren Sessions aktiv Warnsignale erkennen – Themen-Sprünge, >80k Kontext, Wiederholungen.“ – LLMs werden nach langem Kontext unschärfer, sagen das aber nicht von allein.
Diese Regeln verändern Outputs messbar. Nicht weil ein Algorithmus sie aus Metriken extrahiert hat, sondern weil ein Mensch aus einem konkreten Fehler eine explizite Anweisung formuliert hat. Der Mechanismus ist nicht Machine Learning. Es ist eine Textdatei.
Verwandte Arbeiten
CIPHER (Gao et al., NeurIPS 2024) nutzt denselben Kernmechanismus: Edit-Distanz als implizites Feedback, ohne Fine-Tuning, Regelinjektion in den Prompt. Microsoft Research und Cornell, publiziert im April 2024 – fast zwei Jahre bevor ich mit EPO angefangen habe.
Der Unterschied: CIPHER leitet eine natürlichsprachliche Präferenzbeschreibung pro Nutzer ab. EPO führt eine gescorte Datenbank mit Einzelregeln und scope-abhängiger Injektion (global/personal/projekt). Ob das einen praktischen Unterschied macht, kann ich mit meinen Daten nicht beantworten – dafür bräuchte es einen kontrollierten Vergleich.
Dass zwei unabhängige Implementierungen auf den gleichen Ansatz konvergieren, ist ein Hinweis, dass die Idee naheliegt. Dass keiner von uns einen sauberen Kausalitätsnachweis hat, ist ein Hinweis, dass das Problem schwieriger ist als das Tooling.
Drei Ergebnisse
1. Das Gedächtnis ist wichtiger als das Lernen.
LLMs vergessen zwischen Sessions alles. Eine Textdatei mit 20 Regeln, die bei jedem Start geladen wird, hat mehr Effekt als jeder Optimierungsalgorithmus. Die technisch anspruchsvollste Komponente von EPO – die Edit-Distanz-Berechnung, die Konvergenz-Metriken, das Template-Genom – hat weniger bewirkt als CLAUDE.md mit manuell geschriebenen Regeln.
Und es gibt ein zweites Gedächtnis, das noch zuverlässiger ist: Git. Die Commit-History ist das robusteste Langzeitgedächtnis, das ein KI-Workflow haben kann – jede Korrektur, jede Entscheidung, jeder Revert, datiert und unveränderlich. EPO nutzt genau das als Datenquelle. Aber die Erkenntnis ist: Die History selbst ist wertvoller als das, was EPO daraus extrahiert.
2. Implizites Feedback ist zu dünn für semantisches Lernen.
Edit-Distanz sagt: etwas wurde geändert. Nicht: was falsch war. Ein erfundenes Zitat hat einen Edit-Score von 0,02 (ein Satz in einer langen Datei). Eine umformatierte Excel-Tabelle hat 0,98. Das Signal-Rausch-Verhältnis ist zu niedrig für automatische Regelextraktion. CIPHER umgeht das, indem es ein LLM die Edits interpretieren lässt – ein vielversprechender Ansatz, den ich nicht implementiert habe.
3. Messen erzeugt Disziplin, nicht Beweise.
Der eigentliche Wert von EPO ist nicht die Konvergenz-Kurve. Es ist die Gewohnheit, Korrekturen zu formalisieren. Wenn ich etwas ändere und es stört mich genug, schreibe ich eine Regel. Ohne das System hätte ich das nicht getan – nicht aus 45 Korrekturen, und nicht über 35 Projekte synchronisiert. Das Messsystem hat die Disziplin erzeugt, die das Messsystem überflüssig macht.
—
EPO ist Open Source unter AGPL-3.0: github.com/tkoerting/epo-framework
Teil 3 einer Serie über KI-Qualitätsmessung. Vorher: What If Your AI Learned From Every Edit You Make? · KI-Tools vergessen was sie lernen