Cada cierto tiempo aparece un framework que promete poner orden en el caos del desarrollo asistido por IA. nWave es uno de esos intentos, y probablemente el más ambicioso que hemos leído este trimestre. La propuesta es simple de enunciar y difícil de aceptar: no puedes escribir código hasta que el framework te deje.
Llevamos unas semanas evaluándolo sin instalarlo, solo leyendo el repo y la documentación. Esto no es una review de uso en producción — es un dictamen honesto desde la lectura, pensado para colegas que tienen que decidir si vale la pena clonarlo.
Qué hace realmente
nWave se describe como un framework spec-first con siete waves obligatorias y un motor de enforcement que bloquea la escritura de código si no has completado las gates correspondientes. La palabra “wave” no es marketing vacío: cada wave es una fase de trabajo con entregables concretos que deben firmarse antes de pasar a la siguiente. No son sugerencias, son puertas cerradas con llave.
Las siete waves son DISCOVER, DIVERGE, DISCUSS, DESIGN, DEVOPS, DISTILL y DELIVER. Empiezas entendiendo el problema y los stakeholders, generas varias opciones de solución, eliges una con justificación, diseñas técnicamente, preparas la infraestructura y el CI/CD, simplificas lo que quedó inflado, y finalmente entregas con documentación. El orden está fijo. El nombre — nWave — viene precisamente de ese flujo de ondas secuenciales que el framework impone sobre cualquier cambio de código, grande o chico.
Encima de eso hay cuarenta agentes especializados. Cuarenta. Agentes para cada rol imaginable: discovery, arquitectura, testing, compliance, documentación, deploy, mutation testing, auditoría. La idea es que cada uno tenga su contexto y responsabilidad separada, y que el orquestador principal los convoque según la wave activa.
Cómo funciona por dentro
El corazón técnico se llama DES — Design Enforcement System. Es el motor que revisa, antes de permitir que se escriba código, si las waves previas tienen sus entregables completos. Si no, bloquea. Y mientras trabajas, va generando un audit trail inmutable en formato JSONL con hashes SHA256 — cada paso queda firmado criptográficamente, cada decisión queda registrada. Para equipos con requisitos de compliance o auditoría regulatoria, ese diario es oro.
DES también expone rigor profiles configurables:
| Profile | Nivel | Uso típico |
|---|---|---|
| Lean | Básico | Bug fixes triviales |
| Standard | Medio | Features normales |
| Thorough | Alto | Features críticas |
| Exhaustive | Máximo | Compliance o regulación |
La idea de que el rigor sea un dial y no una decisión binaria nos parece sana. Un hotfix no necesita pasar por siete waves de reflexión; una feature que toca billing sí. nWave reconoce eso en su diseño, aunque la experiencia de default sigue siendo pesada.
El ciclo de TDD tampoco es el clásico red-green-refactor: son cinco fases. Escribes test de comportamiento, implementas lo mínimo, agregas tests de edge cases, corres mutation testing para verificar que los tests realmente detectan defectos, y recién entonces refactorizas manteniendo la cobertura. El mutation testing integrado en el flujo es, honestamente, la mejor parte del paquete.
Pros
Vamos con lo bueno, que lo hay y merece reconocimiento.
El enforcement engine es una idea genuinamente interesante. La mayoría de los frameworks spec-first son libros de estilo disfrazados: te dicen cómo trabajar, pero no te obligan a nada. DES sí obliga. En contextos donde saltarse la spec tiene costos reales — auditoría financiera, dispositivos médicos, infra crítica — tener un gate técnico que impida escribir código sin justificación es más fuerte que cualquier proceso humano.
El audit trail JSONL con SHA256 es de categoría enterprise. Si mañana llega un regulador y pide demostrar que un cambio en producción pasó por revisión de seguridad, el trail está ahí, firmado. Eso no lo da ningún linter.
Mutation testing integrado de serie. La mayoría de equipos nunca lo corre porque exige configurar una herramienta aparte. Tenerlo en el flujo por default sube el piso de calidad de tests de manera tangible.
Los rigor profiles son la concesión pragmática. Muestran que el autor entendió que un framework 100% rígido no sobrevive al primer sprint real.
Contras
Está muy acoplado a Claude Code. Los hooks de DES están escritos específicamente para el runtime de Claude Code. Si usas otro cliente, otro modelo o tu propio wrapper, la parte más valiosa del framework — el enforcement — deja de funcionar. Esto nos saca a nosotros y a cualquier equipo con pipeline heterogéneo.
Siete waves obligatorias para cualquier cambio es demasiado. Sí, existe el profile Lean. Pero el diseño mental del framework asume que toda unidad de trabajo merece discovery, divergencia y discusión formal. En la práctica, el 70% de los tickets de cualquier backlog real son cambios pequeños y claros donde forzar divergencia de opciones es teatro.
Cuarenta agentes es excesivo para prácticamente todos los equipos. Multiplica la superficie de mantenimiento, fragmenta el contexto, y agrega latencia por delegación. La experiencia acumulada con agentes coordinados dice que pasar de cinco o seis empieza a tener rendimientos decrecientes rápidamente. Cuarenta es una apuesta contra esa evidencia.
La complejidad hexagonal del sistema añade overhead que solo se justifica si ya estás operando a esa escala. Para un equipo de tres personas, nWave pesa más que el proyecto que intenta ayudar.
Comunidad chica. Con 365 estrellas y 41 forks, la red de soporte es limitada. No es crítica — muchos proyectos buenos empiezan así — pero sí es contexto que pesa al adoptar algo que va a estar en el camino crítico de tu pipeline.
Cuándo sí, cuándo no
Adoptar nWave tiene sentido si ya estás atrapado dentro de Claude Code, tu dominio exige trail de auditoría firmado, tu equipo tiene al menos diez personas con bandwidth para mantener el tooling, y tus cambios rara vez son triviales. Compliance financiero, healthcare, aerospace: ahí el enforcement engine paga su costo.
No tiene sentido si tu pipeline es heterogéneo, si la mayoría de tu trabajo son features de tamaño medio o bugs rápidos, si tu equipo tiene menos de cinco personas, o si tu prioridad es iterar rápido sobre una hipótesis de producto. En ese perfil — que es la mayoría — el framework genera más fricción que valor.
La comparación que aparece inevitablemente es contra Spec-Kit + GSD, o contra setups más ligeros basados en skills de Claude Code o workflows propios. Para el 90% de casos reales esas combinaciones entregan el mismo resultado funcional con una fracción del overhead.
Veredicto
nWave vale la lectura como ejemplo bien ejecutado de enforcement estructurado aplicado a desarrollo con IA. El DES, el audit trail firmado y el mutation testing integrado son ideas que vamos a robar — adaptadas, livianizadas, desacopladas de un runtime específico. El framework completo, en cambio, no lo vamos a recomendar para adopción en ningún cliente actual.
El problema no es que esté mal hecho: está notablemente bien hecho. El problema es que resuelve un conjunto de restricciones — acoplamiento a Claude Code, escala enterprise, compliance estricto — que muy pocos equipos tienen al mismo tiempo. Para todos los demás, el costo de arrastrar cuarenta agentes y siete waves obligatorias no compensa.
Si el autor sigue evolucionándolo hacia un núcleo más pequeño y desacoplado, con el enforcement como biblioteca opcional, podría volverse una herramienta de referencia. Hoy es un proyecto de ingeniería respetable que opinó muy fuerte sobre cómo se debe trabajar.
TL;DR — nWave es una pieza de ingeniería cuidadosa sobre un set de supuestos que casi nadie cumple; léelo por las ideas, no lo instales por los agentes.