Boris Cherny ya no escribe prompts para Claude.
Eso no es una paráfrasis viral. Es una declaración suya, registrada: «Ya no escribo prompts para Claude. Tengo loops ejecutándose que le escriben prompts a Claude y deciden qué hacer. Mi trabajo es escribir loops». Lo ha dicho en múltiples apariciones públicas: una charla en Sequoia, una entrevista en Acquired, la Startup School de Y Combinator. Y el patrón que subyace a todo esto es el verdadero tema de este artículo. No consejos sueltos. No una lista de funciones. La forma concreta en que la persona que construyó Claude Code lo usa realmente, día a día, verificada contra sus propias declaraciones públicas y no contra paráfrasis de segunda mano.
Este es el desglose completo, basado en lo que Cherny ha dicho realmente, más las prácticas recomendadas que la propia Anthropic ha documentado para la herramienta que él construyó.
Claude Code nunca debió ser un producto
Entender cómo usa Cherny la herramienta empieza por entender de dónde viene, porque el origen explica la filosofía, y es una historia más interesante de lo que la mayoría de quienes usan la herramienta hoy se imaginan.
Claude Code comenzó en 2021 como un proyecto de investigación de seguridad de la IA, no como un producto. Primero una extensión rudimentaria de VS Code, luego una herramienta CLI interna llamada clide, usada dentro de Anthropic durante años antes de que nadie fuera de la empresa oyera hablar de ella. Cherny se unió al proyecto en septiembre de 2024 y reconstruyó el núcleo en un sprint de dos semanas en diciembre de ese año. El lanzamiento público en febrero de 2025 llegó sin estridencias, sin gran fanfarria, y recibió más un encogimiento de hombros que entusiasmo. Luego llegó Claude 4 y la adopción se disparó casi de la noche a la mañana.
Su propia evaluación de dónde está la herramienta ahora, expresada directamente: «Solo hemos llegado al 1%».
Esa forma de verlo importa para cómo deberías abordar su uso. Cherny no está describiendo un producto terminado con un patrón de uso correcto y fijo. Está describiendo algo que todavía se está reconstruyendo activamente, por un equipo que usa la herramienta para construir la herramienta. Claude Code se ha reescrito repetidamente usando el propio Claude Code, un bucle de auto-mejora que precede a que el término «loop engineering» existiera siquiera como frase que alguien usara públicamente. Merece la pena detenerse un momento en esto, porque explica algo que confunde a muchos usuarios nuevos: por qué la forma «correcta» de usar esta herramienta parece estar cambiando constantemente. No es incoherencia. Es una herramienta cuyos propios creadores siguen descubriendo activamente de qué es capaz realmente, en tiempo real, usando la propia herramienta para averiguarlo.
Los años que pasó como herramienta de investigación interna antes de convertirse en producto también explican por qué gran parte de la filosofía que sigue tiene una opinión inusualmente marcada para tratarse de una pieza de software para desarrolladores. La mayoría de las herramientas acumulan funciones para satisfacer desde el primer día a una base de usuarios externa amplia, con necesidades contrapuestas. Claude Code acumuló primero su filosofía, dentro de un equipo pequeño que resolvía sus propios problemas, antes de tener que satisfacer el flujo de trabajo de nadie más. Esa historia es exactamente la razón por la que entender los patrones de uso específicos de Cherny, en lugar de los consejos genéricos de «herramienta de IA para programar», merece el tiempo que lleva asimilarlos.
El cambio fundamental: de escribir prompts a diseñar loops
Lo más importante que Cherny ha dicho públicamente sobre el uso real de Claude Code es la declaración sobre los loops, y merece la pena desgranar qué significa en la práctica, no solo como frase citable.
Un prompt es una instrucción única, enviada una vez, respondida una vez. Un loop es un sistema: le escribe un prompt a Claude, evalúa lo que devuelve, decide qué hacer a continuación y se repite, sin que un humano se siente en medio de cada ciclo. La descripción que hace Cherny de su propio trabajo, «mi trabajo es escribir loops», significa que dedica su tiempo a diseñar los sistemas que generan y evalúan prompts, no a teclear prompts él mismo turno a turno.
Su flujo de trabajo diario confirmado lo refleja directamente. El teléfono como interfaz principal, no el teclado del portátil. De cinco a diez sesiones activas a la vez, cada una capaz de lanzar subagentes, a veces unos cientos a la vez, a veces unos miles durante la noche en los trabajos más profundos. Docenas de loops ejecutándose de forma continua en segundo plano, cuidando pull requests, manteniendo sana la integración continua, agrupando feedback con una programación recurrente. Rutinas que persisten en el servidor incluso cuando cierra el portátil.
La conclusión práctica para cualquiera que use Claude Code a diario: el techo de lo que la herramienta puede hacer no lo fija lo bueno que sea un prompt individual. Lo fija lo bien que diseñes el sistema en torno a ciclos repetidos y automatizados de escritura de prompts, verificación y reintento.
Qué cambió realmente en el system prompt y por qué importa
Cherny también ha hablado directamente de una decisión técnica específica que revela cómo piensa sobre dar instrucciones a Claude en general: «Eliminamos alrededor del 80% del system prompt de Claude Code para nuestros modelos más nuevos; esto es lo que hemos aprendido sobre escribir system prompts».
Ese recorte se produjo específicamente con la generación Opus 4.8, reduciendo el system prompt de aproximadamente 15.000 caracteres a unos 4.500, sin pérdida medible en las evaluaciones de código. La lección detrás de esto, según la propia guía de ingeniería de contexto de Anthropic, es que las listas rígidas y exhaustivas de reglas dejan de ser necesarias cuando un modelo es lo bastante capaz como para ejercer un juicio real. Las reglas se convierten en criterio. Los ejemplos de uso de herramientas se sustituyen por interfaces diseñadas para ser autodocumentadas. El contexto exhaustivo inicial se sustituye por la divulgación progresiva: información que se muestra solo cuando una situación concreta lo requiere, en lugar de cargarse en cada sesión por defecto.
Un matiz que merece la pena incluir con honestidad, porque complica la versión simple de esta historia: cuando se lanzó Opus 5, las pruebas independientes de desarrolladores descubrieron que su system prompt real resultó ser aproximadamente un 72% más largo que el de Opus 4.8. Eso no contradice la lección anterior; es una versión más profunda de la misma. El prompt se redujo en volumen de instrucciones rígidas, y luego volvió a crecer con referencias más ricas y específicas, ejemplos resueltos, suites de tests, rúbricas de evaluación: el tipo de contexto que un modelo genuinamente más capaz sí puede aprovechar de verdad. La conclusión no es que «lo más corto siempre sea mejor». Es que el volumen de instrucciones debe ajustarse a lo que el modelo concreto necesita realmente para ejercer un buen criterio, no a un objetivo fijo en una u otra dirección.
Cómo escribir un CLAUDE.md igual que los propios equipos de Anthropic
Esto conecta directamente con cómo deberías estructurar tus propias instrucciones a nivel de proyecto, y la documentación oficial de Anthropic es explícita sobre el modelo mental que hay que usar: piensa en Claude como un empleado brillante pero muy nuevo, con amnesia, que necesita instrucciones explícitas.
Las implicaciones prácticas de esa forma de verlo. Brillante significa que no necesitas sobre-explicar competencia general; ya está ahí. Nuevo significa cero conocimiento acumulado sobre la historia o las convenciones de tu proyecto concreto. Amnesia significa que cada sesión empieza desde cero; CLAUDE.md es lo único que traslada contexto de forma fiable entre sesiones.
La guía documentada de Anthropic recomienda mantener este archivo por debajo de las 200 líneas, y algunos de los equipos más disciplinados lo tienen en unas 60. La prueba para decidir si algo pertenece al archivo: ¿es esto realmente relevante para casi todas las sesiones, o solo para una parte estrecha y situacional del trabajo? Las cosas universales —comandos de compilación, reglas de estilo innegociables, expectativas de testing, salvaguardas reales— pertenecen al archivo raíz. Cualquier cosa más específica pertenece a un archivo importado, que se trae al contexto solo cuando el trabajo de una sesión concreta realmente lo requiere, usando la sintaxis de importación @path/to/file que la herramienta soporta directamente.
Para las instrucciones que genuinamente no se pueden saltar, la práctica interna de Anthropic usa marcadores de énfasis explícitos —«IMPORTANTE» o «DEBES» (YOU MUST)— reservados específicamente para el puñado de reglas donde el coste de que Claude no las cumpla es realmente alto. Marcar todo de esta manera anula por completo el propósito, porque deja de funcionar como señal en el momento en que se aplica de forma indiscriminada.
Modo Plan: entender antes de actuar
Un patrón de comportamiento concreto que merece la pena incorporar a tu forma de trabajar con la herramienta: conseguir que Claude planifique antes de ejecutar, en lugar de lanzarse directamente a los cambios.
Esto no es solo un interruptor de funcionalidad; refleja un cambio real que los propios materiales de Anthropic describen: los modelos más nuevos planifican correctamente sin necesitar una dirección inicial tan intensa como los anteriores, hasta el punto de que algunos equipos han informado de que ya no necesitan forzar un paso explícito de modo plan para cada tarea, porque el razonamiento por defecto del modelo ya produce un plan coherente antes de actuar. Dicho esto, para cambios genuinamente complejos y multi-archivo, pedir explícitamente un plan primero, y revisarlo antes de aprobar la ejecución, sigue siendo un punto de control muy útil: detecta un requisito mal entendido antes de que se propague a través de una docena de ediciones de archivos, en lugar de después.
Subagentes y trabajo en paralelo
El flujo de trabajo confirmado de Cherny, ejecutando cientos, a veces miles, de subagentes en una sola sesión, apunta a una capacidad estructural que merece la pena entender y usar deliberadamente, no por accidente.
Un agente principal puede descomponer una tarea compleja en piezas más pequeñas y desplegar subagentes para ejecutarlas de forma independiente, cada uno trabajando en su propio contexto en lugar de competir todos por espacio en una misma conversación continua. Esto cumple dos propósitos a la vez. Permite que un trabajo que desbordaría una sola ventana de contexto se ejecute a través de muchas más pequeñas. Y añade una capa real de verificación, porque un subagente que revisa la salida de otro agente está comprobando un trabajo que él mismo no ha producido, lo cual es estructuralmente más fiable que un agente evaluando su propia tarea en la misma pasada en que la ha generado.
Para el trabajo en paralelo específicamente, los git worktrees permiten que varias sesiones operen en ramas o directorios separados simultáneamente sin que los cambios en curso de una sesión interrumpan los de otra. Esta es la infraestructura mecánica que hay debajo de ejecutar muchos loops concurrentes como Cherny describe que hace personalmente: no un solo agente trabajando más rápido, sino muchos agentes trabajando a la vez en piezas de trabajo genuinamente separadas.
La decisión de grep: un caso de estudio de la simplicidad frente a la sofisticación
Una decisión técnica específica y bien documentada del propio equipo de Cherny ilustra una filosofía más amplia que merece la pena interiorizar. Claude Code eliminó la búsqueda vectorial y los embeddings para la búsqueda en el código y optó por grep y glob simples. Sus propias palabras sobre el resultado: «superó a todo lo demás. Por mucho».
La lección se generaliza más allá de esta decisión concreta. Una solución que suena más sofisticada —la búsqueda semántica vectorial— no es automáticamente mejor que una más simple —grep— si la simple está realmente bien ajustada al problema. Los codebases tienen sintaxis exacta, nombres de función exactos, rutas de importación exactas: el tipo de coincidencia precisa y literal en la que grep sobresale y que una coincidencia semántica difusa puede llegar a socavar mostrando resultados plausibles pero erróneos.
La conclusión práctica para cómo configures tus propios flujos de trabajo: no te decantes por defecto por la herramienta o arquitectura que suena más compleja dando por hecho que la complejidad implica capacidad. Prueba primero la opción simple con tu caso de uso real. Muchas veces gana, y aunque no gane, habrás confirmado que el enfoque más complejo se gana su lugar en lugar de darlo por sentado.
Nunca dejes que un agente evalúe su propio trabajo
Un principio separado y confirmado de la práctica de ingeniería de harness de Anthropic, directamente relevante para cómo deberías estructurar cualquier paso de verificación en tus propios flujos de trabajo de Claude Code: la generación y la evaluación deben ocurrir en roles genuinamente separados, porque un modelo que revisa su propia salida en la misma pasada en que la ha producido tiende a sesgarse hacia lo positivo, incluso cuando un revisor humano detectaría el fallo de inmediato.
En la práctica, esto significa que el agente que escribe código no debería ser la misma pasada que decide si ese código es lo bastante bueno para publicarse. Un paso de evaluación separado, idealmente con acceso a algo que el agente generador no tenía —la salida real de la suite de tests, el documento original de requisitos— detecta lo que la autoevaluación se pierde. Este es el mismo principio que hay detrás del patrón de verificación con subagentes de antes, aplicado como una disciplina general en lugar de como una función específica.
Gestión del esfuerzo y del contexto
Para cualquiera que ejecute sesiones más largas y exigentes, importa entender cómo señalar directamente el nivel de esfuerzo. Incluir «ultrathink» en un prompt indica la profundidad máxima de razonamiento para esa respuesta concreta, sin cambiar la configuración general de la sesión. Para la orquestación automática de flujos de trabajo a nivel de sesión, poner el nivel de esfuerzo en su nivel más alto combina el razonamiento profundo con la descomposición automática de tareas a lo largo de la sesión, aunque esto requiere un modelo que realmente soporte ese nivel de esfuerzo; no todos los modelos de una misma gama lo hacen.
La gestión del contexto en sí misma merece atención deliberada en sesiones largas. A medida que una sesión se alarga, el contexto acumulado puede empezar a diluir la señal de lo que importa ahora mismo: el mismo problema que crean los archivos CLAUDE.md inflados, pero produciéndose dinámicamente dentro de una conversación en lugar de estáticamente en un archivo. Iniciar periódicamente una sesión nueva para una fase de trabajo genuinamente nueva, en lugar de alargar una conversación indefinidamente, es una disciplina práctica real que merece la pena aplicar, en lugar de asumir que más contexto siempre es estrictamente mejor.
Un ejemplo práctico: aplicar todo esto a una tarea real
Para que todo lo anterior sea concreto y no abstracto, así es como se combinan estos principios en una tarea real y común: añadir una funcionalidad nueva a un codebase existente con complejidad razonable, unos cuantos archivos interconectados, algunos tests existentes, un cambio no trivial pero tampoco exótico.
Empieza con el CLAUDE.md ya en su sitio, corto, universal, con los comandos de compilación y test, las reglas de estilo innegociables, sin nada situacional que lo ensucie. Esto significa que la sesión arranca con contexto real y relevante cargado automáticamente, sin que tengas que reexplicar las convenciones de tu proyecto desde cero.
En lugar de escribir un único prompt largo y esperanzador que describa toda la funcionalidad con detalle exhaustivo, describe el objetivo y deja que la planificación propia del modelo gestione la descomposición, confiando en la filosofía de andamiaje reducido de la discusión anterior sobre el system prompt. Para una tarea de este tamaño, pedir explícitamente un plan primero merece la pena el paso extra, porque un requisito mal entendido detectado aquí cuesta una corrección de dos minutos en lugar de una hora deshaciendo cambios en varios archivos más tarde.
Cuando el plan tenga buena pinta, deja que la ejecución avance. Si la tarea se divide de forma natural en piezas genuinamente independientes —actualizar un modelo de datos y, por separado, actualizar la interfaz que lo consume, por ejemplo—, ese es un candidato natural para la descomposición en subagentes: cada pieza trabajando en su propio contexto en lugar de apiñarse todo en una única conversación continua.
Antes de dar el resultado por terminado, ejecuta una pasada de verificación separada en lugar de fiarte del autoinforme del agente implementador de que todo funciona. Esto puede ser tan simple como una sesión nueva, o un subagente con acceso de solo lectura, que compruebe la salida real de los tests y el diff contra el plan original, no solo aceptar un «está completo» lleno de confianza desde el mismo contexto que escribió el código.
Fíjate en lo que falta en este recorrido. Nada de herramientas exóticas. Ninguna configuración inusual. Solo la aplicación ordinaria de planificar primero para el trabajo genuinamente complejo, descomposición en subagentes para las piezas genuinamente independientes y verificación separada en lugar de autoevaluación: los mismos tres principios que atraviesan todo lo anterior, aplicados a una tarea concreta en lugar de descritos de forma abstracta.
Escalar esto más allá de una sola persona
Todo lo anterior describe prácticas para una persona que usa Claude Code de forma deliberada. El flujo de trabajo confirmado del propio Cherny —cientos de subagentes al día, miles durante la noche— es ya en sí mismo una forma de escalar: una sola persona dirigiendo una cantidad genuinamente grande de trabajo automatizado en paralelo. Pero los mismos principios se extienden a un equipo que adopta estas prácticas de forma conjunta, con algunas consideraciones específicas que merece la pena nombrar directamente.
CLAUDE.md deja de ser un archivo de preferencias personal en el momento en que más de una persona del equipo trabaja de verdad contra el mismo codebase con Claude Code. Trata los cambios que se le hagan con la misma disciplina de revisión que aplicarías a cualquier configuración compartida que afecte al flujo de trabajo de todo el equipo. Un compañero que añade una instrucción «hotfix» puntual después de una única sesión frustrante, sin revisión, es exactamente el mecanismo que produce los archivos inflados y autocontradictorios que dejan de seguirse de forma fiable. Un paso de revisión ligero, aunque solo sea que una segunda persona eche un vistazo al diff antes de que se fusione, atrapa una parte significativa de esto antes de que se acumule hasta convertirse en un problema real.
La disciplina de verificación importa aún más a escala de equipo que para un usuario individual. Cuando una persona escribe y revisa a la vez su propio trabajo asistido por agentes, al menos existe la posibilidad de que detecte personalmente algo que el agente pasó por alto. Cuando un equipo depende de que la salida de Claude Code fluya a través de un proceso de revisión compartido, el principio de evaluación separada de antes deja de ser opcional: es el mecanismo real que protege el codebase de que la autoevaluación confiada pero errónea de un agente llegue a producción, porque la alternativa es confiar en que algún humano, en algún momento del ajetreado flujo de trabajo de un equipo, se tope con lo que el agente no señaló por sí mismo.
Merece la pena establecer también una propiedad explícita sobre las auditorías periódicas de CLAUDE.md: la misma disciplina de mantenimiento recomendada para cualquier documento compartido y acumulativo. Sin un propietario claramente asignado, este trabajo tiende a caerse por las grietas precisamente porque no bloquea ninguna tarea inmediata concreta como lo hace una compilación rota, y seis meses de adiciones sin dueño producen exactamente el tipo de archivo inflado y contradictorio que el principio de aplicabilidad universal existe para prevenir en primer lugar.
Dónde la gente aplica mal estos principios
Un puñado de lecturas equivocadas de las ideas anteriores aparecen una y otra vez, y merece la pena nombrarlas directamente porque cada una tiene una corrección simple y específica.
Tratar «loops en lugar de prompts» como una licencia para saltarse por completo la comprensión de la tarea. La declaración de Cherny es que su trabajo es escribir loops, no que haya dejado de pensar en qué deberían hacer realmente esos loops. Diseñar un buen loop —una buena definición de éxito, una buena condición de parada— sigue exigiendo entender el problema con la misma claridad que lo exigiría escribir un buen prompt individual. El loop sustituye al tecleo manual repetido, no al pensamiento previo.
Leer la reducción del system prompt como «dale al modelo menos contexto, siempre». El contrapunto de Opus 5 al principio de este artículo existe precisamente para corregir esta mala lectura. La lección real es que el volumen de instrucciones debe ajustarse a lo que un modelo concreto necesita de verdad para ejercer un buen criterio, lo que a veces significa menos listas rígidas de reglas y a veces significa más material de referencia rico y específico. Recortar contexto de forma indiscriminada porque «los modelos más nuevos necesitan menos» aplica mal un hallazgo matizado y específico de un modelo como si fuera una regla general.
Sobre-descomponer tareas simples en subagentes por costumbre. La descomposición en subagentes se gana su complejidad en piezas de trabajo genuinamente grandes y genuinamente independientes. Dividir un cambio pequeño y estrechamente acoplado en piezas artificiales de subagentes solo para usar el patrón añade sobrecarga de coordinación sin el beneficio que la justifica en tareas más grandes. El ejemplo práctico anterior en este artículo usó subagentes deliberadamente solo donde las piezas eran naturalmente independientes, no como una opción predeterminada para cada tarea sin importar su tamaño.
Saltarse la verificación asumiendo que «los modelos más nuevos ya no la necesitan». El principio de evaluación separada no es un parche para modelos más débiles que se volverá innecesario a medida que mejore la capacidad. Es un hecho estructural sobre la autoevaluación: a un modelo que comprueba su propio trabajo en el mismo contexto en que lo produjo siempre le costará más detectar sus propios puntos ciegos que a una comprobación independiente, sin importar lo capaz que se vuelva ese modelo subyacente. Esto también es cierto para los revisores humanos, y no deja de serlo porque el revisor se vuelva más inteligente.
Los hábitos diarios reales que merece la pena adoptar
Resumiendo todo lo anterior en una práctica diaria concreta y aplicable, así es como se ve en la práctica seguir el enfoque demostrado por Cherny.
Deja de tratar cada tarea como un prompt único que hay que acertar al primer intento. Diseña un loop en su lugar: un agente que intenta la tarea, una forma de comprobar si el intento tuvo éxito, y un camino definido para lo que ocurre después según esa comprobación: aprobar, reintentar o escalar directamente a ti.
Mantén tu CLAUDE.md corto y trátalo como material de incorporación para un nuevo empleado capaz pero sin contexto, no como un manual exhaustivo. Mueve cualquier cosa situacional a archivos importados en lugar de inflar el documento raíz.
Usa el modo plan deliberadamente en el trabajo genuinamente complejo y multi-archivo, y confía en la planificación por defecto del modelo en tareas más simples y bien acotadas, en lugar de forzar un paso extra en todas partes por costumbre.
Descompón las tareas grandes en subagentes que trabajen en contextos separados, en lugar de intentar sostener una tarea compleja entera en una única conversación continua. Usa una pasada separada para verificar el trabajo significativo, en lugar de fiarte de la autoevaluación de un solo agente.
Opta por defecto por la herramienta más simple que plausiblemente pueda resolver tu problema concreto, como grep le ganó a la búsqueda vectorial para este caso de uso exacto, y recurre a más complejidad solo cuando la opción simple se haya probado de verdad y se haya quedado corta.
Construye paralelismo real en tu flujo de trabajo usando git worktrees para las piezas de trabajo genuinamente independientes, en lugar de ejecutarlo todo a través de una sola sesión secuencial porque esa es la forma de trabajar por defecto.
Hacia dónde se dirige realmente esto
La forma de verlo del propio Cherny —«solo hemos llegado al 1%»— merece tomarse en serio como declaración práctica, no solo como una frase de apariencia humilde. Los patrones específicos descritos arriba —diseño de loops por encima del prompting individual, poda agresiva del system prompt a medida que los modelos son más capaces, descomposición en subagentes, verificación separada— no son una metodología fija y final. Son el estado actual de una herramienta y una práctica que su propio creador describe como todavía temprana.
La habilidad real que merece la pena construir no es memorizar la configuración concreta de mejores prácticas de hoy. Es entender los principios subyacentes lo bastante bien como para seguir adaptándote mientras la herramienta misma sigue cambiando, igual que el propio equipo de Cherny reconstruyó Claude Code repetidamente usando Claude Code, refinando el loop en lugar de tratar cualquier versión concreta como terminada.
Ese es el verdadero hilo conductor que conecta todo en este artículo. No una lista estática de consejos, sino una filosofía de trabajo: diseña sistemas en lugar de teclear instrucciones sueltas, mantén las instrucciones ligeras y deja que la capacidad del modelo haga más del trabajo a medida que mejora, verifica de forma independiente en lugar de fiarte de la autoevaluación, y opta por la simplicidad hasta que la complejidad demuestre que es necesaria. Directamente de cómo la persona que construyó la herramienta la usa él mismo.
Sigue a @cyrilXBT para más desgloses de Claude Code basados en material verificado y registrado.
