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.
Artículos relacionados
Routines de Claude Code: automatiza sin el ordenador encendido
Anthropic acaba de soltar una función en Claude Code que cambia las reglas de la automatización: las Routines. Hasta ahora, para que un agente hiciera tareas solo y en bucle (revisar correos, montar un resumen diario, vigilar algo) necesitabas una herramienta como n8n y, muchas veces, un ordenador o un servidor encendido. Con las Routines puedes lanzar automatizaciones agénticas programadas o por eventos que corren en la infraestructura de Anthropic, sin tu equipo encendido, con la misma suscripción de Claude que ya pagas. Aquí te cuento qué son, qué puedes hacer con ellas, en qué se diferencian de n8n y por qué esto acerca a Claude Code a competir de tú a tú con las plataformas de automatización de toda la vida.
Harness engineering: por qué el entorno importa más que el modelo
Habrás notado algo raro usando ChatGPT, Claude o Copilot: a veces hacen cosas increíbles y a veces fallan en lo más tonto. Y resulta que gran parte de los saltos de calidad de los últimos tiempos no han venido de modelos más listos, sino de mejores entornos donde esos modelos se ejecutan. A esos entornos se les llama arneses (harness), y a la disciplina de construirlos bien, harness engineering. Aquí te explico qué es un arnés, por qué importa tanto, y cómo dejar de tratar la Inteligencia Artificial como un simple chatbot para empezar a construir sistemas de verdad encima de los modelos. Porque ahora que generar código es fácil y rápido, el problema ya no es escribirlo, es controlar el caballo desbocado que lo genera.
Cómo dejé de chocar con los límites de uso de Claude Code
Vivía chocando con los límites de uso de Claude Code, y ahora lo uso todo el día sin tocarlos en semanas. ¿Qué cambié? Me puse a mirar mi configuración y descubrí que estaba malgastando una barbaridad de tokens en contexto invisible que ni sabía que estaba ahí: archivos enormes que se colaban en cada petición, instrucciones acumuladas, ruido que no aportaba nada pero que se contaba en cada mensaje. Aquí te cuento qué es ese contexto invisible que te come la cuota sin que te enteres, cómo detectarlo y qué ajustes concretos me han permitido estirar muchísimo el uso sin pagar más. Porque muchas veces no necesitas un plan más caro: necesitas dejar de tirar tokens a la basura.