El CEO de Y Combinator Compartió su Prompt de Código para Claude. Pero Resuelve el Problema Equivocado
Estaba ejecutando el CLAUDE.md más sofisticado que había visto jamás — un pipeline de revisión estructurado que obliga a Claude a pasar por verificaciones de arquitectura, calidad de código, tests y rendimiento antes de tocar cualquier cosa. En papel era brillante. En la práctica me había dado un trabajo de medio tiempo como ingeniero de QA para un robot.
Así que lo eliminé por completo.
TL;DR: Hay 3 capas para controlar Claude Code: revisión (detectar errores después), aplicación (bloquear errores durante), e intención (prevenir errores antes). La mayoría de devs — incluyendo el CEO de YC — están atascados en la capa 1. Las ganancias reales están en la capa 3. Desglose completo de Prompt Contracts aquí.
El Prompt Que Arruinó Mi Semana
¿Ese pipeline de revisión? No era mío. Venía de Garry Tan — sí, el CEO de Y Combinator. Compartió su prompt de Claude Code en X hace unas semanas y se volvió viral. 3,000 likes. Dev Twitter perdió la cabeza. Y entiendo por qué — el tipo dirige Y Combinator y aún escribe su propio CLAUDE.md. Solo eso lo pone por delante del 90% de CEOs tech que "usan AI" refiriéndose a que le dictan a un asistente que luego tipea en ChatGPT.
Su configuración fuerza a Claude al Plan Mode con un pipeline de revisión estructurado: arquitectura primero, calidad de código segundo, tests tercero, rendimiento cuarto. Cada sección muestra hasta 4 problemas. Cada problema obtiene 2–3 opciones con trade-offs. Claude numera todo, pone letras a las opciones, y espera tu aprobación explícita antes de tocar una sola línea.
Es minucioso. Es disciplinado. Es básicamente una checklist automatizada de revisión de PR de un senior engineer.
Lo ejecuté en un proyecto de Convex que estaba refactorizando — un motor de scheduling con auth de Clerk y Supabase para las partes que Convex no cubre. ¿Y honestamente? La revisión de arquitectura detectó un problema de acoplamiento entre mi middleware de auth y mis rutas de API que había estado fingiendo que no existía por una semana. El pase de rendimiento encontró dos queries N+1 que genuinamente no sabía que existían. Buen material.
¿Entonces por qué lo eliminé?
Porque después de 48 horas me di cuenta de que me había convertido en un revisor de tiempo completo de Claude revisando mi código. Cuatro secciones. Hasta 4 problemas cada una. 2–3 opciones por problema. Cada una requiriendo mi explícito "sí, opción B, procede." En una feature mediana, eso son 30–45 minutos de ida y vuelta antes de que algo cambie. Es como contratar a un trabajador y luego pasar todo tu día viéndolo por la ventana, asintiendo a cada clavo.
Garry Tan construyó un sistema de revisión de código para su AI. Lo que significa que está usando AI para generar más trabajo de revisión para él mismo 🙃
La cinta de revisión es seductora porque se siente productiva. Estás leyendo, evaluando, tomando decisiones. Pero lo estás haciendo todo downstream — después de que Claude ya eligió una dirección. Estás corrigiendo el curso de un auto que ya está manejando.
¿Y el remate? Claude no recuerda tus correcciones en la siguiente sesión de todas formas.
Tres Capas, Una Jerarquía
Después de deshacerme del prompt de Garry no volví a las vibes. He estado ejecutando Claude Code en SaaS de producción por meses y he visto cada modo de falla — la eliminación silenciosa de .env, el intercambio de schema de Supabase a medianoche, el clásico "optimicé tu código removiendo la parte que funcionaba." A lo que he llegado es a una jerarquía.
Capa 1: Revisión (enfoque de Garry Tan) Deja que Claude codee, luego revisa el output. Revisión estructurada, Plan Mode, "pregúntame antes de respirar." Detecta errores después de que existen en tu codebase.
Capa 2: Aplicación (Hooks) Scripts de shell que se ejecutan automáticamente cuando Claude hace algo. Formatear al guardar, bloquear comandos peligrosos, ejecutar typechecks. Detecta errores mecánicos durante la ejecución. No requiere atención humana.
Capa 3: Intención (Prompt Contracts) Moldeas lo que Claude entiende sobre tu proyecto antes de que escriba algo. Decisiones de arquitectura, convenciones de naming, el POR QUÉ detrás de tu stack. Previene que los errores sean concebidos.
La mayoría de devs viven en la Capa 1.
Algunos power users agregan la Capa 2.
Casi nadie construye la Capa 3 apropiadamente — lo cual es loco, porque ahí es donde viven los retornos compuestos.
Capa 2: La Que Se Paga Sola De La Noche A La Mañana
Lo sé — acabo de decirte que la Capa 3 es el endgame. Pero la Capa 2 es donde viven las victorias más rápidas, porque es pura automatización. Configúrala una vez, nunca pienses en ella otra vez. Como un detector de humo, excepto que en lugar de fuego detecta a Claude tratando de hacer rm -rf a la raíz de tu proyecto.
El concepto: tu CLAUDE.md es la guía de estilo. Los hooks son el linter. Uno sugiere, el otro aplica.
Mi configuración real de .claude/settings.json (parcial):
{
"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\"'"
}
]
}
]
}
}
Y el firewall de bash que me salva la vida como una vez por semana:
#!/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
El hook de protección de archivos es el que agregué después de que Claude decidiera que mi .env.local estaba "sin usar" y trató de limpiarlo. Una vez. Fue suficiente. ¿Conoces esa sensación cuando ves tus credenciales de prod desaparecer en tiempo real? Sí. Ahora Claude físicamente no puede tocar .env*, package-lock.json, o cualquier cosa en .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
El hook Stop con notificación de macOS suena tonto hasta que estás ejecutando 3 sesiones de Claude en paralelo y una de ellas ha estado inactiva por dios sabe cuánto tiempo mientras estás metido en otra terminal. Ese tiempo muerto se acumula rápido cuando estás haciendo malabares con branches.
El hook PostToolUse de Prettier mató la mayoría de los nitpicks de formateo en mis PRs.
No porque Claude escriba código feo — usualmente no lo hace — pero "usualmente" no es una palabra que quieras en ningún lugar cerca de tus estándares de formateo.
Nada de esto es glamoroso. Nadie está escribiendo tweets virales sobre configs de "matcher": "Edit|Write". Pero cada hook que agregas es una cosa menos que recordar, un error menos que detectar manualmente, un momento menos de "oh dios qué acaba de hacer". Se componen silenciosamente mientras duermes. Como el interés compuesto, excepto que es útil.
Capa 3: Donde Realmente Discrepo Con Garry Tan
Esta es la capa que convirtió mi output de Claude Code de "impresionante pero necesita niñera" a "escaneo el diff por 5 minutos y shipeo."
Escribí un desglose completo de Prompt Contracts hace unas semanas — ese artículo cubre la teoría y el framework original en detalle. De lo que quiero hablar aquí es del gap específico en el enfoque de Garry que los Prompt Contracts llenan.
El prompt de Garry le dice a Claude: "Revisa este plan. Marca violaciones de DRY. Presenta opciones. Pregunta antes de proceder."
Eso es pensamiento de Capa 1 aplicado con sofisticación de Capa 1. Es la mejor versión de "revisa tu trabajo después de que termines." Pero no aborda POR QUÉ Claude hace las elecciones incorrectas en primer lugar.
Un ejemplo de Convex de la semana pasada.
Tengo un proyecto donde las mutations siguen una convención de naming estricta: [domain].[action].[target]. Entonces billing.create.invoice, auth.verify.session, scheduling.update.slot. El equipo de frontend hace grep de estos patrones en su capa de API. Rompe el patrón, rompe su workflow.
Con el prompt de Garry: Claude escribe una mutation llamada createNewInvoice. La revisión de arquitectura la detecta como una "preocupación de organización de código." Elijo la opción B ("renombrar para seguir convención"), Claude la renombra. 10 minutos gastados en algo que nunca debería haber pasado.
Con un Prompt Contract: Claude ve en mi CLAUDE.md — "Las mutations de Convex siguen el formato [domain].[action].[target]. El frontend hace grep de billing.* para auto-generar su cliente API. Romper este patrón rompe el pipeline de build."
Claude escribe billing.create.invoice la primera vez.
Cero revisión necesaria.
Un enfoque: detectas errores y los arreglas.
Otro enfoque: los errores no pasan porque Claude entiende la restricción. La diferencia se compone a través de cada feature, cada día, cada sesión.
Y antes de que alguien suelte la línea de "solo dale contexto y respeto a Claude en lugar de restricciones 🤓" — sí, el POR QUÉ detrás de cada decisión ES el contexto. Decir "usamos Clerk porque necesitamos sincronización de sesión basada en webhooks a través de 3 servicios" ES darle entendimiento a Claude. Los Prompt Contracts no son amenazas. Son documentación de arquitectura que resulta vivir en un archivo que la AI lee al inicio. Pero divago.
El gap entre "revisar output de AI cuidadosamente" y "moldear la intención de AI para que haya menos que revisar" — ahí es donde vive el 10x.
Cómo Se Ve Esto En La Práctica
Mi workflow real en una nueva feature, ahora mismo, hoy:
- CLAUDE.md tiene mis decisiones de stack con el razonamiento, convenciones de naming, reglas de estructura de archivos, y una sección de "cosas que estarás tentado a hacer pero no deberías" (Capa 3)
- Hooks manejan formateo, type checking, bloqueo de comandos destructivos, y notificaciones (Capa 2)
- Escaneo el diff por ~5 minutos. Ocasionalmente Claude aún me sorprende. Cuando lo hace, agrego una línea a CLAUDE.md para que nunca pase otra vez (alimentando Capa 3)
- Plan Mode / revisión estructurada: Lo uso tal vez una vez por semana. Decisiones arquitectónicas grandes, refactors complejos. No para cada feature. (Capa 1, con moderación)
Con el prompt de Garry, el paso 4 era todo el workflow. Cada feature. Cada vez. Eso es un impuesto de 30–45 minutos en cada ciclo de ship, vs mis ~5 minutos actuales.
No tengo métricas limpias de antes/después — no estaba rastreando tasas de revert cuando empecé, porque quién lo hace. Lo que puedo decirte es que la sensación del workflow cambió completamente. Antes: cada git log tenía 2-3 commits de "revert: deshacer sugerencia útil de Claude" por día. Ahora: tal vez uno por semana, y usualmente es porque mi Prompt Contract tiene un gap que aún no he parchado. Cada revert me enseña dónde apretar la Capa 3, y la tendencia general es hacia abajo.
La Parte Que Nadie Quiere Escuchar
El prompt de Garry Tan es genial. Es legítimamente la mejor configuración de revisión estructurada que he visto compartida públicamente. Si no estás haciendo nada ahora mismo — sin CLAUDE.md, sin hooks, solo "vibe coding" y rezando — ve y usa su prompt. En serio. Es una mejora masiva sobre nada.
Pero está diseñado para un mundo donde no confías en tu AI lo suficiente para dejarlo trabajar sin supervisión. Y aquí está la ironía: la razón por la que no puedes confiar en él es porque no le has dado el contexto que necesita para ser confiable. La solución no es más revisión. Es mejor input.
El prompt no es el cuello de botella. Tu intención sí.
El framework completo de Prompt Contracts está aquí si quieres el deep dive. La próxima semana estoy publicando mi CLAUDE.md completo real — el que uso en cada proyecto, con cada sección explicada. Sígueme si no te lo quieres perder.
Y si estás ejecutando el prompt de Garry y shipeando bien: sigue adelante. En serio. Pero cuando la cinta de revisión empiece a sentirse como un trabajo de medio tiempo, sabrás dónde está la mejora. 🦞
Cuando se trata de construir agentes de IA para producción, no se trata de más revisión, sino de prevenir errores desde el origen. Compartimos semanalmente cómo hacer exactamente eso.