Claude Code: 6 herramientas para que la IA programe sola

Por defecto, Claude Code programa a ciegas

Si usas Claude Code en proyectos reales, ya lo habrás notado: por defecto la IA trabaja con un punto ciego enorme. Se le olvida todo al cerrar la sesión, se pierde en proyectos grandes y funde tokens a una velocidad indecente. No es que sea tonta: es que le falta el sistema alrededor que la dirija.

Llevo meses montando exactamente ese sistema. En este artículo te enseño las 6 piezas que uso cada día para que Claude Code tenga memoria real, deje de perderse y, en muchas tareas, trabaje completamente solo gastando una fracción de lo que gastaría a lo bruto. No es teoría: es el stack que llevo a producción en proyectos de clientes.

Una idea antes de empezar, porque lo cambia todo: el modelo ya no es el cuello de botella. Opus, GPT, Gemini, Qwen… todos son brutales y, en la práctica, intercambiables (commodities). Lo que marca la diferencia es cómo lo guías y cuánto contexto le metes. Las 6 herramientas de abajo van justo de eso.

1. Superpowers: la base de todo

Superpowers (de Jesse Vincent) es un plugin que instala una metodología completa de desarrollo de software para agentes: un conjunto de skills componibles que Claude encadena solo para escribir código sólido gastando una fracción de tokens. Es la base sobre la que monto el resto.

El paquete trae skills para cada fase del trabajo:

• brainstorming — explora el contexto y te hace preguntas antes de escribir nada (persistencia: ¿JSON o SQLite?, estados del flujo, etc.).
• using git worktrees — al aprobar el diseño, crea una rama aislada y verifica que los tests parten limpios.
• Escritura de planes — convierte el diseño en subtareas pequeñas, cada una con archivos exactos, código completo y pasos de verificación.
• Subagentes, TDD (testeo), code review y una tarea final que cierra la rama (finish a development branch).

Cómo se usa (flujo real)

1. Instálalo desde su repositorio de GitHub (el instalador te guía). Después, recarga los plugins → plugins → installed → ahí aparece Superpowers.
2. Modelo recomendado: Opus (el más capaz disponible). Escribe superpowers brainstorming, pulsa TAB para activar la skill y lanza un prompt simple. Ejemplo: “Construye una app mínima de gestión de tareas”.
3. Responde a sus preguntas. Genera un documento de diseño completo.
4. Activa automode on (solo funciona con Opus, no con Sonnet) y Claude invoca solo la escritura del plan, lo trocea en subtareas (en el ejemplo, 14) y decide si las ejecuta inline o lanzando subagentes.

Dato real: ese MVP (monorepo backend + frontend, API, puertos 3001/5173) se construyó solo en 19 min 42 s, consumiendo apenas el 34% de un Plan Max. Tú solo tocas al final, en el pulido.

⚠️ El brainstorming puede abrir un “compañero web” en el navegador con mockups visuales para que elijas la UI a clic. Es cómodo, pero consume bastantes tokens.

2. Dream: memoria que no crece hasta el infinito

El problema de la memoria de un proyecto es que crece sin parar: notas duplicadas, contexto inflado y, al final, el modelo alucina y gasta de más. Dream (o AutoDream) es la capa que lo arregla: consolida y sintetiza la memoria, fusiona lo repetido y se queda solo con lo importante. La analogía es la fase REM del sueño: procesa muchas sesiones y conserva lo que vale.

El modelo de memoria tiene tres capas:

• Sesiones de chat — el contexto inmediato.
• Registro — archivos pequeños que se guardan por sesión.
• Capa inteligente (Dream) — la que optimiza y reescribe todo.

Y dos archivos clave: CLAUDE.md (las reglas e instrucciones del proyecto) y MEMORY.md (la memoria de lo hecho, que escribe Dream).

Cómo se activa

1. Con /memory abres la vista de memoria. Ahí verás un toggle automemory (suele estar OFF): ponlo en ON para que guarde memoria automáticamente.
2. /dream aún está en beta y no lo tiene todo el mundo. Se instala como skill desde un repo de terceros: copia el permalink del repo, pégalo y pide “crea una skill para esto y llámala Dream” usando el creador de skills.
3. Ejecútalo a mano (/dream) o prográmalo cada ciertas horas/sesiones. Escanea cientos de sesiones previas, identifica hitos, compacta, fusiona duplicados y reescribe MEMORY.md troceado en varios markdown interconectados (adiós al archivo gigante único).

Úsalo en proyectos con mucha información acumulada durante semanas o meses. Es donde se nota.

3. El arnés: el sistema que dirige al modelo

Esta es la pieza conceptual más importante. Hemos pasado del prompt engineering (2023) al context engineering (RAG) y ahora al harness engineering (el “arnés”): la estructura que construyes alrededor del modelo para dirigirlo.

La imagen mental es la de un trineo: el modelo es la jauría de perros (potencia bruta, sin rumbo); el arnés eres tú dándole dirección. Los modelos son intercambiables; el arnés es tuyo. Y no es palabrería: el equipo de LangChain subió del puesto 30 al 5 solo optimizando su arnés. Menos contexto y más directo rinde mejor — demasiada información “atonta” al modelo.

El arnés cabe en una decena de archivos y se apoya en tres pilares:

1. El repo. Aquí vive el estándar abierto AGENTS.md: el equivalente a CLAUDE.md pero genérico (lo leen Claude, Codex, Cursor, Antigravity…). Lo acompañan una lista de tareas (feature list), un archivo de progreso (actual + histórico), checkpoints y un init.sh que se ejecuta al arrancar cada sesión y verifica herramientas, estado del repo, del arnés y los próximos pasos.
2. Roles repartidos en subagentes. Un líder que planifica (no codifica), un implementador que ejecuta (no verifica) y un revisor que valida y es el único que aprueba (no implementa). Puedes tener 2, 3 o 5 según el proyecto.
3. Verificación.

Encima de todo va el bucle de autoaprendizaje (self-improving loop): cuando el revisor detecta un fallo no documentado, lo añade como regla a los checkpoints, y ese bug no vuelve a aparecer nunca. El arnés se afila con el uso. Consejo de quienes lo usan en serio: que no sea 100% automático — que te avise y tú apruebes añadir la regla.

Cómo se construye

En una sesión nueva basta con preguntar “¿qué es lo primero que tengo que hacer?”: Claude lee AGENTS.md, lanza init.sh, te da el diagnóstico (todo verde, sesión y tarea activas) y retoma justo donde lo dejaste. Después, “invoca al líder y tira millas” arranca el ciclo líder → implementador → revisor.

Tres avisos honestos:

• Un arnés por proyecto. El esqueleto se reutiliza; el contenido es único (como un CV: formato común, datos propios). Para una landing simple aporta poco; brilla en proyectos complejos.
• No es un setup de 5 minutos. Diseñarlo bien lleva 2-3 horas.
• Mantén AGENTS.md corto: por debajo de ~200 líneas. Con 500-600 líneas el modelo ya se olvida de cosas.

4. Dynamic Workflows: cientos de agentes en paralelo

Un Dynamic Workflow es un script en JavaScript que Claude escribe para orquestar agentes en paralelo. La diferencia con Make o n8n es brutal: si tienes 400 leads que volcar a una tabla, n8n los procesa de uno en uno (400 veces); un Workflow lanza 400 subagentes a la vez.

La clave técnica: el plan vive en el archivo JS, no en la memoria de Claude. No le pesa, no llena la ventana de contexto. Eso es lo que desbloquea tareas de gran volumen.

No lo confundas con un Agent Team: un Team es un equipo con roles que conversan entre sí y se corrigen en continuo (backend, frontend, seguridad…). Un Workflow son agentes solitarios que nunca se ven, cada uno hace una sola pasada y al final se hace un merge. Además, un Workflow es una matrioska: dentro puede usar subagentes, skills y MCP (Google Sheets, Airtable, bases de datos…).

¿Quieres verlo sin montar nada? El comando deep research de Claude Code es, por dentro, un Workflow disfrazado: lanza varios ángulos de búsqueda en paralelo. Sigue el progreso en vivo con /workflows.

Ejemplo para crear el tuyo

“Tengo 30 propuestas comerciales en PDF del último trimestre: detecta qué patrones de pricing y sector están cerrando.”

Claude lanza un agente barato (Haiku) por cada PDF para leerlos en paralelo y un agente Opus que consolida e informa. En un caso real, analizar una carpeta entera de scripts tardó ~2 min y devolvió un informe completo.

🔴 Aviso de coste, en serio. Los Workflows consumen tokens de forma indecente. Un “mejora mi proyecto entero” lanza cientos de subtareas y te funde el plan. Dos reglas de oro: no uses el modelo más potente para todo (Haiku/Sonnet para leer y extraer; reserva Opus solo para consolidar) y, si vas con plan de 20 $, pruébalo solo en tareas pequeñas.

5. Goal: itera hasta que funcione

El comando /goal es para tareas interactivas pero no parametrizables: le das un problema y itera sin parar hasta resolverlo. Es un solo agente dando muchas pasadas — justo lo contrario de un Workflow.

“No consigo descargar este PDF, da estos errores: trabaja en la solución hasta que el PDF se pueda descargar.”

No para hasta lograrlo. La forma fácil de saber qué usar son dos ejes:

• ¿Es interactiva pero no parametrizable? → Goal (1 agente iterando).
• ¿Es parametrizable pero no interactiva? → Workflow (muchos agentes, 1 pasada).
• ¿Es las dos cosas a la vez? → combinas ambos: es el concepto Ultra Code.
• ¿Ni una ni otra? → simplemente hablas con la IA.

6. Effort y Ultra Code: subir o bajar la inteligencia

El comando /effort regula cuánto esfuerzo aplica el modelo, con niveles low, medium, high, x-high y Ultra Code. Pulsa /effort, INTRO y te mueves por los niveles. Ultra Code es el formato x-high pensado para ejecutar Workflows; los demás niveles los usas por separado, sin workflow.

🔴 El más peligroso para el bolsillo. Workflows + Ultra Code puede ventilarte la suscripción en una sola petición. Resérvalo para tareas realmente difíciles.

En resumen: qué usar en cada caso

Esta es la tabla que tengo siempre en la cabeza:

• Pregunta puntual / respuesta corta → simplemente pregunta.
• Algo que harás muchas veces igual → una Skill.
• Tarea “sucia” que conviene aislar del hilo → un Subagente.
• Equipo que necesita hablar entre sí (front/back/seguridad) → un Agent Team.
• Iterar hasta que algo funcione sí o sí → Goal.
• Trabajo gigante de tareas independientes en paralelo → Workflow.
• Conectar todo eso con tus herramientas (Sheets, Airtable, bases de datos) → MCP.

Y por encima de todo: memoria con Dream, dirección con el arnés y disciplina de coste (el modelo adecuado para cada tarea ahorra más tokens que cualquier truco).

Conclusión

No necesitas el modelo más potente del mercado: necesitas el sistema correcto alrededor del modelo. Con Superpowers tienes la metodología, con Dream la memoria, con el arnés la dirección, y con Workflows, Goal y Effort eliges la potencia justa para cada tarea. Ese es el salto de “la IA me ayuda a escribir código” a “la IA trabaja sola y yo superviso”.

En ExpertBrain montamos exactamente esta infraestructura de agentes y automatización de IA para empresas y organismos en producción. Si quieres llevar tu desarrollo y tus procesos al siguiente nivel, hablemos.