Le PDG de Y Combinator a partagé son prompt Claude pour coder. Il résout le mauvais problème.
Je faisais tourner le CLAUDE.md le plus sophistiqué que j'aie jamais vu — un pipeline de révision structuré qui force Claude à passer par l'architecture, la qualité du code, les tests et les vérifications de performance avant de toucher quoi que ce soit. Sur le papier, c'était brillant. En pratique, je m'étais donné un boulot à temps partiel d'ingénieur QA pour un robot.
Alors je l'ai viré.
TL;DR : Il y a 3 niveaux pour contrôler Claude Code : la révision (attraper les erreurs après), l'application (bloquer les erreurs pendant), et l'intention (prévenir les erreurs avant). La plupart des devs — y compris le CEO de YC — sont bloqués au niveau 1. Les vrais gains se trouvent au niveau 3. Explication complète des Prompt Contracts ici.
Le Prompt Qui M'a Bouffé Ma Semaine
Ce pipeline de révision ? Il n'était pas de moi. Il venait de Garry Tan — oui, le CEO de Y Combinator. Il a partagé son prompt Claude Code sur X il y a quelques semaines et ça a fait le buzz. 3 000 likes. Dev Twitter a perdu la tête. Et je comprends pourquoi — le mec dirige Y Combinator et écrit encore son propre CLAUDE.md. Ça seul le place devant 90% des CEO tech qui "utilisent l'IA", ce qui veut dire qu'ils dictent à un assistant qui tape ensuite dans ChatGPT.
Son setup force Claude en Plan Mode avec un pipeline de révision structuré : architecture d'abord, qualité du code ensuite, tests en troisième, performance en quatrième. Chaque section remonte jusqu'à 4 problèmes. Chaque problème a 2-3 options avec des compromis. Claude numérote tout, met des lettres aux options, et attend ton feu vert explicite avant de toucher une seule ligne.
C'est minutieux. C'est discipliné. C'est basiquement la checklist de révision PR d'un senior engineer, automatisée.
Je l'ai fait tourner sur un projet Convex que je refactorisais — un moteur de planification avec auth Clerk et Supabase pour les parties que Convex ne couvre pas. Et franchement ? La révision d'architecture a attrapé un problème de couplage entre mon middleware d'auth et mes routes API que je faisais semblant d'ignorer depuis une semaine. Le passage performance a trouvé deux requêtes N+1 dont j'ignorais vraiment l'existence. Du bon boulot.
Alors pourquoi je l'ai viré ?
Parce qu'après 48 heures j'ai réalisé que j'étais devenu un réviseur à temps plein de Claude révisant mon code. Quatre sections. Jusqu'à 4 problèmes chacune. 2-3 options par problème. Chacune nécessitant mon "oui, option B, continue" explicite. Sur une feature moyenne, ça fait 30-45 minutes d'aller-retour avant que quoi que ce soit change. C'est comme embaucher un entrepreneur puis passer toute ta journée à le regarder par la fenêtre en hochant la tête à chaque clou.
Garry Tan a construit un système de révision de code pour son IA. Ce qui veut dire qu'il utilise l'IA pour se générer plus de travail de révision 🙃
Le tapis roulant de révision est séduisant parce qu'il donne l'impression d'être productif. Tu lis, tu évalues, tu prends des décisions. Mais tu fais tout ça en aval — après que Claude ait déjà choisi une direction. Tu corriges la trajectoire d'une voiture qui roule déjà.
Et le pompon ? Claude ne se souvient pas de tes corrections à la session suivante de toute façon.
Trois Niveaux, Une Hiérarchie
Après avoir largué le prompt de Garry, je ne suis pas retourné aux vibes. Je fais tourner Claude Code sur du SaaS en prod depuis des mois et j'ai vu tous les modes de défaillance — la suppression silencieuse du .env, le swap de schéma Supabase à minuit, le classique "j'ai optimisé ton code en supprimant la partie qui marchait." Ce sur quoi j'ai atterri, c'est une hiérarchie.
Niveau 1 : Révision (approche de Garry Tan) Laisser Claude coder, puis vérifier la sortie. Révision structurée, Plan Mode, "demande-moi avant de respirer." Attrape les erreurs après qu'elles existent dans ta codebase.
Niveau 2 : Application (Hooks) Scripts shell qui se déclenchent automatiquement quand Claude fait quelque chose. Formatage à la sauvegarde, blocage des commandes dangereuses, vérifications de types. Attrape les erreurs mécaniques pendant l'exécution. Aucune attention humaine requise.
Niveau 3 : Intention (Prompt Contracts) Tu façonnes ce que Claude comprend de ton projet avant qu'il écrive quoi que ce soit. Décisions d'architecture, conventions de nommage, le POURQUOI derrière ta stack. Empêche les erreurs d'être conçues.
La plupart des devs vivent au Niveau 1.
Quelques power users ajoutent le Niveau 2.
Presque personne ne construit le Niveau 3 correctement — ce qui est dingue, parce que c'est là que vivent les retours composés.
Niveau 2 : Celui Qui Se Rembourse Du Jour Au Lendemain
Je sais — je viens de te dire que le Niveau 3 est l'objectif final. Mais le Niveau 2 est là où vivent les victoires les plus rapides, parce que c'est de l'automatisation pure. Tu le configures une fois, tu n'y penses plus jamais. Comme un détecteur de fumée, sauf qu'au lieu du feu il détecte Claude qui essaie de rm -rf la racine de ton projet.
Le concept : ton CLAUDE.md est le guide de style. Les hooks sont le linter. L'un suggère, l'autre applique.
Mon setup .claude/settings.json actuel (partiel) :
{
"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\"'"
}
]
}
]
}
}
Et le firewall bash qui me sauve la vie environ une fois par semaine :
#!/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
Le hook de protection de fichiers est celui que j'ai ajouté après que Claude ait décidé que mon .env.local était "inutilisé" et ait essayé de le nettoyer. Une fois. Ça a suffi. Tu connais cette sensation quand tu regardes tes credentials de prod disparaître en temps réel ? Ouais. Maintenant Claude ne peut physiquement pas toucher .env*, package-lock.json, ou quoi que ce soit dans .git/.
#!/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
Le hook Stop avec notification macOS semble con jusqu'à ce que tu fasses tourner 3 sessions Claude en parallèle et qu'une d'elles reste inactive depuis dieu sait combien de temps pendant que tu es à fond dans un autre terminal. Ce temps mort s'accumule vite quand tu jongle avec les branches.
Le hook PostToolUse Prettier a tué la plupart des chipotages de formatage sur mes PR.
Pas parce que Claude écrit du code moche — généralement non — mais "généralement" n'est pas un mot que tu veux quelque part près de tes standards de formatage.
Rien de tout ça n'est glamour. Personne n'écrit de tweets viraux sur les configs "matcher": "Edit|Write". Mais chaque hook que tu ajoutes, c'est une chose de moins à retenir, une erreur de moins à attraper manuellement, un moment "oh dieu qu'est-ce qu'il vient de faire" de moins. Ils se composent silencieusement pendant que tu dors. Comme les intérêts composés, sauf que c'est utile.
Niveau 3 : Là Où Je Ne Suis Vraiment Pas D'Accord Avec Garry Tan
C'est le niveau qui a transformé ma sortie Claude Code de "impressionnant mais nécessite de la surveillance" à "je scanne le diff 5 minutes et je ship."
J'ai écrit une explication complète des Prompt Contracts il y a quelques semaines — cet article couvre la théorie et le framework original en détail. Ce dont je veux parler ici, c'est du gap spécifique dans l'approche de Garry que les Prompt Contracts comblent.
Le prompt de Garry dit à Claude : "Révise ce plan. Signale les violations DRY. Présente les options. Demande avant de procéder."
C'est de la pensée Niveau 1 appliquée avec une sophistication Niveau 1. C'est la meilleure version de "vérifie ton travail après avoir fini." Mais ça n'adresse pas POURQUOI Claude fait les mauvais choix en premier lieu.
Un exemple Convex de la semaine dernière.
J'ai un projet où les mutations suivent une convention de nommage stricte : [domaine].[action].[cible]. Donc billing.create.invoice, auth.verify.session, scheduling.update.slot. L'équipe frontend grep ces patterns dans leur couche API. Casse le pattern, casse leur workflow.
Avec le prompt de Garry : Claude écrit une mutation appelée createNewInvoice. La révision d'architecture l'attrape comme un "problème d'organisation du code." Je choisis l'option B ("renommer pour suivre la convention"), Claude la renomme. 10 minutes passées sur quelque chose qui n'aurait jamais dû arriver.
Avec un Prompt Contract : Claude voit dans mon CLAUDE.md — "Les mutations Convex suivent le format [domaine].[action].[cible]. Le frontend grep billing.* pour auto-générer leur client API. Casser ce pattern casse le pipeline de build."
Claude écrit billing.create.invoice du premier coup.
Zéro révision nécessaire.
Une approche : tu attrapes les erreurs et tu les corriges.
Autre approche : les erreurs n'arrivent pas parce que Claude pige la contrainte. La différence se compose à travers chaque feature, chaque jour, chaque session.
Et avant que quelqu'un sorte la ligne "donne juste du contexte et du respect à Claude au lieu de contraintes 🤓" — ouais, le POURQUOI derrière chaque décision EST le contexte. Dire "on utilise Clerk parce qu'on a besoin de sync de session basée sur webhook à travers 3 services" C'EST donner de la compréhension à Claude. Les Prompt Contracts ne sont pas des menaces. C'est de la documentation d'architecture qui se trouve vivre dans un fichier que l'IA lit au démarrage. Mais je digresse.
Le gap entre "révise soigneusement la sortie IA" et "façonne l'intention IA pour qu'il y ait moins à réviser" — c'est là que vit le 10x.
À Quoi Ça Ressemble En Pratique
Mon workflow actuel sur une nouvelle feature, maintenant, aujourd'hui :
- CLAUDE.md a mes décisions de stack avec le raisonnement, conventions de nommage, règles de structure de fichiers, et une section "choses que tu seras tenté de faire mais ne devrais pas" (Niveau 3)
- Hooks gèrent le formatage, vérification de types, blocage de commandes destructrices, et notifications (Niveau 2)
- Je scanne le diff pendant ~5 minutes. Occasionnellement Claude me surprend encore. Quand ça arrive, j'ajoute une ligne à CLAUDE.md pour que ça n'arrive plus jamais (alimenter le Niveau 3)
- Plan Mode / révision structurée : je l'utilise peut-être une fois par semaine. Grosses décisions architecturales, refactors complexes. Pas pour chaque feature. (Niveau 1, avec parcimonie)
Avec le prompt de Garry, l'étape 4 était tout le workflow. Chaque feature. À chaque fois. C'est une taxe de 30-45 minutes sur chaque cycle de ship, vs mes ~5 minutes actuelles.
Je n'ai pas de métriques propres avant/après — je ne trackais pas les taux de revert quand j'ai commencé, parce que qui fait ça. Ce que je peux te dire c'est que la sensation du workflow a complètement changé. Avant : chaque git log avait 2-3 commits "revert: undo Claude's helpful suggestion" par jour. Maintenant : peut-être un par semaine, et c'est généralement parce que mon Prompt Contract a un gap que je n'ai pas encore patché. Chaque revert m'apprend où resserrer le Niveau 3, et la tendance générale est à la baisse.
La Partie Que Personne Ne Veut Entendre
Le prompt de Garry Tan est excellent. C'est légitimement le meilleur setup de révision structurée que j'aie vu partagé publiquement. Si tu ne fais rien en ce moment — pas de CLAUDE.md, pas de hooks, juste du "vibe coding" en priant — va utiliser son prompt. Sérieusement. C'est une amélioration massive par rapport à rien.
Mais c'est conçu pour un monde où tu ne fais pas assez confiance à ton IA pour la laisser travailler sans surveillance. Et voici l'ironie : la raison pour laquelle tu ne peux pas lui faire confiance, c'est parce que tu ne lui as pas donné le contexte dont elle a besoin pour être digne de confiance. La solution n'est pas plus de révision. C'est un meilleur input.
Le prompt n'est pas le goulot d'étranglement. Ton intention l'est.
Le framework complet des Prompt Contracts est ici si tu veux le deep dive. La semaine prochaine je publie mon CLAUDE.md complet actuel — celui que j'utilise sur chaque projet, avec chaque section expliquée. Follow si tu ne veux pas le rater.
Et si tu fais tourner le prompt de Garry et que tu ships bien : continue. Vraiment. Mais quand le tapis roulant de révision commencera à ressembler à un boulot à temps partiel, tu sauras où est l'upgrade. 🦞
Plutôt que de passer des heures à réviser le code de Claude, découvrez comment prévenir les erreurs dès le départ avec les Prompt Contracts de Rentier Digital.