Y Combinator CEO teilt seinen Claude Code-Prompt – aber löst das falsche Problem
Ich hatte das ausgefeilteste CLAUDE.md laufen, das ich je gesehen hatte — eine strukturierte Review-Pipeline, die Claude durch Architektur-, Code-Qualitäts-, Test- und Performance-Checks zwingt, bevor es auch nur eine Zeile anfasst. Auf dem Papier war es genial. In der Praxis hatte ich mir einen Teilzeitjob als QA-Engineer für einen Roboter geschaffen.
Also habe ich es rausgerissen.
TL;DR: Es gibt 3 Ebenen, um Claude Code zu kontrollieren: Review (Fehler nachträglich abfangen), Enforcement (Fehler währenddessen blockieren) und Intent (Fehler von vornherein verhindern). Die meisten Entwickler — einschließlich YCs CEO — hängen auf Ebene 1 fest. Die echten Gewinne liegen auf Ebene 3. Vollständige Prompt Contracts Aufschlüsselung hier.
Der Prompt, der meine Woche ruinierte
Diese Review-Pipeline? War nicht von mir. Sie stammte von Garry Tan — ja, dem CEO von Y Combinator. Er teilte seinen Claude Code Prompt vor ein paar Wochen auf X und es ging viral. 3.000 Likes. Dev Twitter drehte durch. Und ich verstehe warum — der Mann leitet Y Combinator und schreibt immer noch sein eigenes CLAUDE.md. Das allein stellt ihn über 90% der Tech-CEOs, die "AI nutzen" bedeutet, dass sie einem Assistenten diktieren, der dann in ChatGPT tippt.
Sein Setup zwingt Claude in den Plan Mode mit einer strukturierten Review-Pipeline: erst Architektur, dann Code-Qualität, drittens Tests, viertens Performance. Jeder Abschnitt bringt bis zu 4 Probleme an die Oberfläche. Jedes Problem bekommt 2–3 Optionen mit Abwägungen. Claude nummeriert alles durch, versieht die Optionen mit Buchstaben und wartet auf deine explizite Freigabe, bevor es eine einzige Zeile anfasst.
Es ist gründlich. Es ist diszipliniert. Es ist im Grunde die PR-Review-Checkliste eines Senior Engineers, automatisiert.
Ich ließ es auf einem Convex-Projekt laufen, das ich refaktorierte — eine Scheduling-Engine mit Clerk Auth und Supabase für die Teile, die Convex nicht abdeckt. Und ehrlich? Das Architektur-Review fand ein Kopplungsproblem zwischen meiner Auth-Middleware und meinen API-Routen, das ich eine Woche lang zu ignorieren versucht hatte. Der Performance-Durchgang fand zwei N+1-Queries, von denen ich wirklich nichts wusste. Gute Sache.
Also warum habe ich es rausgerissen?
Weil mir nach 48 Stunden klar wurde, dass ich ein Vollzeit-Reviewer von Claude geworden war, das meinen Code reviewt. Vier Abschnitte. Bis zu 4 Probleme jeweils. 2–3 Optionen pro Problem. Jede erforderte mein explizites "ja, Option B, weiter machen." Bei einem mittleren Feature sind das 30–45 Minuten Hin und Her, bevor sich etwas ändert. Es ist, als würde man einen Handwerker anheuern und dann den ganzen Tag damit verbringen, ihm durch ein Fenster zuzuschauen und bei jedem Nagel zu nicken.
Garry Tan baute ein Code-Review-System für seine AI. Das bedeutet, er nutzt AI, um mehr Review-Arbeit für sich selbst zu generieren 🙃
Das Review-Hamsterrad ist verführerisch, weil es sich produktiv anfühlt. Du liest, bewertest, triffst Entscheidungen. Aber du machst das alles nachgelagert — nachdem Claude bereits eine Richtung gewählt hat. Du korrigierst den Kurs eines Autos, das bereits fährt.
Und der Knackpunkt? Claude erinnert sich sowieso nicht an deine Korrekturen in der nächsten Session.
Drei Ebenen, eine Hierarchie
Nachdem ich Garrys Prompt entfernt hatte, ging ich nicht zurück zu Vibes. Ich lasse Claude Code seit Monaten auf produktiver SaaS laufen und habe jeden Fehlermodus gesehen — das stille .env-Löschen, den nächtlichen Supabase-Schema-Swap, den Klassiker "Ich habe deinen Code optimiert, indem ich den Teil entfernt habe, der funktioniert hat." Worauf ich gelandet bin, ist eine Hierarchie.
Ebene 1: Review (Garry Tans Ansatz) Claude coden lassen, dann den Output prüfen. Strukturiertes Review, Plan Mode, "frag mich, bevor du atmest." Fängt Fehler nachdem sie in deiner Codebase existieren.
Ebene 2: Enforcement (Hooks) Shell-Skripte, die automatisch feuern, wenn Claude etwas macht. Formatierung beim Speichern, gefährliche Befehle blockieren, Typechecks ausführen. Fängt mechanische Fehler während der Ausführung ab. Keine menschliche Aufmerksamkeit erforderlich.
Ebene 3: Intent (Prompt Contracts) Du formst, was Claude über dein Projekt versteht, bevor es etwas schreibt. Architektur-Entscheidungen, Namenskonventionen, das WARUM hinter deinem Stack. Verhindert, dass Fehler überhaupt konzipiert werden.
Die meisten Entwickler leben auf Ebene 1.
Einige Power-User schrauben Ebene 2 dazu.
Fast niemand baut Ebene 3 richtig auf — was verrückt ist, denn da liegen die sich verstärkenden Erträge.
Ebene 2: Die, die sich über Nacht amortisiert
Ich weiß — ich habe dir gerade gesagt, dass Ebene 3 das Endziel ist. Aber Ebene 2 ist da, wo die schnellsten Gewinne liegen, weil es pure Automatisierung ist. Einmal einrichten, nie wieder daran denken. Wie ein Rauchmelder, nur dass er statt Feuer erkennt, wenn Claude versucht, dein Projekt-Root zu rm -rfen.
Das Konzept: dein CLAUDE.md ist der Style Guide. Hooks sind der Linter. Einer schlägt vor, der andere setzt durch.
Mein tatsächliches .claude/settings.json Setup (Auszug):
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": ".claude/hooks/bash-firewall.sh"
}
]
},
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": ".claude/hooks/protect-sensitive-files.sh"
}
]
}
],
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "osascript -e 'display notification \"Claude needs your attention\" with title \"Claude Code\"'"
}
]
}
]
}
}
Und die Bash-Firewall, die mir etwa einmal pro Woche das Leben rettet:
#!/usr/bin/env bash
set -euo pipefail
cmd=$(jq -r '.tool_input.command // ""')
deny_patterns=(
'rm\s+-rf\s+/'
'git\s+reset\s+--hard'
'git\s+push\s+--force'
'DROP\s+TABLE'
'DELETE\s+FROM'
)
for pat in "${deny_patterns[@]}"; do
if echo "$cmd" | grep -Eiq "$pat"; then
echo "Blocked: matches denied pattern '$pat'." 1>&2
exit 2
fi
done
exit 0
Der Dateischutz-Hook ist der, den ich hinzugefügt habe, nachdem Claude entschied, dass meine .env.local "ungenutzt" war und sie aufräumen wollte. Einmal. Das reichte. Du kennst das Gefühl, wenn du deine Prod-Credentials in Echtzeit verschwinden siehst? Ja. Jetzt kann Claude physisch nicht .env*, package-lock.json oder irgendetwas in .git/ anfassen.
#!/usr/bin/env bash
set -euo pipefail
file=$(jq -r '.tool_input.file_path // ""')
deny_globs=(".env*" "package-lock.json" ".git/*")
for g in "${deny_globs[@]}"; do
if printf '%s\n' "$file" | grep -Eiq "^${g//\*/.*}$"; then
echo "Edits to '$file' are blocked." 1>&2
exit 2
fi
done
exit 0
Der Stop-Hook mit macOS-Benachrichtigung klingt dämlich, bis du 3 Claude-Sessions parallel laufend hast und eine davon seit wer weiß wie lange untätig rumhängt, während du tief in einem anderen Terminal steckst. Diese tote Zeit summiert sich schnell, wenn du zwischen Branches jonglierst.
Der PostToolUse Prettier-Hook hat die meisten Formatierungs-Nörgeleien in meinen PRs getötet.
Nicht weil Claude hässlichen Code schreibt — tut es normalerweise nicht — aber "normalerweise" ist kein Wort, das du irgendwo in der Nähe deiner Formatierungsstandards haben willst.
Nichts davon ist glamourös. Niemand schreibt virale Tweets über "matcher": "Edit|Write" Configs. Aber jeder Hook, den du hinzufügst, ist eine Sache weniger zum Merken, ein Fehler weniger zum manuellen Abfangen, ein "oh Gott, was hat es gerade gemacht"-Moment weniger. Sie verstärken sich still, während du schläfst. Wie Zinseszins, nur nützlich.
Ebene 3: Wo ich tatsächlich mit Garry Tan nicht übereinstimme
Das ist die Ebene, die meinen Claude Code Output von "beeindruckend, aber braucht Babysitting" zu "ich scanne den Diff 5 Minuten und shippe" verwandelt hat.
Ich schrieb vor ein paar Wochen eine vollständige Aufschlüsselung von Prompt Contracts — dieser Artikel deckt die Theorie und das ursprüngliche Framework im Detail ab. Worüber ich hier sprechen möchte, ist die spezifische Lücke in Garrys Ansatz, die Prompt Contracts füllen.
Garrys Prompt sagt Claude: "Reviewe diesen Plan. Markiere DRY-Verletzungen. Präsentiere Optionen. Frage vor dem Fortfahren."
Das ist Ebene-1-Denken mit Ebene-1-Raffinesse angewandt. Es ist die beste Version von "prüfe deine Arbeit, nachdem du fertig bist." Aber es adressiert nicht, WARUM Claude von vornherein die falschen Entscheidungen trifft.
Ein Convex-Beispiel von letzter Woche.
Ich habe ein Projekt, wo Mutations einer strikten Namenskonvention folgen: [domain].[action].[target]. Also billing.create.invoice, auth.verify.session, scheduling.update.slot. Das Frontend-Team sucht nach diesen Mustern in ihrem API-Layer. Brich das Muster, brich ihren Workflow.
Mit Garrys Prompt: Claude schreibt eine Mutation namens createNewInvoice. Das Architektur-Review fängt es als "Code-Organisation-Problem" ab. Ich wähle Option B ("umbenennen, um Konvention zu folgen"), Claude benennt es um. 10 Minuten für etwas ausgegeben, das nie hätte passieren sollen.
Mit einem Prompt Contract: Claude sieht in meinem CLAUDE.md — "Convex Mutations folgen dem [domain].[action].[target] Format. Das Frontend sucht nach billing.*, um ihren API-Client automatisch zu generieren. Dieses Muster zu brechen bricht die Build-Pipeline."
Claude schreibt billing.create.invoice beim ersten Mal.
Null Review nötig.
Ein Ansatz: du fängst Fehler ab und reparierst sie.
Anderer Ansatz: die Fehler passieren nicht, weil Claude die Einschränkung versteht. Der Unterschied verstärkt sich über jedes Feature, jeden Tag, jede Session.
Und bevor jemand die "gib Claude einfach Kontext und Respekt statt Einschränkungen 🤓" Linie bringt — ja, das WARUM hinter jeder Entscheidung IST der Kontext. Zu sagen "wir nutzen Clerk, weil wir webhook-basierte Session-Synchronisation über 3 Services brauchen" IST Claude Verständnis zu geben. Prompt Contracts sind keine Drohungen. Sie sind Architektur-Dokumentation, die zufällig in einer Datei lebt, die die AI beim Start liest. Aber ich schweife ab.
Die Lücke zwischen "AI-Output sorgfältig reviewen" und "AI-Intent formen, sodass weniger zu reviewen ist" — da liegt das 10x.
Wie das in der Praxis aussieht
Mein tatsächlicher Workflow bei einem neuen Feature, gerade jetzt, heute:
- CLAUDE.md hat meine Stack-Entscheidungen mit der Begründung, Namenskonventionen, Dateistruktur-Regeln und einen "Dinge, die du versucht sein wirst zu tun, aber nicht solltest" Abschnitt (Ebene 3)
- Hooks handhaben Formatierung, Type Checking, destruktive Befehls-Blockierung und Benachrichtigungen (Ebene 2)
- Ich scanne den Diff für ~5 Minuten. Gelegentlich überrascht Claude mich immer noch. Wenn es das tut, füge ich eine Zeile zu CLAUDE.md hinzu, damit es nie wieder passiert (füttert Ebene 3)
- Plan Mode / strukturiertes Review: Ich nutze es vielleicht einmal pro Woche. Große architektonische Entscheidungen, komplexe Refactorings. Nicht für jedes Feature. (Ebene 1, sparsam)
Mit Garrys Prompt war Schritt 4 der gesamte Workflow. Jedes Feature. Jedes Mal. Das ist eine 30–45 Minuten Steuer auf jeden Ship-Zyklus, vs. meine aktuellen ~5 Minuten.
Ich habe keine sauberen Vorher/Nachher-Metriken — ich habe Revert-Raten nicht getrackt, als ich anfing, weil wer macht das schon. Was ich dir sagen kann, ist, dass sich das Gefühl des Workflows komplett geändert hat. Vorher: jedes git log hatte 2-3 "revert: undo Claude's helpful suggestion" Commits pro Tag. Jetzt: vielleicht einen pro Woche, und es liegt normalerweise daran, dass mein Prompt Contract eine Lücke hat, die ich noch nicht gepatcht habe. Jeder Revert lehrt mich, wo ich Ebene 3 straffen muss, und der Gesamttrend geht nach unten.
Der Teil, den niemand hören will
Garry Tans Prompt ist großartig. Es ist legitimerweise das beste strukturierte Review-Setup, das ich öffentlich geteilt gesehen habe. Wenn du gerade nichts machst — kein CLAUDE.md, keine Hooks, nur "Vibe Coding" und beten — geh und nutze seinen Prompt. Ernsthaft. Es ist ein massives Upgrade über nichts.
Aber es ist für eine Welt entworfen, in der du deiner AI nicht genug vertraust, um sie unbeaufsichtigt arbeiten zu lassen. Und hier ist die Ironie: der Grund, warum du ihr nicht vertrauen kannst, ist, dass du ihr nicht den Kontext gegeben hast, den sie braucht, um vertrauenswürdig zu sein. Die Lösung ist nicht mehr Review. Es ist besserer Input.
Der Prompt ist nicht der Engpass. Deine Absicht ist es.
Das vollständige Prompt Contracts Framework ist hier wenn du den Deep Dive willst. Nächste Woche veröffentliche ich mein tatsächliches komplettes CLAUDE.md — das, was ich bei jedem Projekt nutze, mit jedem Abschnitt erklärt. Folge, wenn du es nicht verpassen willst.
Und wenn du Garrys Prompt nutzt und gut shippst: mach weiter. Ehrlich. Aber wenn sich das Review-Hamsterrad wie ein Teilzeitjob anfühlt, weißt du, wo das Upgrade ist. 🦞
Wie verhindert man, dass KI-Assistenten mehr Zeit mit Code-Reviews verbringen als mit tatsächlichem Coding? In dieser Woche teile ich Einblicke aus der Praxis.