Cómo el creador de Claude Code lo usa a diario

Cómo el creador de Claude Code lo usa a diario

Boris Cherny no ha escrito manualmente una sola línea de código desde noviembre de 2025.

Deja que eso cale un momento. La persona que construyó Claude Code — que diseñó la herramienta que cientos de miles de desarrolladores usan ahora a diario — dejó de escribir código a mano hace más de cuatro meses. Y su rendimiento no bajó. Se aceleró. Envía entre 10 y 30 pull requests todos los días, ejecuta hasta 15 sesiones de Claude Code en paralelo entre su terminal y navegador, y ocasionalmente lanza sesiones de programación desde su teléfono antes de dormir para revisar el trabajo terminado con el café de la mañana.

Cuando escuché esto por primera vez en su aparición en el podcast de Lenny, mi reacción fue de escepticismo. ¿Treinta PRs al día? ¿De alguien que no escribe código? Eso suena a un alarde de LinkedIn disfrazado de gurú de productividad.

Entonces estudié su flujo de trabajo real. Y lo que me sorprendió no fue el volumen — fue la simplicidad. El sistema de Boris es casi agresivamente mínimo. Sin bibliotecas de prompts complejas. Sin scaffolding elaborado. Sin archivos de instrucciones de veinte páginas. Toda su configuración de CLAUDE.md tiene aproximadamente 100 líneas. Unos 2.500 tokens. Eso es todo.

La brecha entre mi productividad con Claude Code y la suya no se debía a alguna técnica secreta que no había descubierto. Se debía a seis principios que había estado ignorando, sobrecomplicando o haciendo al revés. Después de pasar las últimas dos semanas reestructurando mi propio flujo de trabajo siguiendo su enfoque, puedo decirte — los resultados son reales. Mi tiempo de depuración se redujo aproximadamente a la mitad. Mis sesiones producen resultados utilizables en el primer intento unas 3 veces más a menudo. Y finalmente dejé ese ciclo enloquecedor en el que Claude construye con confianza algo equivocado mientras yo observo, demasiado hundido en costos irrecuperables para interrumpir.

Aquí tienes el desglose completo de lo que Boris Cherny realmente hace — y más importante, por qué cada pieza importa más de lo que parece.

"Ve despacio para ir rápido" — Por qué el 80% de las sesiones comienzan en plan mode

Esto fue lo primero que cambió mi forma de trabajar, y honestamente, es el principio al que más tiempo me resistí.

Antes abría Claude Code y empezaba a hacer prompts inmediatamente. Describir la funcionalidad. Ver aparecer el código. Sentirme productivo. Excepto que no era productivo — estaba ocupado. Hay una diferencia crítica, y Boris la clava en una sola observación: la IA resuelve problemas rápido, pero no necesariamente los problemas correctos. Sin una planificación clara, Claude correrá con confianza en la dirección equivocada y construirá algo técnicamente impresionante que falla completamente en el objetivo real.

Boris comienza aproximadamente el 80% de sus sesiones en plan mode. Si no estás familiarizado, plan mode (activado presionando Shift+Tab dos veces en Claude Code) le dice a la IA que piense y analice sin escribir código ni ejecutar comandos. Lee archivos, hace preguntas, propone enfoques — pero no toca nada hasta que apruebes explícitamente el plan.

La técnica específica que Boris usa es lo que él llama el "prompt de entrevista". Antes de que se genere cualquier código, le pregunta a Claude algo así:

Interview me about this. What core problems does this solve?
Who is this for? What does success look like? What should this
NOT do? Summarize it back to me before writing any code.

Ese prompt cambió todo mi flujo de trabajo. Esta es la razón por la que es más poderoso de lo que parece.

Cuando lo probé por primera vez, Claude me hizo cinco preguntas de clarificación sobre una funcionalidad que pensé que había descrito con claridad. Dos de esas preguntas revelaron suposiciones que había hecho y que eran completamente erróneas. Una de ellas — "¿Esto debería modificar el registro de usuario existente o crear una nueva entrada en el registro de actividad?" — habría llevado a un error de arquitectura de base de datos que podría haber costado horas desenredar si Claude simplemente hubiera empezado a construir.

Boris compartió un ejemplo específico que se me quedó grabado: la corrección de un bug para un cliente donde Claude, sin planificación, fue directamente a modificar valores de la base de datos en lugar de arreglar la lógica de visualización de la UI. La "corrección" técnicamente resolvió el síntoma reportado pero rompió tres otras funcionalidades que dependían de esos valores de la base de datos. El tipo de bug que pasa una prueba manual rápida y luego explota en producción dos días después.

Plan mode lo habría detectado en sesenta segundos. La entrevista habría revelado que el problema era solo de visualización. Claude habría propuesto una corrección en la capa de UI. Sin cambios en la base de datos. Sin cascada de roturas.

Llevo dos semanas usando este enfoque de entrevista primero, y el patrón es consistente: aproximadamente 4-5 minutos de planificación ahorran 20-40 minutos de retrabajo. Las cuentas no dejan lugar a dudas.

Un detalle fácil de pasar por alto — plan mode también es significativamente más rápido y económico por interacción. Como Claude no ejecuta herramientas, no escribe archivos ni ejecuta comandos durante la planificación, las respuestas llegan a la velocidad del rayo y consumen menos tokens. Básicamente obtienes el mejor pensamiento de la IA con descuento antes de comprometerte con la costosa fase de ejecución.

Después de que Claude presenta su plan, Boris lo revisa, a veces lo edita directamente usando Ctrl+G (que abre el plan en tu editor de texto), y solo entonces cambia al modo de aceptación automática para que Claude ejecute. En la mayoría de los casos, dice, Claude implementa todo correctamente en un solo intento después de una buena sesión de planificación. Un intento. Sin iteraciones. Sin correcciones de "eso está cerca pero en realidad me refería a...".

Solo eso ya justifica el esfuerzo de planificación. Pero el siguiente principio es lo que hace que la planificación persista entre sesiones.

La CLAUDE.md de 100 líneas — Por qué menos contexto supera a más

Aquí es donde el enfoque de Boris contradecía directamente lo que yo había estado haciendo durante meses.

Tenía un archivo CLAUDE.md que se acercaba a las 500 líneas. Documentación arquitectónica detallada. Estándares de codificación con ejemplos. Contexto histórico sobre por qué se tomaron ciertas decisiones. Bibliotecas de patrones. Se sentía exhaustivo. Profesional. Como un documento de ingeniería apropiado.

También estaba consumiendo silenciosamente el 30% de mi ventana de contexto disponible en cada solicitud. Cada vez que le hacía una pregunta a Claude — incluso una simple — esas 500 líneas se cargaban primero. Tokens gastados antes de que el trabajo real siquiera comenzara.

La CLAUDE.md de Boris tiene aproximadamente 100 líneas. Alrededor de 2.500 tokens. Y supera a cualquier archivo de instrucciones inflado que haya construido jamás.

Su filosofía es casi zen en su moderación: el archivo solo debería contener reglas que corrijan errores recurrentes. Sin documentación. Sin explicaciones de arquitectura. Sin estándares de codificación que Claude ya conoce por sus datos de entrenamiento. Solo correcciones. Barandillas. Las cosas específicas que Claude hace mal en tu proyecto que no sabría sin que se le diga.

El proceso es reactivo, no proactivo. Boris y su equipo en Anthropic siguen una regla simple: "Cada vez que vemos a Claude hacer algo incorrectamente, lo añadimos a CLAUDE.md para que no se repita la próxima vez." El archivo está registrado en git, se comparte con todo el equipo y se actualiza varias veces por semana. Pero también se eliminan cosas. A medida que los modelos mejoran, reglas que eran necesarias hace seis meses se vuelven redundantes. Claude las aprendió por su cuenta.

Esto conecta con algo que cubrí en mi guía de 50 consejos para Claude Code — tu CLAUDE.md es tu superpoder o tu cuello de botella, y la línea divisoria es la longitud. Pero Boris va más allá de lo que yo hice. No solo recomienda mantenerlo corto. Recomienda borrarlo y recrearlo desde cero cuando se infle o se vuelva contradictorio, en lugar de intentar limpiarlo quirúrgicamente.

El razonamiento: las instrucciones acumuladas desarrollan contradicciones internas con el tiempo. La Regla 7 dice "siempre usa async/await" pero la Regla 43 dice "usa callbacks para operaciones de base de datos." Un humano leyendo el archivo podría detectar el conflicto. Claude podría no hacerlo — o peor, podría intentar satisfacer ambas simultáneamente, produciendo código híbrido bizarro.

Empezar de cero elimina las contradicciones, las instrucciones duplicadas y las reglas escritas para capacidades del modelo que ya no aplican. Es el enfoque Marie Kondo de la configuración de IA: si una regla no corrige un problema actualmente activo, no debería estar en el archivo.

Lo probé la semana pasada. Borré mi CLAUDE.md de 500 líneas y la reconstruí desde cero con solo las reglas que podía justificar de las últimas dos semanas de uso. Terminé con 87 líneas. Mi consumo de tokens bajó notablemente, y — aquí está la parte que no esperaba — la calidad del código de Claude realmente mejoró. Menos contexto contradictorio significó un output más coherente.

Hay un detalle estructural que vale la pena mencionar. Boris aprovecha la jerarquía de CLAUDE.md: un archivo a nivel raíz para reglas de todo el proyecto y archivos a nivel de directorio para contexto específico de subsistemas. Tu directorio /api obtiene sus propias reglas enfocadas sin inflar el archivo raíz. Esto es algo que yo también uso intensivamente, y escala magníficamente en monorepos.

Si estás ahí sentado con una CLAUDE.md que ha crecido más allá de las 200 líneas, recomiendo encarecidamente la opción nuclear de Boris. Bórrala. Reconstruye solo desde puntos de dolor recientes. El archivo con el que termines será más pequeño y mejor.

Bucles de verificación — El multiplicador de calidad 2-3x que nadie usa

Este es el principio que, honestamente, me hizo sentir un poco tonto por no haberlo implementado antes.

La afirmación de Boris es específica: darle a Claude la capacidad de verificar su propio trabajo mejora la calidad del output en 2-3x. No "un poco mejor." No "algo más confiable." Dos a tres veces mejor. Y después de implementar su enfoque, creo que el número es preciso.

El concepto es directo. La mayoría de personas usan Claude Code en un ciclo de generar-y-revisar: Claude escribe código, tú lo lees, detectas problemas, pides correcciones. Esto funciona, pero pone toda la carga de calidad sobre ti. Tú eres la capa de verificación. Y eres humano, lo que significa que se te escapan cosas — especialmente durante sesiones largas cuando la atención decae.

El enfoque de Boris invierte esto. Le da a Claude las herramientas e instrucciones para verificar su propio output antes de presentarlo como terminado. Dos pasos:

1. Dale a Claude un método para verificar su trabajo (una suite de tests, una vista previa del navegador, un comando de linting, un verificador de tipos)
2. Dile a Claude explícitamente sobre ese método (en CLAUDE.md o en el prompt)

La implementación práctica varía según lo que estés construyendo. Para una aplicación web, podría significar decirle a Claude: "Después de hacer cambios, ejecuta la suite de tests y abre el navegador para confirmar visualmente que la UI coincide con el requisito." Para un endpoint de API: "Después de implementar, ejecuta la prueba de integración y confirma que la forma de la respuesta coincide con el esquema." Para generación de contenido: "Después de escribir, revisa contra el documento de guías de marca en /docs/style-guide.md."

Boris va un paso más allá — añade prompts de verificación directamente a su archivo CLAUDE.md. Algo como:

Before marking any task as complete, propose a verification plan.
Describe what you'll check and how you'll confirm correctness.
Then execute that plan.

Esta única regla, añadida a tu archivo de instrucciones, obliga a Claude a pensar en la verificación antes de empezar a construir. Y cambia el output dramáticamente. Claude empieza a sugerir casos de prueba en los que no habías pensado. Detecta casos límite durante la implementación en lugar de después. Ejecuta verificaciones de tipos y linters proactivamente en lugar de esperar a que tú lo pidas.

Añadí esta regla a mi propio CLAUDE.md hace ocho días. En ese tiempo, he tenido exactamente dos instancias donde Claude envió código con un bug que no detecté durante la revisión. En los ocho días antes de añadir la regla, el número estaba más cerca de nueve o diez. Muestra pequeña, claro. Pero el cambio direccional es inconfundible.

La perspectiva clave aquí es que Claude no carece de la capacidad de verificar — carece de la instrucción de verificar. Dejado a sus valores predeterminados, Claude optimiza para velocidad y completitud. Quiere darte una respuesta. La verificación ralentiza eso, así que la salta a menos que la construyas explícitamente en el flujo de trabajo. La genialidad de Boris es reconocer que una línea en CLAUDE.md desbloquea una capacidad que siempre estuvo ahí pero inactiva.

Esto conecta con algo más amplio sobre cómo pienso acerca de las skills de agente de Claude Code — las mejores configuraciones no añaden nuevas capacidades a la IA. Activan capacidades que la IA ya tiene pero no usa por defecto. La verificación es el ejemplo más impactante de ese patrón.

Multiplícate — Sesiones paralelas que realmente funcionan

Boris ejecuta 5 instancias de Claude Code localmente en su terminal y otras 5-10 en el sitio web de Anthropic. Simultáneamente. En diferentes tareas.

Cuando escuché esto por primera vez, mi reacción fue "eso suena caótico." ¿Múltiples sesiones de IA trabajando en la misma base de código? Eso es una receta para conflictos de merge, cambios contradictorios y código que no se integra.

Excepto que Boris no las ejecuta en la misma tarea. Cada sesión recibe una pieza de trabajo distinta e independiente. Una podría estar construyendo un nuevo endpoint de API. Otra está escribiendo tests para una funcionalidad existente. Una tercera está refactorizando un módulo de utilidades. Una cuarta está investigando un reporte de bug. Nunca se superponen. Nunca tocan los mismos archivos. Se ejecutan en paralelo porque pueden — el trabajo está naturalmente particionado.

El truco que hace que esto funcione a nivel práctico: cada sesión local usa su propio git checkout en lugar de branches o worktrees dentro del mismo repositorio. Esto elimina los conflictos del sistema de archivos por completo. Cada instancia de Claude piensa que está trabajando en un proyecto independiente. Sin archivos de bloqueo peleando entre sí. Sin cambios a medio escribir en directorios compartidos.

Para sesiones remotas, Boris las inicia con & desde la CLI y a veces usa --teleport para mover sesiones entre su terminal y la interfaz del navegador. Lanza una sesión antes de dormir, y estará esperando con un pull request completado cuando revise por la mañana.

He escalado a ejecutar tres sesiones paralelas — mi hardware y capacidad de atención aún no están al nivel de Boris — y aun en esa escala modesta, la diferencia de productividad es significativa. Tres tareas independientes que me tomarían 45 minutos cada una en serie se completan en aproximadamente 50-55 minutos en total. No es paralelismo perfecto, pero es lo suficientemente cercano como para cambiar fundamentalmente cómo planifico mi jornada laboral.

Hay un beneficio más sutil que Boris menciona y que he confirmado por experiencia: las sesiones frescas traen perspectivas frescas. Cuando estás profundamente metido en una sesión que ha estado trabajando en un problema durante 30 minutos, la ventana de contexto está llena de las suposiciones y los enfoques fallidos previos de ese problema. Iniciar una segunda sesión para mirar el mismo problema — pero desde cero — a veces produce una mejor solución en menos de cinco minutos porque no carga con el equipaje de intentos anteriores.

Ahora hago esto rutinariamente con bugs difíciles. Si mi primera sesión no lo ha resuelto en 15 minutos, abro una sesión fresca con una descripción limpia del problema. La sesión fresca lo resuelve aproximadamente la mitad de las veces. No porque sea más inteligente — porque no tiene lastre.

Para cualquiera interesado en el enfoque de git worktree para sesiones paralelas de Claude, escribí sobre esto con más detalle en mi guía de Claude Code git worktrees agentes paralelos. La versión corta: los worktrees te dan directorios de trabajo aislados desde un solo repositorio, lo que es ligeramente más eficiente que clones completos pero logra el mismo objetivo que Boris describe.

Sistematiza los bucles internos — Slash commands como memoria muscular

Aquí es donde el flujo de trabajo de Boris pasa de "individuo productivo" a "sistema de producción."

Todo desarrollador tiene bucles internos — las tareas que repites varias veces al día. Ejecutar tests. Generar boilerplate. Crear pull requests. Formatear revisiones de código. Escribir mensajes de commit. Actualizar documentación. Estas tareas no son complejas individualmente, pero se acumulan. Si gastas 3 minutos en cada una y haces veinte al día, eso es una hora de trabajo repetitivo.

Boris automatiza estos con slash commands y skills de Claude Code. No ocasionalmente. Obsesivamente. Cada flujo de trabajo que hace más de dos veces se convierte en un comando.

La analogía que usa es perfecta: los prompts regulares son como decirle a un jugador de baloncesto "dribla el balón por la cancha, busca un compañero libre y pasa si ves uno." Los slash commands son jugadas específicas — secuencias precisas ejecutadas de la misma manera cada vez. "Pick and roll desde el ala izquierda." Sin ambigüedad. Sin variación. Solo ejecución.

En Claude Code, los slash commands viven en .claude/commands/ como archivos markdown. Cada archivo describe un flujo de trabajo específico. Cuando escribes /mi-comando, Claude lee el archivo y ejecuta ese flujo de trabajo. Sin re-explicar. Sin preámbulo de "esto es lo que necesito que hagas...". Solo el disparador y el resultado.

El verdadero movimiento de poder de Boris es pedirle a Claude mismo que sugiera qué comandos debería crear:

Based on this project, what Claude skills should I create?
Look at my recent git history, my CLAUDE.md, and the types
of changes I make most frequently. Suggest 5-7 slash commands
that would automate my most common workflows.

Ejecuté este prompt en uno de mis proyectos y Claude sugirió siete comandos. Cinco de ellos eran flujos de trabajo que hacía manualmente todos los días. Dos eran flujos de trabajo que ni siquiera había pensado en automatizar porque involucraban múltiples pasos a través de diferentes herramientas. Construí los siete, y el ahorro de tiempo se acumula diariamente.

La diferencia clave entre un slash command y un prompt guardado es la durabilidad. Los prompts viven en tu portapapeles o un archivo de notas. Se pierden, se editan inconsistentemente y se olvidan. Los slash commands viven en tu repositorio. Están versionados. Se comparten con tu equipo vía git. Cuando mejoras un flujo de trabajo, todos obtienen la mejora en su próximo git pull.

Las skills van un paso más allá — no son solo comandos que tú disparas, sino capacidades que Claude puede invocar autónomamente durante el razonamiento. Una skill con el frontmatter YAML correcto se activa automáticamente cuando Claude encuentra una situación relevante. "Cuando el usuario pide un informe de estado, usa este flujo de trabajo." "Cuando generes un endpoint de API, sigue esta plantilla." Es la diferencia entre tener un libro de recetas y tener un chef que ya conoce todas las recetas.

Para profundizar en la creación de Claude Skills efectivas, mi guía de Claude Skills cubre la estructura YAML, los cinco patrones que realmente importan, y los errores que cometí durante mi primera semana construyéndolas. El enfoque de Boris confirma lo que descubrí independientemente: empieza con los flujos de trabajo que más repites, automatiza esos primero, y deja que la complejidad crezca orgánicamente.

Construye para el futuro — La lección amarga aplicada a tu flujo de trabajo

Este es el principio que une todo lo demás, y es el más filosófico de las seis estrategias de Boris. Pero no lo saltes — es el que te salvará de una trampa en la que he visto caer a decenas de desarrolladores.

Boris hace referencia al famoso ensayo de Rich Sutton de 2019, "The Bitter Lesson", que argumenta que en la historia de la investigación en IA, los métodos generales que aprovechan la computación siempre han terminado superando a los enfoques basados en conocimiento específico de dominio diseñado por humanos. Cada vez que los investigadores intentaron codificar inteligencia manualmente — libros de aperturas de ajedrez, reglas de reconocimiento de voz, gramáticas de traducción — fueron finalmente vencidos por sistemas que simplemente aprendieron de cantidades masivas de datos.

Boris aplica esto a los flujos de trabajo de Claude Code: no sobreingenierices tus prompts o scaffolding. El modelo está mejorando rápidamente. ¿Esa cadena de prompts elaborada en la que pasaste tres días perfeccionando? En seis meses, una simple instrucción de una frase producirá mejores resultados porque el modelo mejoró tanto.

Lo he visto de primera mano. Técnicas que documenté a principios de 2025 para lograr que Claude produjera TypeScript limpio — instrucciones de formato específicas, patrones de ejemplo, anotaciones de tipo explícitas en el prompt — ahora son innecesarias. Claude genera TypeScript limpio por defecto. Las horas que pasé en esos prompts fueron esfuerzo desperdiciado, invertido en infraestructura que las mejoras del modelo hicieron obsoleta.

El consejo práctico de Boris: concéntrate en alimentar al modelo con datos y contexto de calidad en lugar de optimizar la ingeniería de prompts. Tu tiempo está mejor invertido en una base de código bien estructurada con convenciones de nomenclatura claras, tests exhaustivos y buena documentación que en perfeccionar el mega-prompt de diecisiete pasos que obliga a Claude a escribir código de la manera que quieres. Porque Claude aprenderá a escribir código de la manera que quieres. Tu trabajo es asegurarte de que tenga el contexto correcto — no las restricciones correctas.

Esto conecta de vuelta con la filosofía de la CLAUDE.md mínima. Un archivo de instrucciones de 500 líneas es sobreingeniería para las limitaciones del modelo actual. Un archivo de 100 líneas enfocado en correcciones específicas del proyecto seguirá siendo relevante incluso cuando el modelo mejore, porque enseña a Claude cosas que genuinamente no puede saber sin que se le digan — las convenciones de tu equipo, las peculiaridades de tu proyecto, los requisitos específicos de tu dominio de negocio.

Boris lo enmarca como una pregunta de dónde invertir tu hora marginal. Podrías gastarla en:

• Opción A: Refinar un prompt hasta que Claude genere código ligeramente mejor ahora mismo
• Opción B: Mejorar tu base de código, tu cobertura de tests o tu CLAUDE.md con una corrección que rendirá durante meses

La Opción B gana siempre. Y gana por un margen más amplio con cada actualización del modelo, porque cuanto mejor se vuelve el modelo, menos importa la ingeniería de prompts y más importa la calidad del contexto.

He reestructurado mi propio enfoque en consecuencia. Cuando me encuentro ajustando un prompt por tercera vez, me detengo y pregunto: "¿Es esto un problema de prompt o un problema de contexto?" Casi siempre es contexto. La base de código es ambigua. La suite de tests no cubre el caso límite. La CLAUDE.md carece de una convención crítica del proyecto. Arregla el contexto, y el prompt puede quedarse simple.

Lo que cambió en mi propio flujo de trabajo

Después de dos semanas implementando los seis principios de Boris, esto es lo que cambió.

Mis sesiones son más cortas. No porque hago menos — porque la fase de planificación elimina los falsos comienzos que antes consumían el 30-40% de mi tiempo de sesión. Antes pasaba 90 minutos en una funcionalidad con 30 minutos siendo "no, eso no es lo que quise decir, déjame re-explicar." Ahora el prompt de entrevista detecta la desalineación en los primeros cinco minutos.

Mi CLAUDE.md tiene 87 líneas. Bajó de casi 500. Y mi calidad de output fue hacia arriba, no hacia abajo. Menos instrucciones, menos confusión, código más coherente. Lo reviso semanalmente y me hago dos preguntas: "¿Ha cometido Claude este error recientemente?" y "¿Cometería Claude este error sin esta regla?" Si la respuesta a cualquiera es no, la regla se elimina.

Ejecuto tres sesiones paralelas diariamente. Una para la funcionalidad principal que estoy construyendo. Una para tests y documentación. Una para investigación de bugs o refactorización. No interfieren entre sí. No comparten contexto. Y el rendimiento combinado es aproximadamente 2.5x lo que hacía en serie.

Cada flujo de trabajo que he repetido tres veces es ahora un slash command. Tengo catorce distribuidos entre mis proyectos principales. El ahorro de tiempo se siente pequeño individualmente — quizás 2-3 minutos cada uno — pero con veinte invocaciones al día, eso es casi una hora recuperada. Una hora que dedico al trabajo que realmente requiere juicio, no ejecución.

Y dejé de optimizar prompts. Cuando Claude produce output malo, arreglo el contexto: actualizo CLAUDE.md, mejoro la base de código, añado un test faltante. No he escrito un "mejor prompt" en diez días. He escrito mejor código. Y el output de la IA mejoró como resultado.

La implicación incómoda

Hay algo en el enfoque de Boris que vale la pena reflexionar — algo que la mayoría de creadores de contenido sobre Claude Code (yo incluido) tendemos a esquivar.

Los seis principios de arriba no son complejos. Planifica antes de construir. Mantén las instrucciones mínimas. Deja que la IA verifique su propio trabajo. Ejecuta tareas en paralelo. Automatiza flujos de trabajo repetitivos. Apuesta a que el modelo mejorará.

Nada de esto requiere sofisticación técnica. Un desarrollador junior puede implementar los seis en el primer día. La barrera no es el conocimiento — es el ego. Planificar se siente lento cuando quieres empezar a construir. Borrar tu CLAUDE.md de 500 líneas cuidadosamente elaborada se siente como tirar trabajo a la basura. Confiar en que Claude verifique su propio output se siente como ceder el control. Ejecutar sesiones paralelas se siente como perder el hilo.

Los resultados de Boris sugieren que los desarrolladores que prosperarán con la programación asistida por IA no son los que tienen los prompts más ingeniosos. Son los que están dispuestos a cambiar cómo piensan sobre el trabajo en sí. A tratar la IA no como una máquina de escribir más rápida sino como un colaborador que necesita dirección clara, contexto limpio y la autonomía para verificar su propio trabajo.

La persona que construyó la herramienta nos está diciendo exactamente cómo usarla. Y su consejo no es "usa más funciones" o "escribe mejores prompts." Su consejo es: planifica más, configura menos, verifica todo, y confía en que la herramienta seguirá mejorando.

Llevo dos semanas con este enfoque. Mi output subió. Mi frustración bajó. Y por primera vez desde que empecé a usar Claude Code, siento que estoy trabajando con la herramienta en lugar de forzándola a someterse.

Si pruebas una sola cosa de este artículo hoy, que sea el prompt de entrevista. Abre tu próxima sesión de Claude Code en plan mode y pega esto antes de cualquier otra cosa:

Interview me about this. What core problems does this solve?
Who is this for? What does success look like? What should this
NOT do? Summarize it back to me before writing any code.

Responde las preguntas de Claude honestamente. Observa cómo te resume tu intención. Detecta la desalineación antes de que exista una sola línea de código. Y luego dime que esos cinco minutos no valieron la pena.

Preguntas frecuentes

¿Quién es Boris Cherny y cuál es su rol en Anthropic?

Boris Cherny es el creador y jefe de Claude Code en Anthropic. Construyó el prototipo original basado en terminal y ahora lidera el equipo que lo desarrolla. Envía 10-30 pull requests diarios sin escribir código manualmente, usando su propia herramienta para todo el trabajo de desarrollo. Para contexto sobre la herramienta en sí, consulta mi tutorial de Claude Code para principiantes.

¿Cómo activo plan mode en Claude Code?

Presiona Shift+Tab dos veces en la terminal de Claude Code para activar plan mode. Claude entonces analizará archivos y propondrá enfoques sin escribir código ni ejecutar comandos. También puedes usar el comando /plan en Claude Code v2.1.0 o posterior. Consulta "Ve despacio para ir rápido" arriba para el flujo de trabajo completo.

¿Qué tan largo debería ser mi archivo CLAUDE.md?

Boris Cherny mantiene el suyo en aproximadamente 100 líneas (unos 2.500 tokens). El archivo solo debería contener reglas que corrijan errores recurrentes — sin documentación, explicaciones de arquitectura o estándares de codificación que Claude ya conoce. Elimina reglas que no hayan sido relevantes en las últimas dos semanas. Para un desglose completo, consulta mi guía de 50 consejos para Claude Code.

¿Puedo ejecutar múltiples sesiones de Claude Code al mismo tiempo?

Sí. Boris ejecuta 5 sesiones localmente y 5-10 en el navegador simultáneamente. La clave es dar a cada sesión trabajo independiente en checkouts de git separados para evitar conflictos de archivos. Inicia sesiones remotas con & desde la CLI y usa --teleport para mover sesiones entre terminal y navegador.

¿Qué son los slash commands de Claude Code y cómo los creo?

Los slash commands son plantillas de flujo de trabajo reutilizables almacenadas como archivos markdown en .claude/commands/. Escribe /nombre-del-comando para activarlos. Crea uno escribiendo un archivo markdown que describa los pasos del flujo de trabajo y guárdalo en el directorio de commands. Pregúntale a Claude: "¿Qué slash commands debería crear para este proyecto?" para empezar.

Trabajemos juntos

¿Quieres construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (desarrollos personalizados e integraciones): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io