La filosofía de Boris Cherny sobre Claude Code (la que el 90% se pierde)

El 23 de abril de 2026, Manthan Patel publicó un breakdown de cómo usa Claude Code el equipo de Anthropic.

El post se viralizó. Miles de personas copiaron el CLAUDE.md de Boris Cherny. Habilitaron todos los hooks. Configuraron permisos, aliases, shortcuts.

Hicieron exactamente lo opuesto a lo que Boris estaba diciendo.

---

Quién es Boris Cherny y por qué su opinión pesa más que cualquier tutorial

Boris Cherny es el Head of Claude Code en Anthropic. No un evangelista, no un content creator, no un consultor que lo usa todos los días. El tipo que lo construyó.

Antes de Anthropic estuvo en Meta, donde trabajó en infraestructura de developer tooling. En su primer mes en Anthropic creó Claude Code. Hoy lidera el equipo que lo desarrolla y lo itera.

Cuando Boris dice algo sobre cómo usar Claude Code, está hablando desde adentro del modelo, desde las decisiones de diseño, desde los patrones que ve funcionar en producción todos los días — no desde un tutorial de YouTube.

Por eso, cuando dijo esto:

"My setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don't customize it much."

("Mi setup podría ser sorprendentemente vainilla. Claude Code funciona muy bien out of the box, así que personalmente no lo customizo demasiado.")

La mayoría lo leyó como modestia. O como que Boris es tan experto que no necesita customizar nada.

Ninguna de las dos lecturas es la correcta.

---

El malentendido viral

Cuando el breakdown de Manthan Patel circuló, la gente se focalizó en la parte equivocada.

Se copiaron los hooks. Se configuraron los permisos permisivos. Se armaron CLAUDE.md con todo lo imaginable adentro. Algunos hasta crearon repos públicos con "el setup de Boris Cherny".

El problema es que esa gente copió la forma pero perdió el fondo.

"Vanilla" en la boca de Boris no significa "simple". Significa que la complejidad no está en la configuración de la herramienta — está en el proceso de usarla.

Boris tiene exactamente un archivo que mantiene con disciplina quirúrgica: su CLAUDE.md. Ese archivo tiene ~2.500 tokens, unas 100 líneas. El equipo entero lo edita varias veces por semana. Cada error que Claude comete y que vale la pena evitar en el futuro, entra ahí.

Eso no es vanilla. Eso es un sistema de mejora continua que se parece bastante a un proceso de ingeniería.

---

Vanilla = disciplina, no acumulación

El insight central de Boris no es "no customices nada". Es que la customización tiene que estar en el lugar correcto.

Lo que hace Boris	Lo que NO hace Boris
Mantiene un CLAUDE.md de ~100 líneas con el equipo	Acumula configuraciones en .claude/settings.json sin criterio
Agrega entradas al CLAUDE.md solo cuando Claude comete un error real	Copia setups de posts de internet
Itera el CLAUDE.md hasta que los errores medibles bajan	Llena el archivo con reglas preventivas especulativas
Usa el mismo approach para todos en el equipo	Tiene un setup "personal secreto" lleno de magic
Revisa y poda el CLAUDE.md con frecuencia	Acumula reglas que nadie sabe si siguen siendo necesarias

La diferencia entre vanilla real y vanilla disciplinado es que el segundo tiene un proceso.

---

Los 5 principios del workflow de Boris

1. Plan mode como punto de partida

Boris arranca casi todas las tareas en plan mode. No le pide a Claude que empiece a ejecutar — le pide que piense primero.

Por qué importa: la mayoría de los errores de Claude no son errores de ejecución, son errores de interpretación. Claude entendió mal el objetivo y ejecutó bien algo que no era lo que querías. Plan mode expone ese malentendido antes de que cueste tiempo revertirlo.

Cómo aplicarlo: antes de cada tarea no trivial, empezá con "antes de hacer nada, contame cómo vas a encarar esto". Si el plan está bien, dale para adelante. Si no, corregilo en ese momento.

2. Estrategia de subagentes

Boris corre hasta 5 instancias de Claude Code simultáneas, más 5-10 sesiones en claude.ai/code. No hace todo en una sola ventana.

Esto no es multitasking humano — es delegación paralela. Mientras una instancia está trabajando en un feature, otra puede estar refactorizando tests, otra haciendo investigación de documentación, otra generando assets.

"There is no one correct way to use Claude Code... Each person on the Claude Code team uses it very differently."

("No hay una única forma correcta de usar Claude Code. Cada persona en el equipo lo usa de forma muy diferente.")

Lo que Boris está diciendo acá es que el workflow tiene que adaptarse a cómo pensás vos, no al revés. La estrategia de subagentes es su solución al problema de paralelismo — puede que la tuya sea distinta.

Cómo aplicarlo: identificá las tareas que podés hacer en paralelo sin dependencias entre sí. Corrilas en instancias separadas. Reunís los resultados después.

3. El self-improvement loop (esto es lo que casi nadie ve)

Este es el principio más importante de todo el workflow de Boris. Y es el que más se pierde en los posts de resumen.

El flujo es este:

1. Claude comete un error (malinterpreta algo, viola una convención, hace algo que no querés que repita)
2. Boris agrega ese error al CLAUDE.md para que Claude no lo repita
3. El equipo entero tagea @.claude en los PRs cuando identifican algo que merece entrar al CLAUDE.md
4. El CLAUDE.md crece por errores reales, no por suposiciones preventivas

Boris lo dijo así:

"Anytime we see Claude do something incorrectly we add it to the CLAUDE.md, so Claude knows not to do it next time."

("Cada vez que vemos a Claude hacer algo mal, lo agregamos al CLAUDE.md, para que Claude sepa que no tiene que hacerlo la próxima vez.")

Y la parte que la mayoría no cita:

"Ruthlessly edit your CLAUDE.md over time. Keep iterating until Claude's mistake rate measurably drops."

("Editá tu CLAUDE.md despiadadamente con el tiempo. Seguí iterando hasta que la tasa de errores de Claude baje de forma medible.")

Esto es un loop de aprendizaje con feedback real. El CLAUDE.md no es un documento de onboarding — es un registro de errores convertidos en contexto.

La diferencia entre un CLAUDE.md bueno y uno mediocre no es el largo. Es cuántos errores reales captura.

4. Verificación antes de "listo"

Boris tiene una regla que dice que el output de Claude mejora entre 2 y 3 veces cuando le das una forma de verificar su propio trabajo:

"Probably the most important thing... give Claude a way to verify its work. It will 2-3x the quality of the final result."

("Probablemente lo más importante... dale a Claude una forma de verificar su trabajo. Va a multiplicar por 2-3 la calidad del resultado final.")

Cómo se traduce esto en práctica: si le pedís a Claude que escriba un test, pedile también que lo corra. Si le pedís que refactorice código, pedile que verifique que los tests siguen pasando. Si le pedís que documente una función, pedile que lea la implementación real antes de escribir la doc.

La verificación no es para chequearte a vos — es para que Claude se checkee a sí mismo antes de mandarte algo.

Cómo aplicarlo: al final de cada prompt que involucra ejecución, agregá "antes de responder, verificá que X". El X depende del contexto: "que los tests pasan", "que el output es consistente con el tipo esperado", "que no rompiste ninguna de las rutas existentes".

5. Delegá, no guíes línea por línea

Este principio va directo contra el instinto más común de los developers que empiezan con Claude Code.

El instinto es: Claude está escribiendo código, yo lo superviso cada línea, le digo qué hacer paso a paso. Es pair programming con la IA como co-piloto.

El problema es que ese modo de trabajo limita a Claude al nivel de lo que vos ya sabés. Si vos tenés que guiar cada línea, Claude solo puede ejecutar lo que vos podrías escribir solo — solo más rápido.

Boris lo plantea diferente:

"The model performs best if you treat it like an engineer you're delegating to, not a pair programmer you're guiding line by line."

("El modelo funciona mejor si lo tratás como un ingeniero al que le delegás, no como un pair programmer al que guiás línea por línea.")

Delegar implica dar el objetivo completo, el contexto suficiente, las restricciones relevantes, y después dejar que Claude encuentre el camino. Si el camino no te gusta, rechazalo y pedí algo distinto.

"Don't accept the first solution. Push Claude to do better — it usually can."

("No aceptes la primera solución. Empujá a Claude a hacerlo mejor — normalmente puede.")

Y sobre el effort:

"I use High for everything."

("Uso High para todo.")

Boris usa Opus con effort=High en todas las tareas sin excepción. No calibra el modelo según la "importancia" de la tarea. Usa el máximo siempre.

---

El CLAUDE.md como sistema vivo

La mayoría de los CLAUDE.md que vi son documentación estática. Alguien los escribió una vez, capturaron las intenciones de ese momento, y ahí quedaron. A veces tienen secciones enteras de reglas que nadie sabe si siguen aplicando.

El CLAUDE.md de Boris es lo opuesto: es un sistema vivo que crece por errores reales.

El mecanismo es concreto. Cuando alguien del equipo ve a Claude hacer algo que no debería, tagea @.claude en el PR correspondiente. Eso dispara una revisión de si el error merece entrar al CLAUDE.md. Si sí, entra. Si no, igual queda documentado el razonamiento de por qué no entró.

El resultado: un archivo que refleja errores reales del equipo real con Claude real. No suposiciones sobre qué podría salir mal. Evidencia de lo que salió mal.

Y la disciplina de poda es tan importante como la de agregar. Cada regla que no se basa en un error observado es una regla que consume tokens innecesarios y puede confundir a Claude con instrucciones contradictorias o irrelevantes.

---

Cómo apliqué esto: de 363 a menos de 150 líneas

En abril de 2026 audité mi ~/.claude/CLAUDE.md. Tenía 363 líneas. Lo bajé a menos de 150.

¿Qué saqué?

• Reglas preventivas que escribí "por las dudas" y que Claude nunca violó en la práctica
• Explicaciones de por qué existía cada regla (útil para mí como nota, inútil como contexto para Claude)
• Secciones enteras de instrucciones que ya estaban capturadas en los CLAUDE.md de cada proyecto específico
• Un bloque de 220 líneas sobre SDD que reemplacé por 3 líneas con el principio central

¿Qué dejé?

• Cada regla que existía porque Claude había hecho algo específico mal antes
• Las preferencias de voz y tono que afectan todas mis conversaciones
• El protocolo de Engram (memoria persistente entre sesiones)
• La jerarquía de herramientas (MCPs, CLI, cuándo usar cada uno)

El resultado: Claude comete menos errores repetidos. Las sesiones necesitan menos correcciones. El contexto es más limpio y más efectivo.

El principio de Boris funcionó exactamente como él lo describe. No porque el archivo sea más corto, sino porque lo que quedó tiene una razón de ser basada en evidencia real.

---

Cómo auditás tu CLAUDE.md siguiendo la filosofía Boris

Si querés aplicar esto mañana, estas son las preguntas concretas:

1. Para cada regla en tu CLAUDE.md, preguntate: "¿Claude alguna vez violó esto?" Si la respuesta es no, probablemente la regla sea preventiva especulativa. Considerá sacarla o moverla a un comentario que no lea Claude.

2. ¿Cuándo fue la última vez que editaste el archivo basándote en un error real? Si hace más de dos semanas que no actualizás el CLAUDE.md, probablemente estás acumulando errores que no capturaste. Revisá las últimas sesiones.

3. ¿El archivo crece hacia adelante o está estancado? Un CLAUDE.md que nunca crece no es señal de que Claude es perfecto — es señal de que no tenés el hábito de capturar errores.

4. ¿Cada regla es accionable? "Ser cuidadoso con el código" no es una regla. "No modificar archivos de producción sin confirmación explícita" sí es una regla. Si Claude no puede ejecutar la instrucción de forma concreta, no sirve.

5. ¿Tenés reglas duplicadas o contradictorias? Después de varios meses de iteración, es común que entren reglas que se solapan o que contradigan versiones anteriores de la misma regla. Auditá que el archivo sea coherente.

6. ¿Las reglas del proyecto están en el proyecto o en el global? Si tu CLAUDE.md global tiene reglas específicas de un proyecto, eso es ruido para todos los demás proyectos. Mové esas reglas al CLAUDE.md del proyecto.

7. ¿Le das a Claude una forma de verificar su trabajo en tus prompts? Esto no va en el CLAUDE.md — va en cómo estructurás cada tarea. Incorporalo como hábito de prompting: cada tarea ejecutable termina con una instrucción de verificación.

---

La frase que resume todo

Boris dijo algo sobre las preguntas aclaratorias que a mí me parece el mejor diagnóstico posible de un problema de workflow:

"When Claude asks too many clarifying questions or goes off-track, that's usually a signal that your brief was incomplete — not that the model needs more hand-holding."

("Cuando Claude hace demasiadas preguntas aclaratorias o se desvía, eso es usualmente una señal de que tu brief estaba incompleto — no de que el modelo necesita más supervisión.")

Esto cambia la dirección del problema. Cuando Claude no funciona bien, el primer lugar donde mirar no es Claude — es tu CLAUDE.md y tus prompts.

Y eso también es filosofía de ingeniería: el sistema no está roto, el input está mal formateado.

---

Recursos y fuentes

Si querés ir directo a la fuente:

• howborisusesclaudecode.com — el breakdown completo de Manthan Patel, con citas directas de Boris
• x.com/bcherny — Boris en X/Twitter, donde ocasionalmente comparte su thinking sobre Claude Code
• claude.ai/code/docs/best-practices — documentación oficial de best practices de Claude Code

---

Si estás armando tu sistema con Claude Code y querés hablar de arquitectura, CLAUDE.md o workflows de agentes, escribime.

Y si te interesa seguir de cerca el ecosistema Claude desde el lado técnico, cada semana publico análisis en este blog — artículos como este, sin resúmenes de newsletter ni listas genéricas de herramientas.