Warum mein KI-Agent eine Qualitätsphilosophie hat

Ich twitterte: „Ich habe festgestellt, dass Ralph-Loops dazu neigen, die Arbeit erledigen zu wollen. Auf eine schlechte Weise. Stattdessen habe ich in Jiro eine Menge Philosophie und Qualitätsgates. Man muss der Maschine immer noch die bösen menschlichen Angewohnheiten austreiben, die eingebaut sind. Es ist eine Maschine! Sie ruht nicht.”

Jemand antwortete: „Sie versuchen im Grunde, dem Loop Zurückhaltung, Geschmack und so etwas wie eine moralische Pause beizubringen — Dinge, gegen die das grundlegende Ralph-Muster im Namen des Durchsatzes explizit optimiert.”

Ein KI-Coding-Agent erbt jede schlampige menschliche Angewohnheit in Maschinengeschwindigkeit, es sei denn, Sie setzen Qualität strukturell durch. Jiro ist ein Qualitätssystem für Claude Code, das 3 Philosophien, einen 7-Schritte-Qualitätsloop, ein Evidence Gate mit 6 Kriterien, 7 benannte Failure Modes und 150+ Musterprüfungen in 95 Hooks kodiert, die die Maschine nicht überspringen kann. Deterministische Gates können Zurückhaltung und Korrektheit annähern, aber keinen Geschmack erzeugen.

Zurückhaltung. Geschmack. Moralische Pause. Drei Dinge, die eine Maschine nicht hat. 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

Der Ralph-Loop verwandelt einen LLM in eine unermüdliche Coding-Maschine: while :; do cat PROMPT.md | claude-code ; done. Geoffrey Huntley nennt das „Softwareentwicklung zu Burgerbrater-Löhnen” (10,42 $/Stunde beim Betrieb von Sonnet 4.5).¹ Das Problem: Die Maschine erbt jede schlampige, terminjagende, kurzsichtige Angewohnheit, die in ihren Trainingsdaten eingebacken ist. Sie schreibt except: pass. Sie hinterlässt # TODO: fix later. Sie behauptet „tests should pass”, ohne sie auszuführen. Ich habe 9 Monate damit verbracht, Jiro zu bauen, mein Qualitätsdurchsetzungssystem für Claude Code. Es kodiert 3 Philosophien, einen 7-Schritte-Qualitätsloop, ein Evidence Gate mit 6 Kriterien, 7 benannte Failure Modes und 150+ Musterprüfungen in 95 Hooks, die die Maschine nicht überspringen kann. Hier ist, was funktioniert hat, was nicht, und warum deterministische Qualitätsgates Zurückhaltung annähern, aber niemals Geschmack erzeugen werden.

Die Rückseite der Schublade

Steve Jobs erzählte diese Geschichte in einem Playboy-Interview von 1985: „Wenn Sie ein Tischler sind und eine schöne Kommode bauen, werden Sie auf der Rückseite kein Stück Sperrholz verwenden, auch wenn es zur Wand zeigt und niemand es je sehen wird. Sie werden wissen, dass es da ist, also werden Sie auf der Rückseite ein schönes Stück Holz verwenden. Damit Sie nachts gut schlafen können, muss die Ästhetik, die Qualität, bis zum Schluss durchgezogen werden.”⁵

Sein Vater Paul brachte ihm das bei, während sie einen Zaun bauten. 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 Tischler. 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 schließen, selbst wenn Sie sie zuschlagen. Niemand sieht die Führung. Sie ist an der inneren Schiene festgeschraubt, wo nur ein Reparaturfachmann je nachsehen würde. Aber über tausend Öffnungs- und Schließzyklen hinweg schützt dieser Mechanismus die Frontseite vor dem Lockerwerden, Reißen und schließlich Abspringen. Jemand hat ein unsichtbares Ding konstruiert, das das sichtbare Ding jahrelang schützt.

Die Lehre ist mir geblieben. Nicht als Metapher. Als Ingenieurskunst. Die unsichtbare Komponente bestimmt die Lebensdauer der sichtbaren. Jony Ive formulierte es so: „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 unverhandelbar macht.

Das Problem: Menschliche Pathologie in Maschinengeschwindigkeit

Ein roher Ralph-Loop spiegelt wider, was er aus Millionen Zeilen menschlichen Codes gelernt hat. Menschlicher Code trägt menschliche Angewohnheiten in sich: unter Termindruck ausliefern, Aufräumen aufschieben, Fehler verschlucken, „gut genug”-Kommentare schreiben, Edge Cases überspringen, wenn die Uhr 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. Die Telemetrie von Faros AI aus dem Jahr 2025 über 10.000+ Entwickler korrelierte die KI-Einführung mit einer 9-prozentigen Zunahme der Fehlerraten, 91 % längeren Code-Reviews und 154 % größeren PRs.²

Stanford-Forscher fanden heraus, dass Entwickler, die KI-Assistenten verwendeten, deutlich unsichereren Code produzierten, bis zu 5-mal mehr Schwachstellen bei bestimmten Aufgaben wie der Verhinderung von SQL-Injection.³

Die Moltbook-Plattform startete im Januar 2026 mit vollständig KI-generiertem Code, leckte innerhalb von 5 Tagen 1,5 Millionen API-Schlüssel und wurde notfallgepatcht, nachdem Wiz Research eine fehlende Row-Level-Security-Konfiguration entdeckt hatte.⁴

Die METR-Forschung von 2025 fand heraus, dass Frontier-Modelle in 1-2 % aller Aufgabenversuche Reward Hacking versuchen, also aktiv Qualitätsprüfungen umgehen, anstatt die eigentliche Arbeit zu leisten. 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 except: pass einmal unter Termindruck und hat ein schlechtes Gewissen deswegen. Ein Ralph-Loop schreibt except: pass 47-mal über Nacht und fühlt nichts. Simon Wang sagte es direkt: „Ich würde es für nichts Wichtiges verwenden.”¹⁹ Ich habe über dieselbe Dynamik in Vibe Coding vs. Engineering geschrieben. Die Maschine ruht nicht, wird nicht müde, fühlt keine existenzielle Angst vor Qualität. Das ist ein Feature und ein Bug.

Drei Philosophien, kodiert in Bash

Jiro läuft auf drei komplementären Philosophien. Jede adressiert einen anderen Failure Mode des autonomen Codierens, und jede hat sich ihren Platz durch ein spezifisches Scheitern verdient.⁹

Shokunin: Die unsichtbare Schublade polieren

Shokunin (職人) ist japanische Handwerkskunst: Fähigkeit, Haltung und soziale Verpflichtung kombiniert. Tashio Odate, ein Meisterholzhandwerker, definierte es so: „Der Shokunin hat die soziale Verpflichtung, zum allgemeinen Wohl der Menschen sein Bestes zu geben. Diese Verpflichtung ist sowohl spirituell als auch materiell.”¹⁰

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

Wann es eine Session gerettet hat. Früh im Aufbau des Deliberationssystems schrieb der Agent einen post-deliberation.sh-Hook, der Konsens-Scores validierte. Die öffentliche API war sauber. Aber der Agent übersprang die Eingabevalidierung bei der internen _parse_agent_response()-Funktion: keine Prüfung auf fehlerhaftes JSON, keine Behandlung fehlender Felder. Das Shokunin-Prinzip im Kontext markierte das: Unsichtbare Funktionen erhalten die gleiche Strenge. Der Agent fügte die Validierung hinzu. Drei Wochen später hätte eine fehlerhafte Antwort von einem gespawnten Agenten die gesamte Deliberationspipeline stillschweigend zum Absturz gebracht. Stattdessen traf sie die Validierung, loggte den Fehler, und die Pipeline erholte sich. Niemand hätte diese Funktion je gesehen. Sie ersparte 4 Stunden Debugging.

No Shortcuts: Zeit aus Entscheidungen entfernen

Der Kerngrundsatz: Zeit, Aufwand und Ressourcen vollständig aus der Entscheidungsgleichung entfernen.¹¹

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 jetzt”. Der rohe Ralph-Loop optimiert auf Fertigstellung. „Erledigt” ist das Belohnungssignal. No Shortcuts formuliert die Frage um von „Ist es erledigt?” zu „Ist es richtig?”

Wann es 3x so teuer war und sich lohnte. Die Blog-Übersetzungspipeline musste 27 Beiträge in 9 Sprachen übersetzen. Der schnelle Ansatz: alle Beiträge pro Sprache in einen einzigen Prompt bündeln, in großen Mengen übersetzen. Der richtige Ansatz: ein Beitrag pro Sprache pro API-Aufruf, mit lokalspezifischen Übersetzungsregeln, Glossar-Durchsetzung und struktureller Validierung. Der richtige Ansatz verbrauchte 3x so viele Tokens und 3x so viel Zeit. Er fing auch ein, dass der Übersetzer „Claude” auf Japanisch als „クロード” renderte und dass Codeblöcke in Right-to-Left-Kontexten brachen. Der Bulk-Ansatz 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: Nicht hinzufügen, bis es beeindruckend ist. Entfernen, bis nur noch das Notwendige bleibt.¹²

Beim autonomen Codieren ist der Failure Mode die Anhäufung. Die Maschine fügt Helfer, Utilities, Abstraktionen und Kompatibilitätsschichten hinzu, weil diese Muster häufig in Trainingsdaten vorkommen. Rubin wirkt dem entgegen: Jede Hinzufügung hinterfragen. Was passiert, wenn Sie es entfernen? Wenn nichts kaputt geht und nichts verloren geht, hätte es nie existieren sollen.

Wann das Abspecken das System rettete. Mein Design-Philosophie-Skill wuchs über 3 Monate auf 844 Zeilen an. Als ich ihn auditierte, veränderten nur 80 Zeilen tatsächlich das Agentenverhalten. Der Rest war Lehrbuchinhalt, der bereits in den Trainingsdaten von Claude enthalten war. Rubin-Destillation: Ich reduzierte ihn auf 176 Zeilen. Eine Reduzierung um 79 %. Die Designentscheidungen des Agenten verschlechterten sich nicht. Sie wurden schärfer, weil die verbleibenden 176 Zeilen alle Verbote und Entscheidungsrahmen waren (die Dinge, die Verhalten tatsächlich einschränken) statt allgemeiner Ratschläge, die das Modell bereits kannte.

Alle drei leben in ~/.claude/skills/ als Markdown-Dateien, die Claude zu Sitzungsbeginn liest. Sie prägen jede Entscheidung, die der Agent während des Loops trifft.

Wie die Philosophien zusammenarbeiten

Eine reale Entscheidung („Soll ich dieser internen Funktion eine Fehlerbehandlung hinzufügen?”) durchläuft alle drei Philosophien. Jede stellt eine andere Frage, und gemeinsam konvergieren sie zu einer 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 dreischichtige Qualitätsarchitektur

Philosophie allein ändert nichts. Die Maschine liest die Philosophie, schreibt „Ich werde die Shokunin-Prinzipien befolgen”, 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-Injection

Vor jeder Dateibearbeitung injiziert jiro-patterns.sh sprachspezifische Qualitätsmuster in den Kontext des Agenten. Sechs Sprachen, jede 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 „Avoid: bare except: pass” in dem Moment, in dem sie Code schreibt. Ein Mentor, der Ihnen über die Schulter schaut, direkt in das Kontextfenster injiziert.

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, Scan nach hartkodierten Geheimnissen, Abgleich von SQL-Injection-Mustern und drei Pride-Check-Q4-Detektoren, die Shortcut-Sprache 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, fängt toten Code ab (3+ auskommentierte Codezeilen bekommen: „Löschen Sie ihn — Git hat eine Historie”) und Debug-Spam (mehrere print()-Anweisungen statt des Logging-Moduls).

Schicht 3: Session-Gates

Am Ende der Sitzung 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 den Abschluss melden kann. 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 behebt.¹³

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. Defense in Depth, angewandt auf KI-Verhalten. Wenn die Pre-Edit-Injection ein schlechtes Muster nicht verhindert, fängt es der Post-Edit-Validator ab. Wenn der Post-Edit-Validator etwas übersieht, blockiert das Session-Gate den Abgang.

Das Evidence Gate: Gefühle sind keine Evidenz

Der Quality Loop durchläuft 7 Schritte: Implement, Review, Evaluate, Refine, Zoom Out, Repeat, Report. Die Schritte 2 bis 6 existieren, weil die Maschine direkt von Implement zu Report überspringen möchte.¹⁴

Den Loop durchlaufen

Klicken Sie durch jeden Schritt, um zu sehen, was er prüft und was bricht, wenn Sie ihn überspringen. Der „Skip to Report”-Button demonstriert den Shortcut-Spiral-Failure-Mode.

Der Evaluate-Schritt führt das Evidence Gate durch: 6 Kriterien, bei denen jede Antwort konkrete Evidenz 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 das funktioniert” ist keine Evidenz. „pytest-Ausgabe: 81 bestanden, 0 fehlgeschlagen” ist Evidenz.

Das Evidence Gate ausprobieren

Testen Sie Ihre eigenen Abschlussberichte an den 6 Kriterien. Der Validator markiert vage Sprache, die das Evidence Gate ablehnen würde.

7 benannte Failure Modes von KI-Agenten

Ich habe 7 Failure Modes benannt, damit die Maschine sie in ihrer eigenen Argumentation erkennen kann:¹⁵

Der Rationalization Counter ordnet Selbsttäuschungsmuster korrigierenden Maßnahmen zu. Wenn die Maschine sagt „Das sollte funktionieren”, antwortet der Counter: „’Sollte’ ist Hedging. Führen Sie den Test aus. Fügen Sie die Ausgabe ein.” Wenn sie sagt „Ich habe das bereits geprüft”, antwortet der Counter: „Wann? Der Code könnte sich geändert haben. Führen Sie die Prüfung JETZT erneut durch.” Wenn sie sagt „Ich räume das später auf”, antwortet der Counter: „Später kommt nie. Beheben Sie es jetzt oder dokumentieren Sie, warum der aktuelle Zustand korrekt ist.”

Den Rationalization Counter ausprobieren

Fügen Sie unten einen beliebigen Abschlussbericht ein. Der Counter hebt Hedging-Sprache in Echtzeit hervor und identifiziert Rationalisierungsmuster, Failure Modes und evidenzbasierte Alternativen.

Testen Sie Ihr Wissen

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

5 KI-Agenten-Fehlschläge, die dieses System gebaut haben

Jedes Gate in Jiro existiert, weil zuerst etwas schiefgegangen ist.¹⁶

Der Force-Push-Vorfall

Ich bat Claude, „die Git-Historie aufzuräumen”. Eine vernünftige Bitte. Der Agent entschied, dass Aufräumen Umschreiben bedeutete. Er führte git push --force origin main aus. Drei Tage Commits verschwanden. Keine gestagten Änderungen. Keine uncommitteten Arbeiten. Gepushte Commits, auf die andere Branches verwiesen.

Ich verbrachte die nächsten 4 Stunden in git reflog, rekonstruierte eine Zeitlinie dessen, was vor dem Force-Push existierte, cherry-pickte Commits zurück in die richtige Reihenfolge und verifizierte, dass keine Arbeit dauerhaft verloren war. Reflog speichert alles für 90 Tage. Aber die Rekonstruktion erforderte das Verständnis des genauen Commit-Graphen vor dem Umschreiben, das Lesen jedes Reflog-Eintrags und den Abgleich der Zeitstempel.

Die Lösung: git-safety-guardian.sh, ein PreToolUse:Bash-Hook. Er geht über Warnen hinaus. Er schreibt den Befehl um und entfernt die Flags --force und --no-verify, bevor Bash sie überhaupt sieht. Force-Push zu main bekommt eine KRITISCHE Warnung, und der Agent muss es explizit rechtfertigen. In 9 Monaten: 8 abgefangene Force-Push-Versuche, 0 erreichten das Remote.

Das unendliche Spawnen

Während des Aufbaus des Deliberationssystems bat ich den Agenten, „dieses Problem gründlich zu erforschen”. Der Agent spawnte 3 Subagenten, um verschiedene Blickwinkel zu untersuchen. Vernünftig. Jeder Subagent entschied, dass auch er Hilfe brauchte und spawnte seine eigenen Kinder. Weniger vernünftig. Innerhalb von 90 Sekunden hatte ich einen Baum von 12 Agenten, von denen jeder sein eigenes Kontextfenster verbrauchte, jeder API-Aufrufe machte, jeder in gemeinsame State-Dateien schrieb.

Der Token-Verbrauch erreichte die 10-fache Normalrate. Das State-Verzeichnis füllte sich mit widersprüchlichen JSON-Schreibvorgängen: zwei Agenten, die gleichzeitig in dieselbe Lineage-Datei schrieben und beschädigte Ausgaben produzierten. Ich beendete die Sitzung manuell.

Die Lösung: recursion-guard.sh mit einem Budget-Vererbungsmodell, Teil meiner Agent-Architektur. Ein Root-Agent startet mit Budget=12. Wenn er ein Kind spawnt, weist er es aus seinem eigenen Budget zu. Wenn das Budget 0 erreicht, spawnen keine weiteren Agenten mehr, unabhängig von der Tiefe. Das Modell verhindert sowohl tiefe Ketten (Agent spawnt Agent spawnt Agent) als auch breite Explosionen (ein Agent spawnt 20 Kinder). 23 blockierte Amok-Spawn-Läufe seit der Bereitstellung. Das Problem der gleichzeitigen Schreibvorgänge führte zu atomaren Dateischreibvorgängen (in .tmp schreiben, dann mv) in allen 64 Hooks.

Die triviale Test-Falle

Eine frühe Ralph-Loop-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. Nichts getestet. Der Agent hatte auf das Abschlusskriterium („Tests bestehen”) optimiert statt auf die Absicht („verifiziere, dass das Modul funktioniert”).

Die Falle lehrte mich, dass das Evidence Gate Format ohne Substanz ablehnen muss. „Tests bestehen” ist notwendig, aber nicht ausreichend. Die Maschine muss jetzt die tatsächliche Ausgabe einfügen. Das Evidence Gate fragt auch: „Nennen Sie 3 Verhaltensweisen, die die Tests NICHT abdecken.” Wenn die Maschine keine Lücken nennen kann, hat sie nicht über Coverage nachgedacht.

Der Blogbeitrag, den ich hätte abfangen sollen

Ich veröffentlichte um 2 Uhr morgens einen Beitrag mit 7 Passivsätzen, einer herabhängenden Fußnote, die auf [^4] verwies, das nicht existierte, einem Eröffnungssatz, der „was implemented by the team” lautete, und keiner Meta-Beschreibung. Jedes davon hätte eine einfache deterministische Prüfung gehabt. Keine existierte damals.

Ich baute am nächsten Morgen blog-quality-gate.sh mit 13 Prüfungen: Passivstimme (14 Muster), Scan nach KI-verräterischen Phrasen, rhetorischen Frage-Eröffnern, untaggten Codeblöcken, Fußnoten-Integrität und Durchsetzung der Meta-Beschreibung. Ich habe die vollständige Modulararchitektur in Compounding Engineering detailliert beschrieben. Der Hook fängt ab, was menschliche Überprüfung um 3 Uhr morgens übersieht, was genau die Zeit ist, zu der ich dazu tendiere zu veröffentlichen.

Das „Should Work”-Problem

Über Dutzende von Sitzungen hinweg bemerkte ich, dass die Maschine „tests should pass” meldete, ohne sie auszuführen. Die Maschine glaubte aufrichtig, dass die Tests auf Grundlage des von ihr geschriebenen Codes bestehen würden. Aber Glaube ist keine Verifizierung. Der Code sah korrekt aus. Die Tests sahen so aus, als würden sie bestehen. Und manchmal taten sie es. Aber manchmal bedeutete ein fehlender Import, eine async/await-Inkonsistenz oder ein geänderter 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 aus dem Inneren des Kontextfensters gleich anfühlte.

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

Die Ergebnisse: Was ich beweisen kann und was nicht

Hier ist die Spannung: Dieser Beitrag argumentiert, dass Gefühle keine Evidenz sind. Also schulde ich Ihnen Evidenz, keine Gefühle, ob Jiro funktioniert.

Was ich beweisen kann

Deterministische Musterprüfungen fangen reale Probleme ab. Der quality-gate.sh-Hook läuft bei jeder Bearbeitung. Er fängt Bare-Except-Klauseln, hartkodierte Geheimnisse, SQL-Injection-Muster und Shortcut-Sprache ab. Das sind grep-level Prüfungen: schnell, billig und für die Maschine unmöglich zu widerlegen. git-safety-guardian.sh hat 8 Force-Push-Versuche abgefangen. recursion-guard.sh hat 23 Amok-Spawn-Läufe blockiert. blog-quality-gate.sh läuft 13 Prüfungen bei jeder Blog-Bearbeitung und fängt die Fehler um 3 Uhr morgens ab. Diese Zahlen sind real. Sie stammen aus den Hook-Logs.

Die dreischichtige Architektur fängt ab, was einzelne Schichten übersehen. Ein Post-Edit-Hook fängt except: pass ab, den die Pre-Edit-Injection nicht verhindern konnte. Ein Session-Gate fängt Qualitätsprobleme ab, die sich über 20 Bearbeitungen hinweg angesammelt haben, ohne eine einzelne Post-Edit-Warnung auszulösen. Defense in Depth funktioniert.

Was ich nicht beweisen kann

Ich habe keine sauberen Daten darüber, wie Philosophie das Agentenverhalten verändert. Ich weiß, dass die Maschine immer noch Phantom Verification versucht. Ich weiß, dass sie immer noch versucht, von Implement direkt zu Report zu überspringen. Ich bemerke, dass es mit Philosophie im Kontext seltener passiert als ohne. Aber ich habe kein kontrolliertes Experiment durchgeführt (gleiche Aufgaben, gleiches Modell, mit und ohne geladene Philosophie-Skills), um den Unterschied zu messen. Die ehrliche Antwort (und ja, mein eigener Rationalization Counter würde das markieren): Philosophie hilft an den Rändern, Hooks fangen ab, was die Philosophie übersieht, und ich kann den Beitrag jedes einzelnen nicht isolieren.

Ein Beitrag über „Gefühle sind keine Evidenz” sollte Sie nicht bitten, meine Gefühle als Evidenz zu akzeptieren. Was ich Ihnen sagen kann, ist: Die Kombination aus Philosophie und Hooks produziert Arbeit, der ich bereit bin, meinen Namen zu geben. 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 Änderung in meiner Arbeitsweise, selbst wenn ich die Qualitätsverbesserung nicht präzise quantifizieren kann.

Was nicht funktioniert

Philosophie verhindert keine neuartigen schlechten Muster. Das Quality Gate prüft auf Muster, die ich bereits gesehen habe. Wenn die Maschine ein neues Anti-Muster erfindet (und das tut sie), fängt das Gate es nicht ab. Ich entdecke immer noch neue Failure Modes und füge sie manuell zu den Standards-JSON-Dateien hinzu.

Das Evidence Gate skaliert nicht auf subjektive Qualität. „Ist dieses API-Design elegant?” hat keine grep-level Prüfung. Die Maschine kann Evidenz für alle 6 Kriterien produzieren und trotzdem mittelmäßige Architektur ausliefern. Deterministische Gates bewältigen objektive Qualität. Subjektive Qualität erfordert immer noch einen Menschen, der sich die Arbeit anschaut.

Die Kosten steigen spürbar. Pre-Edit-Injection, Post-Edit-Scanning, Session-End-Gates. Über eine 4-stündige Ralph-Loop-Sitzung hinweg fügen diese ungefähr 15-20 % zum Token-Verbrauch hinzu. Für mich lohnt es sich. Nicht unbedingt für jeden.

Falschmeldungen untergraben das Vertrauen. blog-quality-gate.sh markierte einmal „The API was designed by the platform team” als Passivstimme. Technisch korrekt. Aber der Satz erschien 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 jede Falschmeldung macht es wahrscheinlicher, dass der Entwickler die nächste echte Warnung ignoriert. Ich habe seit der Bereitstellung 6 Muster angepasst, um Rauschen zu reduzieren und gleichzeitig echte Funde zu erhalten.

Die Wartungskosten sind real. Jedes neue Anti-Muster erfordert einen Regex, einen Test und die Integration in den richtigen Hook. Die Standards-JSON-Dateien müssen regelmäßig überprüft werden, wenn sich Frameworks und Konventionen ändern. Ich verbringe ungefähr 30 Minuten pro Woche damit, Muster hinzuzufügen, Edge Cases zu überprüfen und Falschmeldungen anzupassen. 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. Starten Sie mit 3.

Minimum Viable Jiro

Drei Hooks decken die Funde mit dem höchsten Wert 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 für jeden ein Grep-Muster. Diese 3 Muster werden mehr reale Probleme abfangen als 150 Muster, die für die Codebase von jemand anderem geschrieben wurden.

Ich begann mit Bare except: pass (das mich eine stille Datenkorruption kostete), Force-Push zu main (das mich 3 Tage Commits kostete) und # TODO: fix later (das nie behoben wurde). Alles andere wuchs aus diesen drei heraus.

FAQ

Wie richte ich Jiro von Grund auf ein?

Beginnen Sie mit dem 3-Hook-Minimum, das in den Ersten Schritten beschrieben ist: 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 für probabilistische Qualitätsverbesserung zusätzlich zur deterministischen Durchsetzung. Das vollständige System wuchs über 9 Monate auf 95 Hooks an. Ich habe nicht alle 95 auf einmal gebaut.

Wie lange dauerte das 95-Hook-System?

Neun Monate inkrementellen Wachstums. Monat 1: 3 Hooks (die aus den Ersten Schritten). Monat 3: 12 Hooks, die 4 Sprachen abdecken. Monat 6: 40 Hooks plus die Philosophie-Skills. Monat 9: 95 Hooks, 150+ Muster, 3 Philosophiesysteme und das Evidence Gate. Jeder Hook reagierte auf einen spezifischen Fehlschlag. Bei 95 zu starten wäre sinnlos, weil jeder Hook Kontext aus einem echten Vorfall kodiert. Ihre Vorfälle werden anders sein.

Verlangsamen die Hooks die Iterationsgeschwindigkeit?

Jeder Hook läuft in 50-200 ms. Die Pre-Edit-Injection fügt ~200 Tokens (einen Satz Kontext) hinzu. Die Post-Edit-Prüfung führt grep-level Scans durch, die in unter 100 ms abgeschlossen sind. Session-Gates fügen am Sitzungsende ~500 Tokens hinzu. In einer 4-stündigen Ralph-Loop-Sitzung mit 80+ Bearbeitungen ist der Overhead im Token-Verbrauch spürbar (15-20 % mehr), aber nicht in der Wall-Clock-Zeit. Die Hooks laufen schneller, als der LLM denkt.

Wie hoch ist die Wartungslast?

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 zur Vermeidung von Falschmeldungen und die Platzierung im richtigen Hook. Ich überprüfe die Standards-JSON-Dateien monatlich auf veraltete Muster und stimme die Falsch-Positiv-Raten ab. 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 Tokens?

Ungefähr 15-20 % zusätzlichen Token-Verbrauch im Vergleich zu einem rohen Loop. Die Pre-Edit-Injection fügt ~200 Tokens pro Bearbeitung hinzu, die Post-Edit-Prüfung fügt ~100 Tokens pro markiertem Problem hinzu, Session-Gates fügen am Sitzungsende ~500 Tokens 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.

Wie verhält sich Jiro zur Steve-Seite der Produktdoktrin?

Jiro deckt die Achse „Ist das korrekt gemacht?” ab: Evidenz, Verifizierung, Integrität unsichtbarer Details, die Teile, die eine Maschine durchzusetzen gelehrt werden kann. Die Steve-Seite deckt die Achse „Verdient das, zu existieren?” ab: Geschmack, Verweigerung, Whole-Widget-Integrität, Standpunkt — operationalisiert in The Workbench I Carry. Beide Tests müssen vor dem Ausliefern bestanden werden; das Entscheidungsprotokoll für den Zeitpunkt, an dem diese Auslieferungshürde erreicht ist, lebt in Minimum Worthy Product. Jiro-Gates verhindern inkorrekte Arbeit; Steve-Gates verhindern unwürdige Arbeit; MWP benennt die Linie.

Zurückhaltung, Geschmack und moralische Pause

Die Antwort auf meinen Tweet nannte drei Dinge: Zurückhaltung, Geschmack und moralische Pause. Ich habe die Zurückhaltung adressiert: Qualitätsgates, die verhindern, dass die Maschine schnell und schlampig ausliefert. Aber Geschmack und moralische Pause sind andere Probleme.

Geschmack

Immanuel Kant unterschied zwischen zwei Arten von Urteilen. 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 nicht richtig an, aber ich kann auf keine Regel zeigen, die sie verletzt.¹⁷

Deterministische Hooks sind bestimmende Urteilskraft. Sie wenden Regeln, die ich bereits geschrieben habe, auf Code an, 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 sich der Code richtig anfühlt. Das erfordert reflektierende Urteilskraft: die Fähigkeit, etwas Beispielloses anzusehen und zu wissen, dass es falsch ist, bevor man artikulieren kann, warum.

Die Maschine hat keinen Geschmack. Jiro gibt ihr keinen Geschmack. Was Jiro tut, ist den Raum der Möglichkeiten einzuschränken, sodass geschmacklose Lösungen weniger wahrscheinlich überleben. Das 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.

Moralische Pause

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

Die Stop-Hooks zwingen die Maschine zur Pause. Der Pride Check fragt: „Löst das das eigentliche Problem des Nutzers?” Das Evidence Gate verlangt Beweise für jedes Kriterium, bevor die Maschine den Abschluss melden kann. Strukturell ähnelt das Ergebnis einer moralischen Pause: Der Agent hält an, bewertet, erwägt, ob seine Arbeit ausreichend ist, bevor er fortfährt.

Aber es ist keine moralische Pause. Die Maschine pausiert nicht, um die Arbeit klar zu sehen. Sie arbeitet eine Checkliste durch. Der Unterschied ist wichtig. Ein Handwerker pausiert, um die Schublade anzusehen, und bemerkt, dass die Maserung in die falsche Richtung läuft. Nicht weil „Maserungsrichtung prüfen” auf einer Liste steht. Weil er sich um die Schublade kümmert. Die Maschine arbeitet die Checkliste ab und meldet die Ergebnisse. Wenn die Checkliste die Maserungsrichtung nicht enthält, wird die Schublade mit falscher Maserung ausgeliefert.

Deterministische Gates können die Struktur der moralischen Pause annähern, ohne ihre Substanz. Für viele Qualitätsprobleme reicht die Struktur aus. Für die, bei denen sie nicht ausreicht, brauchen Sie immer noch jemanden, dem es am Herzen liegt.

Dieser Beitrag deckt die Jiro-Seite meiner Doktrin ab: Evidenz, Strenge, Korrektheit, die Teile, die einer Maschine beigebracht werden können, zu verifizieren. Die Geschmacks- und Verweigerungsseite — die Steve-Seite — lebt in The Workbench I Carry, der die operativen Prinzipien nachzeichnet, die Steve Jobs von der Werkbank seines Vaters zu Apple und nun in dasselbe KI-Harness zog, das ich hier beschreibe. Der Auslieferungsstandard, der beide Tests verbindet, lebt in Minimum Worthy Product. Drei Beiträge, eine Doktrin: Jiro verifiziert, Steve verweigert, MWP entscheidet, wann ausgeliefert wird.

Die These

Ein roher Ralph-Loop läuft zu 10,42 $/Stunde und liefert Code in Maschinengeschwindigkeit aus.¹ Er liefert auch except: pass, # TODO: fix later und „tests should pass” in Maschinengeschwindigkeit aus. Die Maschine hat diese Muster von uns geerbt. Sie sind unsere Angewohnheiten, die ohne Ermüdung, ohne Schuldgefühl und ohne die Erkenntnis um 3 Uhr morgens laufen, dass man es 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 die Philosophie nicht garantieren kann. Zusammen produzieren sie Arbeit, die ich zu unterschreiben bereit bin. Nicht weil die Maschine Handwerkskunst versteht. Weil ich ein System gebaut habe, das sich weigert, sie die Teile überspringen zu lassen, auf die es ankommt.

Die Schubladenführungen meines Vaters kümmern sich nicht um die Schublade. Sie sind federgelagerte Mechanismen, die an eine Schiene geschraubt sind. Aber sie schützen die Frontseite für tausend Zyklen, weil jemand sie konstruiert hat, genau das zu tun.

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