La guerra de frameworks de Claude Code
(shmck.substack.com)- Los desarrolladores ahora están en una etapa de aprendizaje sobre cómo colaborar con la IA, y Claude maximiza su valor cuando se usa no como un simple chatbot sino como un framework
- En la comunidad continúan diversos intentos por definir cómo configurar y aprovechar Claude, al punto de que la experimentación es tan intensa que ya se le llama Claude Code Framework Wars
- A partir de esto, está surgiendo una forma de trabajo en la que Claude se utiliza en múltiples roles como gerente de proyecto, arquitecto, desarrollador y revisor
- Diseñar un framework requiere 8 decisiones principales, incluyendo gestión del trabajo, provisión de instrucciones, colaboración entre agentes, operación de sesiones, acceso a herramientas, desarrollo de código, entrega y preservación del contexto
- La lección central es que la IA no reemplaza al desarrollador, sino que se consolida como un colega que multiplica la productividad mediante reglas y roles estructurados
Introducción
- Idea central: considerar a Claude no como una simple herramienta de conversación sino como un framework, para generar resultados previsibles y valiosos mediante reglas claras y flujos de trabajo definidos
- El desarrollador deja de centrarse en escribir código y pasa a roles de alto valor agregado (gestión de proyectos, diseño, arquitectura)
- El framework de Claude Code funciona con prompts estructurados sin necesidad de escribir código
- Claude Code Framework Wars: la comunidad de desarrolladores está experimentando con distintos enfoques para usar IA de forma productiva
- Decenas de proyectos open source compiten definiendo flujos de trabajo y estructuras de roles
- Ejemplos: Agent OS, Claude-Flow
Principales decisiones a considerar al diseñar un framework
1. Dónde gestionar el trabajo
- Es necesario definir una fuente de tareas que Claude pueda consultar
- Backlog en Markdown: gestionar las tareas como una lista de pendientes en formato Markdown
- Ejemplos: Backlog.md, ReqText
- Texto estructurado: convertir especificaciones de producto en tareas
- Ejemplo: Agent OS
- Issues/tickets: guardar especificaciones en GitHub Issues o tickets de Jira y conectarlas con la revisión de código
- Ejemplo: ccpm
- Backlog en Markdown: gestionar las tareas como una lista de pendientes en formato Markdown
- Clave: las tareas deben almacenarse en un lugar accesible y rastreable para Claude
2. Cómo darle guía a Claude
- En lugar de prompts ambiguos, hay que dar instrucciones a Claude con una estructura clara
- Biblioteca de comandos: comandos slash predefinidos como
/create-tasksy/review - Estándares de código: especificar el stack tecnológico y las guías de codificación
- Definición de terminado: codificar los criterios para considerar una tarea completada
- Hooks de validación disparados: forzar linting y pruebas en cada cambio
- Claude como revisor: Claude realiza tanto desarrollo como revisión
- Biblioteca de comandos: comandos slash predefinidos como
- Clave: reglas claras y repetibles mejoran la calidad del trabajo de Claude
3. Estructura de colaboración entre agentes
- Cuando se usan varios agentes Claude, se coordinan mediante roles y planificación
- Simulación de roles: la IA asume funciones de PM, arquitecto, desarrollador y tester
- Ejemplo: Agent OS
- Procesamiento paralelo tipo swarm: ejecución simultánea de múltiples agentes dentro de un flujo estructurado que va de especificación → pseudocódigo → código → pruebas
- Ejemplo: Claude-Flow
- Artefactos nativos del repositorio: guardar tareas, logs y registros de decisiones (ADR) en el codebase para mantener memoria persistente
- Ejemplo: Roo Commander
- Simulación de roles: la IA asume funciones de PM, arquitecto, desarrollador y tester
- Clave: la coordinación evita conflictos entre múltiples trabajadores de IA
4. Cómo operar las sesiones
- Para evitar el caos en la salida de la IA, las sesiones se establecen como entorno de trabajo
- Orquestación de terminal: Claude controla comandos, ventanas y logs
- Ejemplos: Symphony, Claude-Squad
- Worktrees paralelos: ejecutar múltiples ramas en paralelo con Git Worktrees
- Ejemplo: Crystal
- Contenedores paralelos: ejecutar Claude en contenedores independientes para evitar conflictos
- Ejemplo: ClaudeBox
- Orquestación de terminal: Claude controla comandos, ventanas y logs
- Clave: el trabajo en paralelo maximiza la productividad sin conflictos
4. Cómo ejecutar las sesiones
- Para evitar el caos en la salida de la IA, las sesiones se establecen como entorno de trabajo
- Orquestación de terminal: Claude controla comandos, ventanas y logs
- Ejemplos: Symphony, Claude-Squad
- Worktrees paralelos: ejecutar múltiples ramas en paralelo con Git Worktrees
- Ejemplo: Crystal
- Contenedores paralelos: ejecutar Claude en contenedores independientes para evitar conflictos
- Ejemplo: ClaudeBox
- Orquestación de terminal: Claude controla comandos, ventanas y logs
- Clave: el trabajo en paralelo maximiza la productividad sin conflictos
5. Acceso de Claude a herramientas
- Configurar a Claude para que aproveche su conocimiento de todo el stack tecnológico
- Integración MCP: conectar navegador, base de datos, test runner y framework de automatización de UI
- Biblioteca de herramientas personalizadas: construida con scripts de shell y comandos
- Ejemplo: Symphony
- Accesores de base de datos: herramientas potentes de acceso a bases de datos
- Ejemplo: Claudable with Supabase
- Hooks de prueba y validación: ejecutar pruebas con Vitest, Jest, etc., antes de dar por terminada una tarea
- Ejemplo: Agent OS
- Clave: integrar herramientas transforma a Claude de un simple autocompletado en un miembro activo del equipo
6. Cómo desarrollar código
- Claude puede asumir distintos roles según se necesite
- Gerente de proyecto (PM): convertir especificaciones de producto en tareas y backlog
- Arquitecto: diseñar la estructura general, definir interfaces y establecer reglas antes de programar
- Implementador: escribir código siguiendo pruebas y estándares
- QA: revisar problemas en las tareas
- Ejemplo: BMAD-code
- Revisor: auditar la calidad del PR, la legibilidad y los riesgos
- Clave: usar IA a lo largo de todo el ciclo de vida del software
7. Cómo entregar el código
- Definir cómo llega el código al repositorio
- Clave: elegir entre iteraciones seguras para producción o scaffolding para prototipos
8. Cómo preservar el contexto
- Resolver el problema de olvido de Claude con una memoria del framework
- Documentos y diario: mantener actualizados CLAUDE.md, notas de arquitectura y diario del proyecto
- Ejemplo: Claude Conductor
- Memoria persistente y chequeos: guardar resúmenes del trabajo reciente, salud del proyecto y decisiones
- Ejemplo: Claude-Flow
- Documentos y diario: mantener actualizados CLAUDE.md, notas de arquitectura y diario del proyecto
- Clave: sin memoria, la IA repite errores; con memoria, el progreso se vuelve más acumulativo
Cómo integrarlo todo
- Considerar las opciones como un menú; no hace falta configurarlo todo de una vez
- Configuración para principiantes: backlog en Markdown + diferencias por ticket
- Equipo estructurado: especificaciones de producto + estándares + simulación de roles
- Enfoque experimental: artefactos en repositorio + sesiones paralelas
- Modo prototipo: app builder + scaffolding de documentación
Conclusión e implicaciones
- Lección central: Claude rinde mejor en un entorno estructurado
- No reemplaza el rol del desarrollador; reduce el trabajo boilerplate para que este se concentre en definir especificaciones, revisar diseños y definir arquitectura
- Si el trabajo se desvía, puede descarrilarse rápidamente, por lo que la gestión estructural es indispensable
- Aunque aún estamos en una etapa temprana, los frameworks están llevando a la IA a converger no hacia una caja mágica sino hacia un conjunto de compañeros de equipo gestionables
- Cuanta más estructura se le dé, mayor valor devuelve
- A través de proyectos open source, la comunidad está experimentando con distintos frameworks y explorando formas de usar IA de manera productiva
- Los desarrolladores pueden usar Claude de forma sistemática para centrarse en trabajos de alto valor agregado e integrar la IA como parte del equipo para maximizar la productividad
1 comentarios
Comentarios en Hacker News
He probado varios "frameworks" para Claude Code, pero objetivamente no me queda claro que el rendimiento haya mejorado.
Están llenos de rituales alrededor de procesos complejos como si fueran una receta oficial, pero me pregunto qué es lo que realmente los hace útiles.
Siento que este enfoque de framework no encaja con el propósito del entrenamiento del modelo.
En la práctica, terminas arrojándole información innecesaria al modelo y contaminando el contexto a la fuerza para ajustarlo a "mi proceso predefinido".
Creo que lo importante es eliminar esa contaminación del contexto, dar solo la información indispensable para la tarea real e ir mejorando de forma gradual.
Este tipo de colaboración tradicional encaja mejor cuando ocurre fuera del contexto del agente, que está limitado por el propio contexto.
En este texto no se menciona en absoluto a los subagents, así que me da curiosidad saber cuándo fue escrito.
Yo delego a subagents tareas como "buscar en el memory bank solo la información relevante para la tarea actual" o "ejecutar pruebas y devolver únicamente los fallos y la cobertura".
Eso me ha ayudado a evitar que el contexto del agente principal se llene demasiado rápido.
https://docs.anthropic.com/en/docs/claude-code/sub-agents
Mi vida se volvió mucho más cómoda al adoptar algunas prácticas útiles como dev containers y worktrees.
También armé mi propio "framework" de shell scripts para manejar archivos del proyecto y crear worktrees, y lo terminé en unos dos días.
Me gusta la libertad de no depender de una herramienta específica.
Estoy de acuerdo en que la contaminación del contexto es una realidad a la que de verdad hay que prestarle atención.
En especial, después de ver que las definiciones de endpoints MCP ocupan una parte considerable de mi contexto, como unos 20 mil tokens, ahora siempre tomo en cuenta ese problema de contexto al elegir MCP.
Se siente como una situación muy parecida a la de un project manager real.
Lo que yo quiero es que, al usar Claude, se incluya en la propuesta una etapa donde primero haga preguntas sobre lo que no está claro.
Si a un ingeniero real solo le dieras los requisitos y el resultado esperado, obviamente haría preguntas adicionales antes de ejecutar para asegurarse de que entendió bien.
Espero que Claude también pueda automatizar ese proceso de validación.
A menudo veo muchos errores porque no toma en cuenta en absoluto las preguntas que no fueron aclaradas.
Cuando aplican estos frameworks, me da curiosidad cuánta autonomía real les dejan y en qué entorno los usan, ya sea greenfield o brownfield.
También me gustaría saber si alguien ha logrado obtener resultados con confianza conectando Claude Code a software empresarial.
En mi empresa tengo acceso relativamente libre a Claude Code, pero en mi codebase los resultados son inconsistentes, sobre todo si incluyo frontend UI o Playwright.
Quiero conocer experiencia real sobre cuánto código basura deja, qué tan agotadora se vuelve la colaboración con colegas, el tamaño de los pull requests, el costo de razonamiento y cómo gestionan la paralelización.
Los documentos README a veces se sienten como material promocional de venta, llenos de términos específicos del sistema, emojis y formas excesivamente personalizadas de ordenar la caja de herramientas.
Al final, imagino que Anthropic y otros terminarán incorporando estas funciones directamente en su propio CLI.
Personalmente, con un modelo de reasoning hago que procese una especificación de 10 páginas, lint/type check/formatter/hook estrictos, checklist de trabajo e incluso TDD red/green, y con un simple "go" a GPT-5 me genera automáticamente lo necesario.
Si cualquiera tuviera las mismas herramientas, podría armar fácilmente su propio sistema.
Uso el plan Max de $200, así que el costo de razonamiento también queda fijo.
En especial, los resultados fueron claros en escenarios greenfield, como agregar nuevas funcionalidades.
Para refactorizaciones complejas o cambios profundos del sistema, también avanza bastante si hay buena documentación de diseño, pero donde falta documentación no funciona tan bien.
Al principio producía "código no tan bueno", con implementaciones flojas en estilo, reutilización o mantenibilidad, pero desde que reforzamos el archivo CLAUDE.md y obligamos a la persona de desarrollador a usar siempre el subagent "elixir-code-reviewer", la calidad del código mejoró de forma notable.
Nuestra plataforma es open source, así que comparto aquí la configuración actual de comandos de Claude y subagents.
https://github.com/Simon-Initiative/oli-torus/tree/master/.claude
El estilo tan característico de los LLM se sentía muy fuerte en el blog.
La información es útil, pero da risa estar aprendiendo sobre IA a partir de una IA.
Últimamente muchos textos sobre IA me transmiten esa misma sensación.
En la práctica, salvo que sea una tarea no especializada, hay que monitorear directamente a Claude Code e intervenir de inmediato si empieza a desviarse.
No se le puede dar demasiado permiso por temas de seguridad ni dejar de revisar qué comandos está ejecutando realmente.
Los "frameworks" actuales todavía tienen mucho camino por recorrer y, por ahora, lo más realista es pensar en esto como "un pasante junior que produce código a velocidad brutal".
Puede ser que quien escribió el post no haya revisado bien los repos o que en realidad el resultado venga de una investigación limitada.
Por ejemplo, superClaude no es un servidor MCP, y metaGPT no parece ser compatible con Claude Code.
Siempre me he preguntado por qué no dejan que los agents, igual que los humanos, gestionen su propio contexto.
No entiendo por qué incluyen siempre todo el historial completo de trabajos previos cada vez.
Si dejaran que el agent decida qué contexto conservar para ser eficaz y aprenda por sí mismo las ventajas y desventajas de gestionar el contexto, creo que mejoraría su capacidad para ejecutar cada tarea.
Al final, aquí también parece repetirse la clásica "bitter lesson" de manual.
La gente crea toda clase de "frameworks", pero la siguiente generación de modelos los vuelve inútiles a todos.
http://www.incompleteideas.net/IncIdeas/BitterLesson.html
Me sorprendió bastante que no se mencionara BMAD-method.
Por mi experiencia, BMAD-method es el mejor complemento para Claude Code.
Me da curiosidad qué es BMAD-method.
Quisiera saber si se queda solo en el nivel de system prompt o qué lo hace sentirse tan útil.
https://github.com/bmad-code-org/BMAD-METHOD
El sistema BMAD se ve parecido a AgentOS, que aparece en el post.
Ese tipo de context engineering me ha funcionado bien, y yo mismo hago que Claude genere comandos y agents para luego ajustarlos según lo que necesito.
Últimamente también estoy usando mucho json y markdown para compartir contexto.
taskmaster también, pero no aparece en la lista.
Gestionar el context se siente casi como programación de bajo nivel.
Es parecido a tener que meter los valores exactos en los registros de CPU para obtener la operación correcta.
La diferencia es que nosotros tenemos mucho menos control sobre qué context agregar o quitar en cada tarea.
Probé B-MAD Framework y la diferencia en resultados fue tan grande que ahora ya no puedo trabajar sin esa herramienta.
Ojalá sigan apareciendo más frameworks así.
Me da curiosidad si alguien aquí ha usado realmente estos frameworks.
Quiero saber si dan resultados de verdad o si son solo hype de moda.
Los resultados son los esperables: aparecen funciones por todos lados sin validación, casi sin documentación decente y llenas de Claude-ismos.
En la práctica, quedan al nivel de algo que solo sirve para unos pocos proyectos que le interesan a quien lo construyó.