En los últimos meses aparecieron más frameworks de AI coding de los que cabe probar. Cada uno con su manifiesto, su workflow propio, su promesa de cambiar cómo se programa. El problema honesto: instalar los nueve para compararlos cuesta más tiempo que el que ahorra cualquiera de ellos.
Así que hicimos el trabajo al revés. Leímos a fondo los nueve, tomamos notas, y escribimos esta página para que un colega pueda decidir en 15 minutos qué adoptar sin instalar nada. Cada uno tiene su blog dedicado enlazado al final; esta es la vista aérea.
La tabla corta
| Framework | Estrellas | Tipo | Complejidad | Nuestro veredicto |
|---|---|---|---|---|
| Superpowers | 164k | Skills + TDD | Baja | Adoptar — base |
| Spec-Kit | 90k | Spec-driven | Media | Adoptar — metodología |
| GSD | 56k | Context eng. | Media | Adoptar — base |
| BMAD-METHOD | 45k | Enterprise Agile | Alta | Evitar — overkill |
| RuFlo / Claude-Flow | 33k | Swarms + MCP | Muy alta | Evitar — superficie enorme |
| Archon | 19k | DAGs YAML | Media | Adoptar — orquestación |
| Ralph Loop | 8.8k | Bash loop | Mínima | Limitado — solo greenfield |
| nWave | 365 | Gates + waves | Alta | Evitar — demasiado acoplado |
| Rita Vrataski | 117 | Governance | Baja | Opcional — sólo si usas Linear |
El número de estrellas no es calidad; es visibilidad. Hay cosas de 363 estrellas notablemente bien pensadas y cosas de 32k que son un monumento a la acumulación. Tómalo como contexto de comunidad, no como nota del profesor.
La pirámide que usamos
Después de tres semanas de lectura, nos quedamos con una forma sencilla de ordenar el stack:
┌──────────────────────────────┐
│ GOVERNANCE │ Rita Vrataski + Linear
├──────────────────────────────┤
│ ORQUESTACIÓN │ Archon (DAGs YAML)
├──────────────────────────────┤
│ METODOLOGÍA │ Spec-Kit (SDD)
├──────────────────────────────┤
│ BASE │ Superpowers + GSD
└──────────────────────────────┘
Cada nivel resuelve una pregunta distinta. Base responde “cómo trabaja el agente en un archivo”. Metodología responde “cómo sabemos qué construir”. Orquestación responde “cómo coordinamos muchos pasos en un mismo feature”. Governance responde “cómo mantenemos trazabilidad frente al negocio”.
Un equipo chico probablemente sólo necesita el primer nivel. Un equipo regulado necesita los cuatro. Todo lo de en medio es calibración.
Base — Superpowers + GSD
Superpowers aporta la piedra angular: skills en markdown, TDD obligatorio, subagentes con contexto fresco, code review automática entre tareas. Es agnóstico del runtime (Claude Code, Codex, Cursor, OpenCode). Curva baja. Es lo que recomendaríamos a un colega que pregunta “por dónde empiezo”.
GSD no compite — complementa. Ataca el problema que Superpowers no ve: cómo rompes un feature largo en fases sin que el contexto se pudra entre una y otra. Tiene salvaguardas explícitas (ship refusal, scope reduction detection, analysis paralysis guard) que son difíciles de imitar con disciplina humana.
Usar ambos no es redundante. Superpowers te da la mecánica de “cómo trabaja el agente en esta tarea”. GSD te da la mecánica de “cómo mueves el proyecto de una tarea a la siguiente”. Si solo puedes adoptar uno, Superpowers. Si puedes adoptar dos, ambos.
Metodología — Spec-Kit
Spec-Kit llega de GitHub con un planteamiento incómodamente bueno: la especificación es la fuente de verdad y el código es su output. El flujo /specify → /plan → /tasks → /implement convierte la spec en un artefacto versionable, no en el PDF que nadie lee.
No es revolución — es higiene. Es especialmente valioso en software regulado donde cada línea debe rastrear a un requisito. El costo: overhead real por feature, y la disciplina de mantener la spec viva. Si tu equipo ya escribe specs decentes, Spec-Kit es un upgrade natural. Si tu equipo nunca las escribió, va a doler antes de ayudar.
Orquestación — Archon
Cuando un feature tiene seis cosas que hacer y tres pueden ir en paralelo, Archon vale su peso. Define el workflow como un DAG en YAML: nodos, dependencias, gates. El agente ejecuta el grafo. No es más listo; es más predecible.
No usamos Archon para exploración —ahí destruye la intuición con andamios— pero para el tercer refactor igual que los dos anteriores, ahorra una tarde completa cada vez. La heurística: si puedes escribir el workflow sin ejecutarlo, úsalo.
Governance — Rita Vrataski (opcional)
El patrón Rita Vrataski Loop sólo aplica si tu equipo ya vive en Linear. Consiste en que humano y agente compartan el mismo backlog, con el PM tool como árbitro. Aporta trazabilidad y priorización humana; sobra en equipos que no usan Linear.
No es stack base. Es una capa de governance que se añade arriba de todo lo demás si la infraestructura lo justifica.
Los que no adoptamos
BMAD-METHOD es impresionante de leer — seis agentes nombrados imitando un equipo enterprise — pero el overhead es desproporcionado para equipos de cinco a diez personas. Si tienes un departamento de veinte devs y un sprint de tres semanas, merece segunda lectura. Para el resto, es una caricatura de la estructura que no tenemos.
RuFlo / Claude-Flow tiene 32k estrellas y genuina innovación técnica (RuVector, Agent Booster). Pero son 313 herramientas MCP mantenidas por una sola persona. El bus factor basta para descartarlo en cliente. Lo miramos con admiración, no lo instalamos.
nWave hizo un trabajo notable con su enforcement engine y su audit trail SHA256. El problema no es técnico — es de encaje: acoplado a Claude Code, 40 agentes específicos, 7 waves obligatorias incluso para ajustes triviales. Ideas buenas, ejecución pesada.
Los patrones límite
Ralph Loop es elegante: while :; do cat PROMPT.md | claude-code; done. Cuarenta caracteres de bash. Funciona sorprendentemente bien para greenfield de fin de semana. No sirve para proyecto de cliente; no tiene memoria, no tiene planning, no tiene recovery inteligente. Lo incluimos para que quede claro que a veces la respuesta correcta cabe en una línea.
Qué elegiría un equipo de cinco personas
Si mañana empezamos desde cero:
- Lunes — Instalar Superpowers. Un día aprendiendo skills básicas y TDD.
- Martes a viernes — Primer feature real usando sólo Superpowers. Ver dónde duele.
- Semana 2 — Añadir GSD para manejar features más largos.
- Cuando el primer proyecto requiera trazabilidad — Spec-Kit.
- Cuando aparezca el primer feature con 8+ pasos paralelos — Archon.
Lo que no haríamos: adoptar los cinco el mismo lunes. Cada framework añade fricción; el beneficio se acumula por capa, no por suma simultánea.
Qué elegiría un equipo de veinte en software regulado
Aquí el cálculo cambia:
- Spec-Kit desde el día uno. La trazabilidad es auditoría, no lujo.
- Superpowers + GSD como runtime del agente.
- Archon para features multi-componente.
- Rita Vrataski si usan Linear como PM.
Más un rito no-negociable: code review humana obligatoria sobre todo el output del agente, no importa qué framework lo generó.
El principio que repetimos
Estos frameworks se complementan, no compiten. Elegir uno por blog post viral lleva a reemplazarlo a los tres meses. Elegirlos por la pregunta que resuelven lleva a una arquitectura que envejece bien.
La tentación es usar el más nuevo. La respuesta honesta casi siempre es: Superpowers + GSD + disciplina humana resuelve el 90% de los casos. Todo lo demás se adopta cuando la falta duele — no antes.
TL;DR — empieza con Superpowers + GSD. Añade Spec-Kit cuando necesites trazabilidad. Añade Archon cuando tengas features con pasos paralelos. Ignora BMAD, RuFlo y nWave hasta que trabajes en un contexto donde genuinamente aporten. Ralph Loop es una postal, no un stack. Rita Vrataski es opcional y vive o muere con Linear.