Las 6 estrategias del creador de Claude Code para tus proyectos

El que la hizo, la usa distinto

Llevamos meses todos haciendo lo mismo con Claude Code: afinar prompts, acumular reglas, ajustar cada parámetro. Y resulta que Boris Cherney, el hombre que creó la herramienta, la usa de una forma bastante distinta a la del montón. En una entrevista soltó las seis estrategias que aplica él, y al leerlas te das cuenta de que muchos lo estábamos haciendo regular.

Te las cuento una a una, con cómo aplicarlas hoy. No son trucos sueltos: juntas forman una manera de trabajar. Vamos.

1. Empieza en plan mode, no en build mode

La primera, y de las más importantes: el 80% de los proyectos de Boris empiezan en modo plan, no en modo construcción. Es decir, antes de escribir una sola línea, Claude propone un plan y tú lo afinas hasta que de verdad ataca el problema que quieres resolver.

¿Por qué importa tanto? Porque sin plan, el agente se lanza a “arreglar” lo primero que cree, se va por las ramas, toca cosas que no tocaba y a veces da el problema por resuelto cuando no lo era. Empezar planeando te ahorra tokens, dinero y, sobre todo, tiempo. Boris lo resume genial: “mover despacio para mover rápido”. Todo el pensamiento ocurre antes; luego la ejecución es casi automática.

Truco práctico: en modo plan, dile algo como “antes de construir, entrevístame: ¿qué problema resuelve esto?, ¿para quién es?, ¿qué NO debe hacer?”. Claude te hará preguntas sobre cosas que antes daba por supuestas, y el plan saldrá mucho mejor.

2. Un CLAUDE.md minimalista

La segunda va contra la intuición de casi todos. El CLAUDE.md es el archivo de instrucciones que Claude lee al empezar cada sesión: quién es, qué hace, las reglas del proyecto. Y la tentación es meterle de todo. Error.

Boris hace lo contrario: lo mantiene lo más corto posible. Y si se le infla, lo borra y empieza de cero. Suena radical, pero tiene lógica: un CLAUDE.md de 5.000 tokens lleno de reglas viejas, duplicadas o contradictorias distrae al modelo, que no sabe qué priorizar. Aquí no aplica el “cuanto más contexto, mejor”: al revés, cuanto más ajustado al mínimo necesario, más determinista y fiable.

Yo no lo borro entero, que me da vértigo, pero uso un comando que funciona igual de bien: cada cierto tiempo le pido “actualiza el CLAUDE.md eliminando todo lo que ya no sea necesario, sea contradictorio o sea relleno que reste eficacia”. Pruébalo: verás cómo se queda en la mitad y funciona igual o mejor.

3. Dale una forma de verificar su trabajo

La tercera es, para mí, la más infravalorada. Boris tiene una frase que se me quedó grabada: dale a Claude una forma de verificar su propio trabajo, y multiplicarás por dos o tres la calidad del resultado. No un 10% más. Dos o tres veces. Lo dice el que creó la herramienta.

La idea es montarle un bucle de feedback: que Claude no solo haga la tarea, sino que pueda comprobar si le ha salido bien y corregir. En la práctica, dos pasos: darle una herramienta para ver el resultado de su trabajo, y decirle que la tiene disponible. Para una web, que pueda abrir un navegador y comprobar lo que construyó. Para una automatización, que ejecute el flujo y verifique el output. Para contenido, un documento con tu guía de marca contra el que contrastar.

Esto enlaza de lleno con lo que conté en harness engineering: el entorno y los bucles de verificación importan tanto como el modelo. El truco más potente: añade al CLAUDE.md cómo se verifica el trabajo en ese proyecto, para que el plan de verificación exista desde el principio.

4. Multiplícate: varias sesiones en paralelo

La cuarta sorprende. Boris trabaja con varias sesiones de Claude en paralelo, cada una en una tarea distinta. La clave es que las tareas no se solapen: dos sesiones tocando los mismos archivos es un caos, pero dos sesiones en cosas distintas multiplican lo que produces.

Y hay un beneficio extra precioso: una sesión nueva, sin el contexto acumulado de la anterior, ve el problema desde cero y muchas veces encuentra algo obvio que la primera, demasiado metida en los detalles, no veía. Es como cuando te atascas con algo, llega alguien nuevo y lo resuelve a la primera.

De ahí el pro tip más simple del vídeo: cuando lleves mucho rato atascado en una sesión, abre una nueva y empieza de cero. Es el “apagar y volver a encender” de toda la vida. Nadie sabe muy bien por qué, pero a veces es justo lo que necesitas.

5. Inner loops: encapsula lo que repites

La quinta va de tus bucles internos: esas tareas que haces muchas veces al día (un tipo de informe, revisar código en cierto formato, preparar propuestas, lo que sea). Boris las encapsula con slash commands; yo prefiero las skills, que para mí son más accesibles y potentes, pero la idea es la misma: documentas el proceso una vez y se ejecuta siempre igual, con tu estilo y sin errores.

¿Cómo saber qué encapsular? Hay un prompt buenísimo para esto: “basándote en el proyecto en el que trabajo, ¿qué skills (o comandos) debería crear?”, y Claude te propone según los procesos que repites. Aún mejor: durante dos o tres días, apúntate cada media hora qué has hecho, pásaselo y pídele que identifique todo lo que repites más de dos o tres veces al día y sea automatizable. Con esa lista, dejas de repetir “haz esto así, por favor” para siempre.

6. No apuestes nunca contra el modelo

Y la sexta, la más filosófica y puede que la más importante a largo plazo. En la oficina de Boris hay, literalmente, un cartel que dice “The Bitter Lesson”, por el famoso texto de Rich Sutton: el modelo más general siempre acaba ganando al más específico. Traducido a tu día a día: nunca apuestes en contra del modelo.

¿Qué significa en la práctica? Que cada ajuste hiperespecífico, cada optimización fina de un prompt para arañar un 5%, probablemente será innecesario dentro de seis meses, porque el modelo mejorará y lo hará solo. Así que, en vez de gastar tu tiempo en eso, inviértelo en construir el sistema de información que rodea al modelo: un buen CLAUDE.md, tus skills, tus procesos documentados. Eso sí escala, eso sí dura, y cuanto mejor sea el modelo, mejor funcionará todo lo que ya tienes montado.

Boris lo dice de forma brutal: la Inteligencia Artificial nunca va a ser tan mala como lo es hoy. Siempre irá a mejor. Así que construye para ese futuro, no para pelearte con las limitaciones de hoy.

Lo que me llevo de todo esto

Si juntas las seis, el patrón está clarísimo, y es el mismo que vengo defendiendo: deja de obsesionarte con el prompt perfecto y empieza a construir el entorno. Planea antes de ejecutar, dale el contexto justo (ni más ni menos), móntale forma de verificarse, paraleliza, encapsula lo que repites y apuesta a que el modelo irá a mejor.

Es, en el fondo, dejar de tratar a Claude Code como un genio caprichoso y empezar a tratarlo como un sistema que diseñas tú. Y si quieres montar este tipo de flujos de trabajo con Inteligencia Artificial bien hechos en tu empresa, es justo en lo que puedo ayudarte. Yo llevo aplicando varias de estas desde que las leí, y se nota.

Preguntas frecuentes

¿Por qué conviene empezar en plan mode en Claude Code?

Porque planear antes de ejecutar evita que el agente se lance a “arreglar” lo primero que cree, se vaya por las ramas o dé por resuelto un problema que no lo estaba. Empezar en modo plan, afinando el plan hasta que ataca el problema real, ahorra tokens, dinero y tiempo. Boris Cherney lo resume como “mover despacio para mover rápido”: el pensamiento va delante y la ejecución sale casi automática.

¿Es mejor un CLAUDE.md largo o corto?

Corto. Un CLAUDE.md inflado con reglas viejas, duplicadas o contradictorias distrae al modelo y le impide priorizar. Boris Cherney lo mantiene al mínimo necesario, e incluso lo borra y reescribe si se hincha. La intuición de “cuanto más contexto, mejor” no aplica aquí: cuanto más ajustado, más fiable y determinista es el resultado.

¿Cómo hago que Claude verifique su propio trabajo?

Dándole una forma de comprobar el resultado y diciéndole que la tiene disponible. Por ejemplo, que abra un navegador para revisar una web que ha construido, que ejecute una automatización y verifique su salida, o que contraste un texto contra tu guía de marca. Según Boris Cherney, ese bucle de feedback puede multiplicar por dos o tres la calidad del resultado. Conviene dejar escrito en el CLAUDE.md cómo se verifica en cada proyecto.

¿Qué es 'no apostar contra el modelo'?

Es la idea de que los modelos mejoran constantemente, así que las optimizaciones hiperespecíficas de hoy (afinar un prompt para arañar un poco) suelen quedar obsoletas en meses, porque el modelo acaba haciéndolo solo. En vez de invertir ahí, conviene invertir en el sistema que rodea al modelo (un buen CLAUDE.md, skills, procesos documentados), que sí escala y mejora a medida que el modelo mejora.

Fuentes

Compártelo si te ha resultado útil, sobre todo con quien siga peleándose con el prompt perfecto.

¿Cuál de las seis te ha pillado haciéndolo al revés? A mí, la del CLAUDE.md. Cuéntame.

Y… empieza despacio, que es como se va rápido.