Boris Cherny ya no le escribe prompts a Claude.
Eso no es una paráfrasis viral. Es su propia declaración pública: "Ya no le escribo prompts a Claude. Tengo loops corriendo que le escriben prompts a Claude y deciden qué hacer. Mi trabajo es escribir loops." Lo dijo 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 tips. No una lista de funciones. La forma específica en que la persona que construyó Claude Code realmente lo usa, día a día, verificada contra sus propias declaraciones públicas en lugar de paráfrasis de segunda mano.
Este es el desglose completo, basado en lo que Cherny realmente ha dicho, más las mejores prácticas documentadas por la propia Anthropic para la herramienta que él construyó.
Claude Code Nunca Debió Ser Un Producto
Entender cómo Cherny usa 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 las personas que usan la herramienta hoy en día se imaginan.
Claude Code comenzó en 2021 como un proyecto de investigación de seguridad de IA, no como un producto. Primero fue una extensión tosca de VS Code, luego una herramienta CLI interna llamada clide, usada dentro de Anthropic durante años antes de que alguien 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ó en silencio, sin mucho alboroto, y recibió más encogimientos de hombros que entusiasmo. Luego llegó Claude 4 y la adopción explotó casi de la noche a la mañana.
Su propia evaluación de dónde está la herramienta ahora, dicha directamente: "Solo estamos al 1%."
Ese enfoque importa para cómo deberías usarla. Cherny no está describiendo un producto terminado con un patrón de uso correcto y fijo. Está describiendo algo que su propio equipo sigue reconstruyendo activamente, usando la herramienta para construir la herramienta. Claude Code ha sido reescrito repetidamente usando Claude Code, un loop de auto-mejora que precede a que el término "loop engineering" existiera como una frase que alguien usara públicamente. Vale 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 seguir cambiando. No es inconsistencia. Es una herramienta cuyos propios creadores todavía están descubriendo activamente de qué es capaz realmente, en tiempo real, usando la propia herramienta para averiguarlo.
Los años como herramienta de investigación interna antes de convertirse en producto también explican por qué gran parte de la filosofía a continuación se lee como inusualmente opinionada para una pieza de software de desarrollo. La mayoría de las herramientas acumulan funciones para satisfacer a una base amplia de usuarios externos con necesidades contrapuestas desde el primer día. Claude Code acumuló su filosofía primero, dentro de un equipo pequeño resolviendo 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 consejos genéricos de "herramientas de IA para programar", vale el tiempo que toma realmente absorberlos.
El Cambio Central: De Escribir Prompts A Diseñar Loops
Lo más importante que Cherny ha dicho públicamente sobre usar Claude Code es la declaración sobre los loops, y vale la pena desglosar lo que significa en la práctica, no solo como una 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 regresa, decide qué pasa después y se repite, sin un humano sentado en medio de cada ciclo. La descripción de trabajo declarada de Cherny — "mi trabajo es escribir loops" — significa que dedica su tiempo a diseñar los sistemas que generan y evalúan prompts, no a escribir prompts él mismo turno por turno.
Su flujo de trabajo diario confirmado refleja esto directamente. El teléfono como su interfaz principal, no un teclado de laptop. De cinco a diez sesiones activas corriendo a la vez, cada una capaz de generar subagentes, a veces unos cientos a la vez, a veces unos miles durante la noche en trabajos más profundos. Decenas de loops corriendo continuamente en segundo plano, cuidando pull requests, manteniendo sana la integración continua, agrupando comentarios en un horario recurrente. Rutinas que persisten del lado del servidor incluso cuando su laptop está cerrada.
La conclusión práctica para cualquiera que use Claude Code día a día: el techo de lo que la herramienta puede hacer no lo establece lo bueno que sea un solo prompt. Lo establece qué tan bien diseñes el sistema alrededor de ciclos repetidos y automatizados de prompts, verificación y reintentos.
Lo Que Realmente Cambió En El Prompt Del Sistema Y Por Qué Importa
Cherny también ha hablado directamente sobre una decisión técnica específica que revela cómo piensa en dar instrucciones a Claude: "Eliminamos ~80% del prompt del sistema de Claude Code para nuestros modelos más nuevos; esto es lo que hemos aprendido sobre escribir prompts del sistema."
Ese recorte ocurrió específicamente con la generación de Opus 4.8, reduciendo el prompt del sistema de aproximadamente 15,000 caracteres a alrededor de 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 una vez que un modelo es lo suficientemente capaz como para ejercer un criterio real. Las reglas se convierten en decisiones de criterio. Los ejemplos de uso de herramientas se reemplazan por interfaces diseñadas para ser autodocumentadas. El contexto exhaustivo inicial se reemplaza por revelación progresiva: la información aparece solo cuando una situación específica realmente la requiere, en lugar de cargarse en cada sesión por defecto.
Un matiz que vale la pena incluir con honestidad, porque complica la versión simple de esta historia: cuando llegó Opus 5, pruebas independientes de desarrolladores encontraron que su prompt del sistema real resultó 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 ella. El prompt se redujo en volumen de instrucciones rígidas, y luego creció de nuevo en referencias más ricas y específicas, ejemplos resueltos, suites de pruebas, rúbricas de evaluación: el tipo de contexto que un modelo genuinamente más capaz puede aprovechar bien. La conclusión no es "más corto siempre es mejor". Es que el volumen de instrucciones debe seguir lo que el modelo específico realmente necesita para ejercer buen criterio, no un objetivo fijo en ninguna dirección.
Escribir Un CLAUDE.md Como Lo Hacen Los 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 a usar: piensa en Claude como un empleado brillante pero muy nuevo, con amnesia, que necesita instrucciones explícitas.
Las implicaciones prácticas de ese enfoque. Brillante significa que no necesitas sobre-explicar la competencia general, ya está ahí. Nuevo significa cero conocimiento acumulado sobre la historia o las convenciones de tu proyecto específico. Amnesia significa que cada sesión empieza desde cero; CLAUDE.md es lo único que transporta contexto de forma confiable entre sesiones.
La guía documentada de Anthropic apunta a mantener este archivo por debajo de 200 líneas, con algunos de los equipos más disciplinados llegando a tan solo 60. La prueba para saber si algo pertenece al archivo: ¿es esto genuinamente relevante para casi todas las sesiones, o solo para una parte estrecha y situacional del trabajo? Las cosas universales — comandos de build, reglas de estilo innegociables, expectativas de pruebas, protecciones 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 específico de una sesión realmente lo requiere, usando la sintaxis de importación @path/to/file que la herramienta soporta directamente.
Para instrucciones que genuinamente no pueden omitirse, la práctica interna de Anthropic usa marcadores de énfasis explícitos, como "IMPORTANT" o "YOU MUST", reservados específicamente para las pocas reglas donde el costo de que Claude las pase por alto es genuinamente alto. Marcar todo de esta manera destruye el propósito por completo, porque deja de funcionar como una señal en el momento en que se aplica indiscriminadamente.
Modo Plan: Entender Antes De Actuar
Un patrón de comportamiento específico que vale la pena incorporar a tu forma de trabajar con la herramienta: hacer que Claude planifique antes de ejecutar, en lugar de saltar directamente a los cambios.
Esto no es solo un interruptor de funciones; 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 pesada como la que necesitaban los anteriores, hasta el punto de que algunos equipos han reportado que ya no necesitan forzar un paso explícito de modo plan para cada tarea, porque el razonamiento predeterminado del modelo ya produce un plan coherente antes de actuar. Dicho esto, para cambios genuinamente complejos de múltiples archivos, solicitar explícitamente un plan primero, y revisarlo antes de aprobar la ejecución, sigue siendo un punto de control real y útil: atrapa 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 — correr cientos, a veces miles, de subagentes en una sola sesión — apunta a una capacidad estructural que vale 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 que todo compita por espacio en una sola conversación continua. Esto cumple dos propósitos a la vez. Permite que el trabajo que desbordaría una sola ventana de contexto corra a través de muchas ventanas más pequeñas. Y añade una capa real de verificación, porque un subagente que revisa la salida de otro agente está verificando un trabajo que no produjo él mismo, lo cual es estructuralmente más confiable que un agente corrigiendo su propia tarea en el mismo aliento que la produjo.
Para trabajo en paralelo específicamente, los git worktrees permiten que múltiples sesiones operen en ramas o directorios separados simultáneamente, sin que los cambios en progreso de una sesión interrumpan los de otra. Esta es la infraestructura mecánica que sustenta la ejecución de muchos loops concurrentes de la forma en que Cherny describe hacerlo personalmente: no un solo agente trabajando más rápido, sino muchos agentes trabajando en piezas de trabajo genuinamente separadas al mismo tiempo.
La Decisión De Usar Grep: Un Caso De Estudio De Simplicidad Sobre 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 vale la pena internalizar. Claude Code eliminó la búsqueda vectorial y los embeddings para la búsqueda en la base de código, a favor de grep y glob simples. Sus propias palabras sobre el resultado: "superó a todo. Por mucho."
La lección se generaliza más allá de esta decisión específica. 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 más simple está realmente bien adaptada al problema. Las bases de código tienen sintaxis exacta, nombres de funciones 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 socavar al mostrar resultados plausibles pero incorrectos.
La conclusión práctica para configurar tus propios flujos de trabajo: no optes por la herramienta o arquitectura que suene más compleja por la suposición de que la complejidad implica capacidad. Prueba primero la opción simple contra tu caso de uso real. Muchas veces gana, e incluso cuando no lo hace, has confirmado que el enfoque más complejo se gana su lugar en lugar de asumirlo.
Nunca Dejes Que Un Agente Califique 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 el mismo aliento que la produjo tiende a sesgarse hacia lo positivo, incluso cuando un revisor humano detectaría el defecto 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 suficientemente bueno para enviarse a producción. 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 pruebas, el documento original de requisitos — atrapa lo que la auto-evaluación se pierde. Este es el mismo principio detrás del patrón de verificación con subagentes de arriba, aplicado como disciplina general en lugar de como función específica.
Gestión De Esfuerzo Y Contexto
Para cualquiera que ejecute sesiones más largas y exigentes, entender cómo señalar el nivel de esfuerzo directamente importa. Incluir "ultrathink" en un prompt señala la máxima profundidad de razonamiento para esa respuesta específica 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, establecer el nivel de esfuerzo en su nivel más alto combina razonamiento profundo con 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 gama lo soportan.
La gestión del contexto en sí merece atención deliberada en sesiones largas. A medida que una sesión se extiende, el contexto acumulado puede empezar a diluir la señal de lo que realmente importa en ese momento: el mismo problema que crean los archivos CLAUDE.md inflados, solo que ocurriendo dinámicamente dentro de una sola conversación en lugar de estáticamente en un archivo. Iniciar periódicamente una sesión nueva para una fase genuinamente nueva de trabajo, en lugar de extender una conversación indefinidamente, es una disciplina real y práctica que vale la pena aplicar, en lugar de asumir que más contexto siempre es estrictamente mejor.
Un Ejemplo Práctico: Aplicar Esto A Una Tarea Real
Para hacer todo lo anterior concreto en lugar de abstracto, así es como estos principios se combinan en una tarea real y común: añadir una función nueva a una base de código existente con complejidad razonable, algunos archivos interconectados, algunas pruebas existentes, un cambio no trivial pero no exótico.
Empieza con el CLAUDE.md ya en su lugar: corto, universal, con los comandos de build y de prueba, las reglas de estilo innegociables, sin nada situacional que lo ensucie. Esto significa que la sesión comienza con contexto real y relevante cargado automáticamente, sin que tengas que re-explicar las convenciones de tu proyecto desde cero.
En lugar de escribir un solo prompt largo y esperanzador que describa la función completa con detalle exhaustivo, describe el objetivo y deja que la planificación propia del modelo maneje la descomposición, confiando en la filosofía de andamiaje reducido de la discusión sobre el prompt del sistema de arriba. Para una tarea de este tamaño, solicitar explícitamente un plan primero vale el paso extra, porque un requisito mal entendido atrapado aquí cuesta una corrección de dos minutos en lugar de una hora deshaciendo cambios en múltiples archivos más tarde.
Una vez que el plan se ve bien, deja que la ejecución proceda. Si la tarea se divide naturalmente 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 que todo se amontone en una sola conversación continua.
Antes de tratar el resultado como terminado, ejecuta una pasada de verificación separada en lugar de confiar en el auto-reporte 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 verifique la salida real de las pruebas y el diff contra el plan original, en lugar de aceptar un confiado "está completo" del mismo contexto que escribió el código.
Nota lo que está ausente en este recorrido. Sin herramientas exóticas. Sin configuración inusual. Solo la aplicación ordinaria de plan-primero para trabajo genuinamente complejo, descomposición en subagentes para piezas genuinamente independientes, y verificación separada en lugar de auto-evaluació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 deliberadamente. El flujo de trabajo confirmado del propio Cherny — cientos de subagentes diarios, miles durante la noche — ya es en sí mismo una forma de escalamiento: una persona dirigiendo una cantidad genuinamente grande de trabajo paralelo y automatizado. Pero los mismos principios se extienden a un equipo que adopta estas prácticas en conjunto, con algunas consideraciones específicas que vale la pena nombrar directamente.
CLAUDE.md deja de ser un archivo de preferencias personales en el momento en que más de una persona en un equipo trabaja realmente contra la misma base de código con Claude Code. Trata los cambios a este archivo con la misma disciplina de revisión que aplicarías a cualquier configuración compartida que afecte el flujo de trabajo de todo el equipo. Un compañero que añade una instrucción aislada de "hotfix" después de una sola sesión frustrante, sin revisión, es exactamente el mecanismo que produce los archivos inflados y auto-contradictorios que dejan de seguirse de forma confiable. Un paso de revisión ligero, incluso solo una segunda persona que eche un vistazo al diff antes de que se fusione, atrapa una parte significativa de esto antes de que se acumule en un problema real.
La disciplina de verificación importa incluso más a escala de equipo que para un usuario individual. Cuando una persona escribe y revisa su propio trabajo asistido por agentes, al menos existe la posibilidad de que atrape 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 ya no es opcional: es el mecanismo real que protege la base de código de que la auto-evaluación confiada pero equivocada de un agente llegue a producción, porque la alternativa es confiar en que algún humano, en algún punto del ajetreado flujo de trabajo de un equipo, atrape lo que el agente no señaló.
También vale la pena establecer una propiedad explícita sobre auditorías periódicas del CLAUDE.md, la misma disciplina de mantenimiento recomendada para cualquier documento compartido y acumulativo. Sin un dueño claramente asignado, este trabajo tiende a quedar en el olvido precisamente porque no bloquea ninguna tarea inmediata individual como lo hace un build roto, 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 malas lecturas específicas de las ideas anteriores aparecen repetidamente; vale la pena nombrarlas directamente, ya que cada una tiene una corrección simple y específica.
Tratar "loops sobre prompts" como licencia para saltarse por completo el entendimiento de la tarea. La propia declaración de Cherny es que su trabajo es escribir loops, no que dejó 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 — todavía requiere entender el problema con la misma claridad que lo haría escribir un buen prompt único. El loop reemplaza el tecleo manual repetido, no el pensamiento inicial.
Leer la reducción del prompt del sistema como "dale al modelo menos contexto, siempre." El contraejemplo de Opus 5 al principio de este artículo existe específicamente para corregir esta mala lectura. La lección real es que el volumen de instrucciones debe coincidir con lo que un modelo específico necesita genuinamente para ejercer 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 indiscriminadamente porque "los modelos más nuevos necesitan menos" aplica mal un hallazgo matizado y específico de un modelo como regla general.
Sobre-descomponer tareas simples en subagentes por hábito. 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 un default 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 la capacidad mejore. Es un hecho estructural sobre la auto-evaluación: a un modelo que revisa su propio trabajo en el mismo contexto que lo produjo siempre le costará más atrapar sus propios puntos ciegos que a una verificación independiente, sin importar cuán capaz se vuelva el modelo subyacente. Esto también es cierto para los revisores humanos, y no deja de ser verdad solo porque el revisor se vuelva más inteligente.
Los Hábitos Diarios Que Vale La Pena Adoptar
Consolidando todo lo anterior en una práctica diaria concreta y aplicable, esto es lo que realmente significa seguir el enfoque demostrado de Cherny.
Deja de tratar cada tarea como un solo prompt que hay que acertar al primer intento. Diseña un loop en su lugar: un agente que intente la tarea, una forma de verificar si el intento tuvo éxito, y un camino definido para lo que sucede después según esa verificación: pasar, reintentar o escalar directamente a ti.
Mantén tu CLAUDE.md corto y trátalo como material de incorporación para un empleado nuevo 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 trabajo genuinamente complejo de múltiples archivos, y confía en la planificación predeterminada del modelo en tareas más simples y bien delimitadas, en lugar de forzar un paso extra en todos lados por hábito.
Descompón tareas grandes en subagentes que trabajen en contextos separados, en lugar de intentar sostener toda una tarea compleja en una sola conversación continua. Usa una pasada separada para verificar trabajo significativo, en lugar de confiar en la auto-evaluación de un solo agente.
Opta por la herramienta más simple que plausiblemente pueda resolver tu problema específico, igual que grep venció a la búsqueda vectorial en este caso de uso exacto, y recurre a más complejidad solo una vez que la opción simple haya sido probada y haya quedado corta.
Construye paralelismo real en tu flujo de trabajo usando git worktrees para piezas de trabajo genuinamente independientes, en lugar de ejecutar todo a través de una sola sesión secuencial porque esa es la forma predeterminada de trabajar.
Hacia Dónde Se Dirige Esto Realmente
El marco de Cherny de "solo estamos al 1%" merece tomarse en serio como una declaración práctica, no solo como una frase que suena humilde. Los patrones específicos descritos arriba — diseño de loops en lugar de prompts individuales, poda agresiva del prompt del sistema a medida que los modelos se vuelven 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 vale la pena construir no es memorizar la configuración específica de mejores prácticas de hoy. Es entender los principios subyacentes lo suficientemente bien como para seguir adaptándote a medida que la herramienta misma sigue cambiando, de la misma manera que el equipo de Cherny reconstruyó Claude Code repetidamente usando Claude Code, refinando el loop en lugar de tratar cualquier versión única como terminada.
Ese es el hilo conductor real que conecta todo en este artículo. No una lista estática de tips, sino una filosofía de trabajo: diseñar sistemas en lugar de teclear instrucciones individuales, mantener las instrucciones ágiles y dejar que la capacidad del modelo haga más del trabajo a medida que mejora, verificar de forma independiente en lugar de confiar en la auto-evaluación, y optar por la simplicidad hasta que la complejidad demuestre que es necesaria. Directamente desde cómo la persona que construyó la herramienta la usa realmente.
Sigue a @cyrilXBT para más desgloses de Claude Code basados en material verificado y registrado.
