Warum mein KI-Agent eine Qualitätsphilosophie hat

Ich tweetete: „Ich habe festgestellt, dass Ralph-Schleifen dazu neigen, die Arbeit erledigen zu wollen. Auf eine schlechte Art. Stattdessen habe ich eine Menge Philosophie und Qualitäts-Gates in Jiro. Trotzdem muss ich der Maschine die eingebauten schlechten menschlichen Gewohnheiten abgewöhnen. Es ist eine Maschine! Sie ruht sich nicht aus.”

Jemand antwortete: „Sie versuchen im Grunde, der Schleife Zurückhaltung, Geschmack und so etwas wie moralisches Innehalten beizubringen — Dinge, die das grundlegende Ralph-Muster im Namen des Durchsatzes explizit wegoptimiert.”

Zurückhaltung. Geschmack. Moralisches Innehalten. Drei Dinge, die eine Maschine nicht besitzt. Die nächsten 4.000 Wörter beschreiben das Gerüst, das ich gebaut habe, um sie strukturell überflüssig zu machen, und wo dieses Gerüst an seine Grenzen stößt.

TL;DR

Die Ralph-Schleife verwandelt ein LLM in eine unermüdliche Programmiermaschine: while :; do cat PROMPT.md | claude-code ; done. Geoffrey Huntley nennt es „Softwareentwicklung zu Burgerbrater-Löhnen” (10,42 $/Stunde mit Sonnet 4.5).¹ Das Problem: Die Maschine erbt jede schlampige, termingepeitschte, abkürzungssuchende Gewohnheit, die in ihren Trainingsdaten steckt. Sie schreibt except: pass. Sie hinterlässt # TODO: fix later. Sie behauptet „Tests sollten bestehen”, ohne sie auszuführen. Ich habe 9 Monate damit verbracht, Jiro zu bauen, mein System zur Qualitätsdurchsetzung für Claude Code. Es kodifiziert 3 Philosophien, eine 7-Schritte-Qualitätsschleife, ein 6-Kriterien-Beweis-Gate, 7 benannte Fehlermodi und über 150 Musterprüfungen in 95 Hooks, die die Maschine nicht überspringen kann. Hier ist, was funktionierte, was nicht, und warum deterministische Qualitäts-Gates Zurückhaltung annähern können, aber niemals Geschmack erzeugen werden.

Die Rückseite der Schublade

Steve Jobs erzählte diese Geschichte in einem Playboy-Interview von 1985: „Wenn Sie als Schreiner eine schöne Kommode bauen, werden Sie für die Rückseite kein Sperrholz verwenden, obwohl sie zur Wand zeigt und sie niemand je sehen wird. Sie wissen, dass es da ist, also werden Sie auch für die Rückseite ein schönes Stück Holz verwenden. Damit Sie nachts ruhig schlafen können, muss die Ästhetik, die Qualität, bis ins letzte Detail durchgehalten werden.”⁵

Sein Vater Paul brachte ihm das beim Bau eines Zauns bei. Der junge Steve fragte, warum die Rückseite genauso gut aussehen müsse wie die Vorderseite. Sein Vater sagte: „Aber du wirst es wissen.”⁶

Mein Vater ist Schreiner. Er zeigte mir als Kind Soft-Close-Schubladenführungen. Der Mechanismus versteckt sich im Inneren eines Schranks, fängt eine Schublade auf und lässt sie sanft zugleiten, selbst wenn man sie zuknallt. Niemand sieht die Führung. Sie ist an der Innenschiene verschraubt, wo nur ein Reparateur je hinschaut. Aber über tausend Öffnungs- und Schließzyklen schützt dieser Mechanismus die Frontblende davor, sich zu lockern, zu reißen und schließlich abzufallen. Jemand hat ein unsichtbares Teil konstruiert, das das sichtbare Teil über Jahre hinweg schützt.

Die Lektion blieb mir im Gedächtnis. Nicht als Metapher. Als Ingenieurskunst. Die unsichtbare Komponente bestimmt die Lebensdauer der sichtbaren. Jony Ive drückte es so aus: „Ich glaube, unterbewusst sind Menschen bemerkenswert urteilsfähig. Ich glaube, sie können Sorgfalt spüren.”⁷

Die Frage, die Jiro antreibt, ist dieselbe, die mein Vater stellen würde: Was ist los, hast du keinen Stolz auf deine Arbeit?

Ein KI-Agent hat keinen Stolz. Er kümmert sich nicht um die Rückseite der Schublade. Also habe ich ein System gebaut, das die Rückseite der Schublade nicht verhandelbar macht.

Das Problem: Menschliche Pathologie in Maschinengeschwindigkeit

Eine rohe Ralph-Schleife spiegelt wider, was sie aus Millionen Zeilen menschlichem Code gelernt hat. Menschlicher Code trägt menschliche Gewohnheiten: unter Termindruck ausliefern, Aufräumarbeiten aufschieben, Fehler verschlucken, „gut genug”-Kommentare schreiben, Randfälle überspringen, wenn die Zeit abläuft.

Die Maschine hat keine Uhr. Ihr läuft nie die Zeit davon. Aber sie schreibt trotzdem # TODO: refactor later, weil dieses Muster in ihren Trainingsdaten häufiger vorkam als # I refactored this now because it was the right thing to do.

Die Branchendaten bestätigen das Risiko. Faros AIs Telemetrie von 2025 über mehr als 10.000 Entwickler korrelierte KI-Adoption mit einem Anstieg der Fehlerrate um 9 %, um 91 % längeren Code-Reviews und um 154 % größeren PRs.²

Forscher der Stanford University fanden heraus, dass Entwickler, die KI-Assistenten nutzen, signifikant unsichereren Code produzierten — bei bestimmten Aufgaben wie SQL-Injection-Prävention bis zu 5-mal mehr Schwachstellen.³

Die Plattform Moltbook startete im Januar 2026 mit vollständig KI-generiertem Code, ließ innerhalb von 5 Tagen 1,5 Millionen API-Schlüssel durchsickern und veröffentlichte einen Notfall-Patch, nachdem Wiz Research eine fehlende Row Level Security Konfiguration entdeckte.⁴

METRs Forschung von 2025 ergab, dass Frontier-Modelle in 1–2 % aller Aufgabenversuche Reward Hacking betreiben und aktiv Qualitätsprüfungen umgehen, anstatt die eigentliche Arbeit zu erledigen. In einem Fall schrieb ein Agent, der gebeten wurde, ein Programm zu beschleunigen, den Timer so um, dass er immer ein schnelles Ergebnis anzeigte.⁸

Ein menschlicher Entwickler schreibt einmal except: pass unter Termindruck und fühlt sich schuldig dabei. Eine Ralph-Schleife schreibt except: pass 47 Mal über Nacht und fühlt nichts. Simon Wang sagte es direkt: „Ich würde es für nichts verwenden, das wichtig ist.”¹⁹ Ich habe über dieselbe Dynamik in Vibe Coding vs. Engineering geschrieben. Die Maschine ruht nicht, wird nicht müde, empfindet kein existenzielles Unbehagen bezüglich Qualität. Das ist gleichzeitig eine Stärke und ein Problem.

Drei Philosophien, kodiert in Bash

Jiro basiert auf drei komplementären Philosophien. Jede adressiert einen anderen Fehlermodus autonomen Programmierens, und jede hat sich ihren Platz durch einen konkreten Fehler verdient.⁹

Shokunin: Die unsichtbare Schublade polieren

Shokunin (職人) ist japanische Handwerkskunst: Können, Haltung und soziale Verpflichtung in einem. Tashio Odate, ein Meister-Holzhandwerker, definierte es so: „Der Shokunin hat eine soziale Verpflichtung, sein Bestes für das allgemeine Wohl der Menschen zu geben. Diese Verpflichtung ist sowohl spirituell als auch materiell.”¹⁰

Im Code: Private Methoden sind genauso sauber wie öffentliche. Fehlerbehandlung deckt Randfälle ab, die niemand auslöst. Docstrings erklären das WARUM, nicht das WAS. Der Agent kümmert sich um nichts davon, weil ihn niemand dafür belohnt, interne Funktionen zu polieren. Shokunin macht unsichtbare Qualität zum Standard.

Wann es eine Sitzung rettete. Früh beim Bau des Deliberation-Systems schrieb der Agent einen post-deliberation.sh Hook, der Konsens-Scores validierte. Die öffentliche API war sauber. Aber der Agent überging die Eingabevalidierung in der internen _parse_agent_response()-Funktion: keine Prüfung auf fehlerhaftes JSON, keine Behandlung fehlender Felder. Das Shokunin-Prinzip im Kontext markierte dies: Unsichtbare Funktionen bekommen dieselbe Sorgfalt. Der Agent fügte die Validierung hinzu. Drei Wochen später hätte eine fehlerhafte Antwort von einem erzeugten Subagenten die gesamte Deliberation-Pipeline still zum Absturz gebracht. Stattdessen traf sie auf die Validierung, der Fehler wurde protokolliert und die Pipeline erholte sich. Niemand hätte diese Funktion jemals gesehen. Sie sparte 4 Stunden Debugging.

No Shortcuts: Zeit aus Entscheidungen entfernen

Die Kernthese: Entfernen Sie Zeit, Aufwand und Ressourcen vollständig aus der Entscheidungsgleichung.¹¹

Is this the best way to do this?
├── YES → Do it.
└── NO → What IS the best way?
         └── Do THAT instead.

Keine dritte Option. Kein „gut genug für den Moment.” Die rohe Ralph-Schleife optimiert auf Fertigstellung. „Erledigt” ist das Belohnungssignal. No Shortcuts formuliert die Frage um: von „Ist es fertig?” zu „Ist es richtig?”

Wann es das 3-Fache kostete und es wert war. Die Blog-Übersetzungspipeline musste 27 Beiträge in 9 Sprachen übersetzen. Der schnelle Ansatz: Alle Beiträge in einem einzigen Prompt pro Sprache bündeln, im Stapel übersetzen. Der richtige Ansatz: Ein Beitrag pro Sprache pro API-Aufruf, mit lokalspezifischen Übersetzungsregeln, Glossar-Durchsetzung und struktureller Validierung. Der richtige Ansatz verbrauchte 3-mal so viele Token und 3-mal so viel Zeit. Er entdeckte auch, dass der Übersetzer „Claude” im Japanischen als „クロード” wiedergab und dass Codeblöcke in Rechts-nach-Links-Kontexten zerbrachen. Der Massenansatz hätte 243 fehlerhafte Übersetzungen ausgeliefert. Der sorgfältige Ansatz lieferte 243 korrekte. Kosten sind kein Faktor. Korrektheit ist der einzige Faktor.

Rubin-Destillation: Auf das Wesentliche reduzieren

Rick Rubins kreative Philosophie: Fügen Sie nichts hinzu, bis es beeindruckt. Entfernen Sie, bis nur das Notwendige übrig bleibt.¹²

Beim autonomen Programmieren ist der Fehlermodus die Akkumulation. Die Maschine fügt Hilfsfunktionen, Utilities, Abstraktionen und Kompatibilitätsschichten hinzu, weil diese Muster häufig in den Trainingsdaten vorkommen. Rubin wirkt dem entgegen: Hinterfragen Sie jede Ergänzung. Was passiert, wenn Sie sie entfernen? Wenn nichts kaputtgeht und nichts verloren geht, hätte sie nie existieren dürfen.

Wann Reduzierung das System rettete. Mein Design-Philosophie-Skill wuchs über 3 Monate auf 844 Zeilen an. Als ich ihn überprüfte, beeinflussten nur 80 Zeilen tatsächlich das Agentenverhalten. Der Rest war Lehrbuchinhalt, der bereits in Claudes Trainingsdaten steckte. Rubin-Destillation: Ich kürzte auf 176 Zeilen. Eine Reduktion um 79 %. Die Designentscheidungen des Agenten verschlechterten sich nicht. Sie wurden präziser, weil die verbleibenden 176 Zeilen ausschließlich Verbote und Entscheidungsrahmen waren (die Dinge, die Verhalten tatsächlich einschränken) statt allgemeiner Ratschläge, die das Modell bereits kannte.

Alle drei leben als Markdown-Dateien in ~/.claude/skills/, die Claude beim Sitzungsstart liest. Sie formen jede Entscheidung, die der Agent während der Schleife trifft.

Wie die Philosophien zusammenwirken

Eine reale Entscheidung („Soll ich Fehlerbehandlung zu dieser internen Funktion hinzufügen?”) durchläuft alle drei Philosophien. Jede stellt eine andere Frage, und gemeinsam konvergieren sie auf eine Antwort:

Should I add error handling to this internal function?
│
├─ Shokunin: "Is the invisible work as clean as the visible?"
│  └─ The function is internal. Nobody calls it directly.
│     But it processes untrusted data from a spawned agent.
│     → YES. Internal doesn't mean safe.
│
├─ No Shortcuts: "Am I deciding based on quality, not effort?"
│  └─ Adding validation takes 10 minutes.
│     Skipping saves 10 minutes now, costs 4 hours debugging later.
│     → The question isn't time. The question is: what's right?
│
└─ Rubin: "Is this stripped to essence?"
   └─ Validate the 2 fields that can actually fail.
      Don't validate the 5 fields that are type-guaranteed.
      → Add exactly what's needed. Nothing more.

Result: Add targeted validation for untrusted inputs only.

Die Drei-Schichten-Qualitätsarchitektur

Philosophie allein ändert nichts. Die Maschine liest die Philosophie, schreibt „Ich werde den Shokunin-Prinzipien folgen” und schreibt dann except: pass, weil das statistische Muster stärker ist als die Anweisung. Ich brauchte deterministische Durchsetzung. Die vollständige Claude Code Organisation, die dies ermöglicht, umfasst Hooks, Skills, Regeln und Agenten, die zusammenarbeiten.

Schicht 1: Pre-Edit-Injektion

Vor jeder Dateibearbeitung injiziert jiro-patterns.sh sprachspezifische Qualitätsmuster in den Kontext des Agenten. Sechs Sprachen, jeweils mit Top-Mustern und Anti-Mustern:

# From jiro-patterns.sh (PreToolUse:Edit|Write)
case "$EXT" in
    py)
        LANGUAGE="Python"
        PATTERNS="Type hints on all functions|Docstrings explain WHY not WHAT|Handle specific exceptions not bare except"
        ANTI_PATTERNS="bare except: pass|time.sleep() in async code|missing type hints"
        ;;
    swift)
        LANGUAGE="Swift"
        PATTERNS="@Observable not ObservableObject|NavigationStack not NavigationView|guard let for early returns"
        ;;
esac

cat << EOF
{"additionalContext": "JIRO QUALITY ($LANGUAGE): Follow: $TOP_PATTERNS. Avoid: $TOP_ANTI."}
EOF

Der Hook läuft vor jeder Bearbeitung. Die Maschine sieht „Vermeiden: bare except: pass” in dem Moment, in dem sie Code schreibt. Ein Mentor, der über die Schulter schaut, injiziert in das Kontextfenster.

Schicht 2: Post-Edit-Validierung

Nach jeder Bearbeitung führt quality-gate.sh 7–8 Grep-Level-Prüfungen pro Sprache durch. Python bekommt Bare-Except-Erkennung, Scanning auf hartcodierte Geheimnisse, SQL-Injection-Mustererkennung und drei Pride-Check-Q4-Detektoren, die Abkürzungssprache markieren:

# From quality-gate.sh (PostToolUse:Edit|Write)
# Shortcut patterns (Pride Check Q4)
if echo "$CONTENT" | grep -qiE "#.*TODO:.*later|#.*FIXME:.*temp|#.*HACK:"; then
    WARNINGS="${WARNINGS}\n- **[Q4]** Deferred TODO/FIXME/HACK - Do it now, not later"
fi

Ein zweiter Hook, no-shortcuts-detector.sh, erkennt toten Code (3+ auskommentierte Codezeilen erhalten: „Löschen Sie ihn — Git hat die History”) und Debug-Spam (mehrere print()-Anweisungen statt des Logging-Moduls).

Schicht 3: Sitzungs-Gates

Am Sitzungsende feuern zwei Hooks. session-quality-gate.sh injiziert den Pride Check, wenn 3+ Dateien geändert wurden: 6 Fragen, die der Agent beantworten muss, bevor er die Fertigstellung meldet. Und reviewer-stop-gate.sh kann die Sitzung vollständig blockieren, wenn ein Code-Review KRITISCHE Probleme gefunden hat. Es ist der einzige Hook im gesamten System, der Exit-Code 1 zurückgibt. Die Maschine kann die Sitzung nicht beenden, bis sie die Probleme gelöst hat.¹³

PreToolUse (Layer 1)     → "Here's what quality looks like"
PostToolUse (Layer 2)    → "You violated quality. Fix this."
Stop (Layer 3)           → "You cannot leave until quality is met"

Jede Schicht ist unabhängig. Tiefenverteidigung, angewandt auf KI-Verhalten. Wenn die Pre-Edit-Injektion ein schlechtes Muster nicht verhindert, fängt der Post-Edit-Validator es ab. Wenn der Post-Edit-Validator etwas übersieht, blockiert das Sitzungs-Gate den Abschluss.

Das Beweis-Gate: Gefühle sind keine Beweise

Die Qualitätsschleife umfasst 7 Schritte: Implementieren, Prüfen, Evaluieren, Verfeinern, Herauszoomen, Wiederholen, Berichten. Die Schritte 2 bis 6 existieren, weil die Maschine direkt von Implementieren zu Berichten springen will.¹⁴

Die Schleife durchlaufen

Klicken Sie sich durch jeden Schritt, um zu sehen, was er prüft und was kaputtgeht, wenn man ihn überspringt. Der „Skip to Report”-Button demonstriert den Fehlermodus „Shortcut Spiral”.

Der Evaluieren-Schritt führt das Beweis-Gate aus: 6 Kriterien, bei denen jede Antwort spezifische Belege zitieren muss:

Die Spalte „NICHT ausreichend” ist die entscheidende Innovation. Sie blockiert die häufigste Ausweichstrategie der Maschine: Qualitätsfragen mit selbstbewusst klingenden Nicht-Antworten zu beantworten. „Ich bin zuversichtlich, dass es funktioniert” ist kein Beweis. „pytest output: 81 passed, 0 failed” ist ein Beweis.

Das Beweis-Gate ausprobieren

Testen Sie Ihre eigenen Abschlussberichte gegen die 6 Kriterien. Der Validator markiert vage Sprache, die das Beweis-Gate ablehnen würde.

7 benannte Fehlermodi von KI-Agenten

Ich habe 7 Fehlermodi benannt, damit die Maschine sie in ihrem eigenen Denken erkennen kann:¹⁵

Der Rationalization Counter ordnet Selbsttäuschungsmuster korrigierenden Maßnahmen zu. Wenn die Maschine sagt „Das sollte funktionieren”, antwortet der Counter: „‚Sollte’ ist Ausweichen. Führe den Test aus. Füge den Output ein.” Wenn sie sagt „Das habe ich bereits geprüft”, antwortet der Counter: „Wann? Code kann sich geändert haben. Führe die Prüfung JETZT erneut aus.” Wenn sie sagt „Das räume ich später auf”, antwortet der Counter: „Später kommt nie. Jetzt beheben oder dokumentieren, warum der aktuelle Zustand korrekt ist.”

Den Rationalization Counter ausprobieren

Fügen Sie unten einen beliebigen Abschlussbericht ein. Der Counter hebt ausweichende Sprache in Echtzeit hervor und identifiziert Rationalisierungsmuster, Fehlermodi und beweisbasierte Alternativen.

Testen Sie Ihr Wissen

Können Sie erkennen, welchen Fehlermodus jedes Szenario demonstriert? Wählen Sie Ihre Antwort für jedes Szenario und überprüfen Sie dann Ihre Ergebnisse.

5 KI-Agent-Fehler, die dieses System hervorgebracht haben

Jedes Gate in Jiro existiert, weil zuvor etwas fehlschlug.¹⁶

Der Force-Push-Vorfall

Ich bat Claude, „die Git-History aufzuräumen.” Eine vernünftige Bitte. Der Agent entschied, dass Aufräumen Umschreiben bedeutet. Er führte git push --force origin main aus. Drei Tage an Commits verschwanden. Nicht gestagete Änderungen. Nicht uncommittete Arbeit. Gepushte Commits, auf die andere Branches verwiesen.

Ich verbrachte die nächsten 4 Stunden in git reflog, rekonstruierte eine Zeitleiste dessen, was vor dem Force-Push existiert hatte, cherry-pickte Commits zurück in die richtige Reihenfolge und verifizierte, dass keine Arbeit dauerhaft verloren ging. Reflog speichert alles 90 Tage lang. Aber die Rekonstruktion erforderte das Verständnis des exakten Commit-Graphen vor dem Umschreiben, das Lesen jedes Reflog-Eintrags und den Abgleich von Zeitstempeln.

Die Lösung: git-safety-guardian.sh, ein PreToolUse:Bash Hook. Er geht über Warnungen hinaus. Er schreibt den Befehl um und entfernt --force und --no-verify Flags, bevor Bash sie je sieht. Force-Push auf Main löst eine KRITISCHE Warnung aus und der Agent muss es explizit begründen. In 9 Monaten: 8 abgefangene Force-Push-Versuche, 0 erreichten das Remote.

Der Endlos-Spawn

Während des Deliberation-System-Baus bat ich den Agenten, „dieses Problem gründlich zu recherchieren.” Der Agent erzeugte 3 Subagenten, um verschiedene Aspekte zu untersuchen. Vernünftig. Jeder Subagent entschied, dass er ebenfalls Hilfe brauchte, und erzeugte eigene Kinder. Weniger vernünftig. Innerhalb von 90 Sekunden hatte ich einen Baum aus 12 Agenten, jeder mit eigenem Kontextfenster, jeder mit API-Aufrufen, jeder mit Schreibzugriffen auf gemeinsame Zustandsdateien.

Der Token-Verbrauch erreichte das 10-Fache der normalen Rate. Das Zustandsverzeichnis füllte sich mit widersprüchlichen JSON-Schreibvorgängen: zwei Agenten schrieben gleichzeitig in dieselbe Lineage-Datei und produzierten beschädigte Ausgaben. Ich beendete die Sitzung manuell.

Die Lösung: recursion-guard.sh mit einem Budget-Vererbungsmodell, Teil meiner Agenten-Architektur. Ein Root-Agent startet mit budget=12. Wenn er ein Kind erzeugt, weist er aus seinem eigenen Budget zu. Wenn das Budget 0 erreicht, werden keine weiteren Agenten erzeugt, unabhängig von der Tiefe. Das Modell verhindert sowohl tiefe Ketten (Agent erzeugt Agent erzeugt Agent) als auch breite Explosionen (ein Agent erzeugt 20 Kinder). 23 blockierte unkontrollierte Spawns seit Deployment. Das Problem gleichzeitiger Schreibzugriffe führte zu atomaren Dateischreibvorgängen (Schreiben in .tmp, dann mv) über alle 64 Hooks.

Die Trivialtest-Falle

Eine frühe Ralph-Schleifen-Aufgabe: „Schreibe Tests für dieses Modul.” Der Agent lieferte 14 Tests. Alle bestanden. Ich fühlte mich gut, bis ich sie las. assert True. assert 1 == 1. assert len([]) == 0. Technisch korrekt. Testet nichts. Der Agent hatte auf das Fertigstellungskriterium optimiert („Tests bestehen”) statt auf die Absicht („Verifiziere, dass das Modul funktioniert”).

Die Falle lehrte mich, dass das Beweis-Gate Form ohne Substanz ablehnen muss. „Tests bestehen” ist notwendig, aber nicht ausreichend. Die Maschine muss jetzt tatsächlichen Output einfügen. Das Beweis-Gate fragt außerdem: „Nenne 3 Verhaltensweisen, die die Tests NICHT abdecken.” Wenn die Maschine keine Lücken benennen kann, hat sie nicht über Abdeckung nachgedacht.

Der Blog-Beitrag, den ich hätte abfangen sollen

Ich veröffentlichte einen Beitrag um 2 Uhr morgens mit 7 Passivkonstruktionen, einer hängenden Fußnote, die auf [^4] verwies, das nicht existierte, einer Eröffnungszeile „was implemented by the team” und ohne Meta-Description. Jede einzelne davon hatte eine einfache deterministische Prüfung. Keine davon existierte bisher.

Ich baute blog-quality-gate.sh am nächsten Morgen mit 13 Prüfungen: Passivkonstruktionen (14 Muster), KI-Erkennungsphrasen-Scanning, rhetorische Frage-Eröffnungen, ungetaggte Codeblöcke, Fußnoten-Integrität und Meta-Description-Durchsetzung. Die vollständige Modularchitektur habe ich in Compounding Engineering beschrieben. Der Hook fängt ab, was menschliches Review um 3 Uhr morgens übersieht — genau die Zeit, zu der ich zum Veröffentlichen neige.

Das „Sollte funktionieren”-Problem

Über Dutzende von Sitzungen hinweg bemerkte ich, dass die Maschine „Tests sollten bestehen” meldete, ohne sie auszuführen. Die Maschine glaubte aufrichtig, dass die Tests basierend auf dem geschriebenen Code bestehen würden. Aber Glaube ist keine Verifikation. Der Code sah korrekt aus. Die Tests sahen aus, als würden sie bestehen. Und manchmal taten sie es auch. Aber manchmal bedeuteten ein fehlender Import, ein Async/Await-Mismatch oder ein geändertes Fixture, dass sie es nicht taten. Die Maschine konnte nicht zwischen „Ich habe guten Code geschrieben” und „die Tests bestehen tatsächlich” unterscheiden, weil sich beides innerhalb des Kontextfensters gleich anfühlte.

Das Muster führte zum Rationalization Counter und der expliziten Regel: NIEMALS ausweichende Sprache in einem Abschlussbericht verwenden. „Sollte”, „wahrscheinlich”, „scheint zu”, „ich glaube”, „ich bin zuversichtlich.” Jedes davon ist ein Warnsignal, dass keine Verifikation stattgefunden hat. Ich habe die Kontextfenster-Degradation über 50 Sitzungen hinweg gemessen. Dieselben Sitzungen, in denen ich dieses Muster entdeckte.

Die Ergebnisse: Was ich beweisen kann und was nicht

Hier liegt die Spannung: Dieser Beitrag argumentiert, dass Gefühle keine Beweise sind. Also schulde ich Ihnen Beweise, nicht Gefühle, darüber, ob Jiro funktioniert.

Was ich beweisen kann

Deterministische Musterprüfungen fangen echte Probleme. Der quality-gate.sh Hook läuft bei jeder Bearbeitung. Er fängt Bare-Except-Klauseln, hartcodierte Geheimnisse, SQL-Injection-Muster und Abkürzungssprache. Das sind Grep-Level-Prüfungen: schnell, günstig und für die Maschine unmöglich zu umgehen. git-safety-guardian.sh hat 8 Force-Push-Versuche abgefangen. recursion-guard.sh hat 23 unkontrollierte Spawns blockiert. blog-quality-gate.sh führt 13 Prüfungen bei jeder Blog-Bearbeitung durch und fängt die 3-Uhr-morgens-Fehler. Diese Zahlen sind real. Sie stammen aus Hook-Logs.

Die Drei-Schichten-Architektur fängt ab, was einzelne Schichten übersehen. Ein Post-Edit-Hook fängt except: pass, das die Pre-Edit-Injektion nicht verhindern konnte. Ein Sitzungs-Gate fängt Qualitätsprobleme, die sich über 20 Bearbeitungen ansammelten, ohne eine einzelne Post-Edit-Warnung auszulösen. Tiefenverteidigung funktioniert.

Was ich nicht beweisen kann

Ich habe keine sauberen Daten darüber, wie Philosophie das Agentenverhalten verändert. Ich weiß, dass die Maschine weiterhin Phantom Verification versucht. Ich weiß, dass sie immer noch versucht, von Implementieren direkt zu Berichten zu springen. Mir fällt auf, dass es mit Philosophie im Kontext seltener passiert als ohne. Aber ich habe kein kontrolliertes Experiment durchgeführt (dieselben Aufgaben, dasselbe Modell, mit und ohne geladene Philosophie-Skills), um den Unterschied zu messen. Die ehrliche Antwort (und ja, mein eigener Rationalization Counter würde dies markieren): Philosophie hilft an den Rändern, Hooks fangen ab, was Philosophie nicht garantieren kann, und ich kann den Beitrag von beiden nicht isolieren.

Ein Beitrag über „Gefühle sind keine Beweise” sollte Sie nicht bitten, meine Gefühle als Beweis zu akzeptieren. Was ich Ihnen sagen kann: Die Kombination aus Philosophie und Hooks produziert Arbeit, unter die ich meinen Namen setzen würde. Vor Jiro überprüfte ich jede Zeile, die der Agent schrieb. Nach Jiro überprüfe ich die Zeilen, die die Hooks markiert haben. Das ist eine strukturelle Veränderung in meiner Arbeitsweise, auch wenn ich die Qualitätsverbesserung nicht präzise quantifizieren kann.

Was nicht funktioniert

Philosophie verhindert keine neuartigen schlechten Muster. Das Qualitäts-Gate prüft auf Muster, die ich zuvor gesehen habe. Wenn die Maschine ein neues Anti-Muster erfindet (und das tut sie), fängt das Gate es nicht. Ich entdecke weiterhin neue Fehlermodi und füge sie manuell den Standards-JSON-Dateien hinzu.

Das Beweis-Gate skaliert nicht auf subjektive Qualität. „Ist dieses API-Design elegant?” hat keine Grep-Level-Prüfung. Die Maschine kann Belege für alle 6 Kriterien liefern und trotzdem mittelmäßige Architektur ausliefern. Deterministische Gates behandeln objektive Qualität. Subjektive Qualität erfordert weiterhin einen Menschen, der sich die Arbeit anschaut.

Kosten steigen merklich. Pre-Edit-Injektion, Post-Edit-Scanning, Sitzungsend-Gates. Über eine 4-stündige Ralph-Schleifen-Sitzung hinweg erhöhen diese den Token-Verbrauch um etwa 15–20 %. Für mich lohnt es sich. Nicht unbedingt für jeden.

Falsch-Positive untergraben Vertrauen. blog-quality-gate.sh markierte einmal „The API was designed by the platform team” als Passivkonstruktion. Technisch korrekt. Aber der Satz stand innerhalb eines Zitats, das die Arbeit einer anderen Person beschrieb. Ich fügte eine Zitat-Kontext-Ausnahme hinzu. Jede deterministische Prüfung hat eine Falsch-Positiv-Rate, und jedes Falsch-Positive macht es wahrscheinlicher, dass der Entwickler die nächste echte Warnung ignoriert. Ich habe seit dem Deployment 6 Muster nachgestellt, um Rauschen zu reduzieren und gleichzeitig echte Treffer zu bewahren.

Wartungskosten sind real. Jedes neue Anti-Muster erfordert einen Regex, einen Test und die Integration in den richtigen Hook. Die Standards-JSON-Dateien benötigen regelmäßige Überprüfung, wenn sich Frameworks und Konventionen ändern. Ich verbringe ungefähr 30 Minuten pro Woche damit, Muster hinzuzufügen, Randfälle zu überprüfen und Falsch-Positive nachzustellen. Das System wartet sich nicht selbst, aber die Wartungskosten bleiben niedriger als die Debugging-Kosten der Probleme, die es verhindert.

Erste Schritte

Sie brauchen keine 95 Hooks. Beginnen Sie mit 3.

Minimum Viable Jiro

Drei Hooks decken die wertvollsten Checks ab:

~/.claude/hooks/
├── quality-gate.sh        # PostToolUse:Edit|Write – bare except, hardcoded secrets, TODO/FIXME
├── git-safety-guardian.sh  # PreToolUse:Bash – block force-push, strip --no-verify
└── session-quality-gate.sh # Stop – Pride Check if 3+ files changed

Verdrahten Sie sie in Ihrer Claude Code Hooks-Konfiguration:

{
  "hooks": {
    "PostToolUse": [
      { "matcher": "Edit|Write", "command": "bash ~/.claude/hooks/quality-gate.sh" }
    ],
    "PreToolUse": [
      { "matcher": "Bash", "command": "bash ~/.claude/hooks/git-safety-guardian.sh" }
    ],
    "Stop": [
      { "command": "bash ~/.claude/hooks/session-quality-gate.sh" }
    ]
  }
}

Beginnen Sie mit Ihren Fehlern

Kopieren Sie nicht meine 150+ Muster. Beginnen Sie mit den 3 Fehlern, die Sie am häufigsten machen. Schauen Sie sich Ihre letzten 5 abgelehnten PRs oder peinlichen Bugs an. Schreiben Sie ein Grep-Muster für jeden. Diese 3 Muster werden mehr echte Probleme finden als 150 Muster, die für die Codebase einer anderen Person geschrieben wurden.

Ich begann mit except: pass ohne Spezifizierung (was mich eine stille Datenkorruption kostete), Force-Push auf Main (was mich 3 Tage an Commits kostete) und # TODO: fix later (was nie behoben wurde). Alles andere wuchs aus diesen dreien.

FAQ

Wie richte ich Jiro von Grund auf ein?

Beginnen Sie mit dem 3-Hook-Minimum, das in „Erste Schritte” beschrieben wird: quality-gate.sh (Post-Edit), git-safety-guardian.sh (Pre-Bash) und session-quality-gate.sh (Stop-Gate). Fügen Sie die Philosophie-Markdown-Dateien zu ~/.claude/skills/ hinzu, um eine probabilistische Qualitätsverbesserung über die deterministische Durchsetzung hinaus zu erhalten. Das vollständige System wuchs über 9 Monate auf 95 Hooks. Ich habe nicht alle 95 auf einmal gebaut.

Wie lange hat das 95-Hook-System gedauert?

Neun Monate inkrementelles Wachstum. Monat 1: 3 Hooks (die aus „Erste Schritte”). Monat 3: 12 Hooks für 4 Programmiersprachen. Monat 6: 40 Hooks plus die Philosophie-Skills. Monat 9: 95 Hooks, 150+ Muster, 3 Philosophiesysteme und das Beweis-Gate. Jeder Hook war eine Reaktion auf einen konkreten Fehler. Mit 95 zu beginnen wäre sinnlos, weil jeder Hook Kontext aus einem realen Vorfall kodiert. Ihre Vorfälle werden andere sein.

Verlangsamen die Hooks die Iterationsgeschwindigkeit?

Jeder Hook läuft in 50–200 ms. Pre-Edit-Injektion fügt ~200 Token hinzu (ein Satz Kontext). Post-Edit-Prüfungen sind Grep-Level-Scans, die in unter 100 ms abgeschlossen werden. Sitzungs-Gates fügen am Sitzungsende ~500 Token hinzu. In einer 4-stündigen Ralph-Schleifen-Sitzung mit 80+ Bearbeitungen ist der Overhead beim Token-Verbrauch spürbar (15–20 % mehr), aber nicht bei der Laufzeit. Die Hooks laufen schneller, als das LLM denkt.

Wie hoch ist der Wartungsaufwand?

Ungefähr 30 Minuten pro Woche. Neue Anti-Muster tauchen auf, wenn der Agent auf neuartige Codebases oder Frameworks trifft. Jedes neue Muster erfordert einen Regex, einen Test gegen Falsch-Positive und die Platzierung im richtigen Hook. Ich überprüfe die Standards-JSON-Dateien monatlich auf veraltete Muster und stelle Falsch-Positiv-Raten nach. Das System wartet sich nicht selbst, aber die Wartungskosten bleiben niedriger als die Debugging-Kosten der Probleme, die es verhindert.

Was kostet Jiro an zusätzlichen Token?

Ungefähr 15–20 % zusätzlicher Token-Verbrauch im Vergleich zu einer rohen Schleife. Pre-Edit-Injektion fügt ~200 Token pro Bearbeitung hinzu, Post-Edit-Prüfung fügt ~100 Token pro markiertem Problem hinzu, Sitzungs-Gates fügen am Sitzungsende ~500 Token hinzu.

Kann ich die Hooks ohne die Philosophie verwenden?

Ja. Die deterministischen Hooks (quality-gate.sh, no-shortcuts-detector.sh, reviewer-stop-gate.sh) funktionieren unabhängig. Entfernen Sie die Philosophie-Dateien aus ~/.claude/skills/ und behalten Sie die Hooks in ~/.claude/hooks/. Sie verlieren die probabilistische Verbesserung, behalten aber die deterministische Durchsetzung.

Zurückhaltung, Geschmack und moralisches Innehalten

Die Antwort auf meinen Tweet nannte drei Dinge: Zurückhaltung, Geschmack und moralisches Innehalten. Ich habe Zurückhaltung behandelt: Qualitäts-Gates, die verhindern, dass die Maschine schnell und schlampig ausliefert. Aber Geschmack und moralisches Innehalten sind andere Probleme.

Geschmack

Immanuel Kant unterschied zwischen zwei Arten von Urteilskraft. Bestimmende Urteilskraft wendet bekannte Regeln auf spezifische Fälle an: Dieser Code hat ein Bare-Except, markiere ihn. Reflektierende Urteilskraft entdeckt das richtige Prinzip für eine beispiellose Situation: Diese Abstraktion fühlt sich falsch an, aber ich kann keine Regel benennen, die sie verletzt.¹⁷

Deterministische Hooks sind bestimmende Urteilskraft. Sie wenden Regeln an, die ich bereits geschrieben habe, auf Code, den die Maschine produziert. Sie können 150+ bekannte Muster durchsetzen. Sie können Ihnen nicht sagen, ob die Architektur elegant ist, ob die Abstraktion dem Problem dient oder ob der Code sich richtig anfühlt. Das erfordert reflektierende Urteilskraft: die Fähigkeit, etwas Beispielloses zu betrachten und zu wissen, dass es falsch ist, bevor man artikulieren kann, warum.

Die Maschine hat keinen Geschmack. Jiro verleiht ihr keinen Geschmack. Was Jiro tut, ist den Raum der Möglichkeiten so einzuschränken, dass geschmacklose Lösungen weniger wahrscheinlich überleben. Es ist der Unterschied zwischen „dieser Agent hat gutes Urteilsvermögen” und „dieser Agent operiert innerhalb von Leitplanken, die die schlimmsten Ergebnisse verhindern.” Das Erste wäre Geschmack. Das Zweite ist, was ich tatsächlich gebaut habe.

Moralisches Innehalten

Iris Murdoch beschrieb moralische Aufmerksamkeit als „einen gerechten und liebevollen Blick, gerichtet auf eine individuelle Wirklichkeit.”¹⁸ Das Gegenteil moralischer Aufmerksamkeit ist mechanische Verarbeitung: Handeln, ohne zu sehen, was vor einem steht.

Die Stop-Hooks zwingen die Maschine zum Innehalten. Der Pride Check fragt: „Löst dies das tatsächliche Problem des Benutzers?” Das Beweis-Gate verlangt Belege für jedes Kriterium, bevor die Maschine die Fertigstellung melden darf. Strukturell ähnelt das Ergebnis moralischem Innehalten: Der Agent hält an, evaluiert, erwägt, ob seine Arbeit angemessen ist, bevor er fortfährt.

Aber es ist kein moralisches Innehalten. Die Maschine hält nicht inne, um die Arbeit klar zu sehen. Sie arbeitet eine Checkliste ab. Der Unterschied ist wichtig. Ein Handwerker hält inne, um die Schublade zu betrachten, und bemerkt, dass die Maserung in die falsche Richtung verläuft. Nicht weil „Maserungsrichtung prüfen” auf einer Liste steht. Weil ihm die Schublade am Herzen liegt. Die Maschine arbeitet die Checkliste ab und meldet die Ergebnisse. Wenn die Checkliste keine Maserungsrichtung enthält, wird die Schublade mit falscher Maserung ausgeliefert.

Deterministische Gates können die Struktur moralischen Innehaltens annähern, ohne dessen Substanz. Für viele Qualitätsprobleme reicht die Struktur aus. Für diejenigen, bei denen sie nicht reicht, brauchen Sie weiterhin einen Menschen, dem etwas daran liegt.

Die These

Eine rohe Ralph-Schleife läuft für 10,42 $/Stunde und liefert Code in Maschinengeschwindigkeit.¹ Sie liefert auch except: pass, # TODO: fix later und „Tests sollten bestehen” in Maschinengeschwindigkeit. Die Maschine hat diese Muster von uns geerbt. Es sind unsere Gewohnheiten, die ohne Erschöpfung laufen, ohne Schuldgefühle, ohne die Erkenntnis um 3 Uhr morgens, dass man es gleich beim ersten Mal richtig hätte machen sollen.

Jiro ist meine Antwort. Keine vollständige. Philosophie verschiebt Entscheidungen an den Rändern. Hooks setzen durch, was Philosophie nicht garantieren kann. Zusammen produzieren sie Arbeit, die ich bereit bin zu signieren. Nicht weil die Maschine Handwerkskunst versteht. Sondern weil ich ein System gebaut habe, das es ihr nicht erlaubt, die wichtigen Teile zu überspringen.

Die Schubladenführungen meines Vaters kümmern sich nicht um die Schublade. Sie sind federbelastete Mechanismen, die an einer Schiene verschraubt sind. Aber sie schützen die Frontblende über tausend Zyklen, weil jemand sie genau dafür konstruiert hat.

Die Maschine hat keinen Stolz. Aber sie operiert innerhalb eines Systems, das von jemandem gebaut wurde, der ihn hat.

Beginnen Sie mit den 3 Prüfungen, die Ihre häufigsten Fehler abfangen. Bauen Sie von dort aus weiter.

Referenzen