Comparativa · Fase 1 — el SDD
zero vs gentle.
Dos enfoques de spec-driven development para agentes de IA. gentle-ai (de Alan / Gentleman Programming) y zero comparten la misma intuición — no improvisar, trabajar en fases — pero la resuelven distinto. Esto compara solo el SDD; la memoria va en la fase 2.
Dos filosofías.
El mismo objetivo — que el agente no improvise — resuelto de dos maneras distintas.
Un ciclo de vida de especificación
10 fases sobre un modelo de artefactos estilo OpenSpec: specs canónicas que evolucionan con deltas (ADDED/MODIFIED/REMOVED), sync y archivo con audit trail. TDD estricto, presupuesto de revisión. Es un sistema de documentación viva del proceso.
Un loop de feedback ajustado
4 fases con un orquestador que cuenta rondas y tiene un cap duro,
un veredicto adversarial obligatorio, y memoria de corridas
que alimenta un tuner de modelos. Es un sistema que se auto-mejora
con cada corrida.
Bloques componibles
Cada pieza hace una cosa y se enchufan. gentle-ai / gentle-pi — harness SDD + registry de skills. engram — memoria persistente (Go + SQLite/FTS5).
Un workflow con todo cableado
La memoria y el aprendizaje van adentro. zero / zero-pi — pipeline SDD + skill-loop + run-memory + autotune. Cortex — memoria MCP cross-session.
Los pipelines, lado a lado.
gentle granular y artefactado · zero compacto y con loop de verificación.
sdd-fullspec ∥ design pueden ir en paralelo. verify reporta pero no arregla → el orquestador rutea de vuelta a apply. Sin cap de rondas dentro del pipeline.
/forgeveredicto devuelve pasa ·
corregir (re-build) · replantear (re-plan). El
orquestador cuenta rondas build↔veredicto y frena en el cap
con "no verificado" — nunca miente un éxito.
La comparativa.
| Dimensión | gentle-ai SDD | zero SDD |
|---|---|---|
| Fases | 10 — init→explore→proposal→spec→design→tasks→apply→verify→sync→archive | 4 — explore→plan→build→veredicto |
| Entrada | chains (sdd-full) + comandos por fase + lenguaje natural |
un comando — /forge <feature> |
| Artefactos de spec | ✓modelo OpenSpec — specs canónicas, deltas ADDED/MODIFIED/REMOVED, sync, archivo con audit trail | ✓modelo propio — store .sdd/specs/, deltas ADDED/MODIFIED/REMOVED, /zero-sync, .sdd/archive/ (v0.1.8) |
| Cap de iteración | ✗ninguno dentro del pipeline — verify↔apply puede loopear (cap solo en tooling companion) | ✓cap duro de rondas + estado terminal "no verificado" |
| Review adversarial | ~sdd-verify es un ejecutor más, no fresh-context/blind. Lo adversarial (judgment-day) está aparte |
✓veredicto es una fase obligatoria, perspectiva fresca, sin pasa no hay éxito |
| Modelo de veredicto | verify emite CRITICAL/WARNING/SUGGESTION → orquestador rutea a apply | 3 veredictos — pasa / corregir (re-build) / replantear (re-plan) |
| Rigor TDD | ✓estricto — RED→GREEN→TRIANGULATE→REFACTOR, tabla de evidencia, auditoría de calidad de asserts | ~liviano — "test-first donde sea práctico" |
| Carga de revisión | ✓presupuesto de 400 líneas, Review Workload Forecast, estrategia de PR encadenado | ✓Review Workload Forecast — presupuesto de 400 líneas por task en la fase plan (v0.1.6). Sin PR encadenado |
| Ruteo de modelos | por agente, estático — /gentle:models + nivel de "thinking" |
por fase, adaptativo — autotune v2 aprende por fase (corregir→build, replantear→plan) y ajusta solo el culpable |
| Memoria en el loop | store de artefactos — guarda los archivos de fase en engram; resume por topic key | loop de aprendizaje — recuerda resultados de corridas pasadas y alimenta el autotune |
| Paralelismo | ~secuencial single-writer; el paralelo lo aporta pi-subagents (companion) |
✗secuencial |
| Agentes soportados | ✓~10 — Claude Code, Cursor, Gemini, OpenCode, Copilot, Kiro… | ~4 — Claude Code, pi, OpenCode, Codex |
| Resumir una corrida | ✓/sdd-continue — sigue por la próxima fase lista |
✓/forge --continue — retoma desde la fase/task incompleta (v0.1.7) |
| Respaldo en código | merge de deltas + guardrails OpenSpec en TS con tests; comportamiento de fase prompt-driven | installer + autotune + motor de merge de specs (spec-merge.ts) en TS con tests; comportamiento de fase prompt-driven |
| Auto-contenido | ~la experiencia completa pide 6–7 paquetes companion | ✓pipeline + skills + memoria + autotune en un paquete |
Lo que zero mejora.
Dónde el enfoque de zero es genuinamente más estricto o más vivo.
Cap duro + "no verificado"
El orquestador de zero cuenta rondas build↔veredicto y frena en el cap admitiendo que no se verificó. El SDD de gentle no tiene cap adentro del pipeline — verify↔apply puede girar sin límite.
Veredicto adversarial obligatorio
En zero el veredicto es una fase del pipeline, con
perspectiva fresca, y la corrida no puede declararse exitosa sin un
pasa. En gentle el review adversarial real está bolt-on
(skill judgment-day), no garantizado.
Re-plan vs re-build (3 veredictos)
replantear distingue "el plan estaba mal" de "el build
estaba mal" y vuelve a la fase correcta. gentle solo rutea CRITICAL →
apply: siempre asume que el culpable es la implementación.
Memoria que es un loop, no un store
zero recuerda resultados — qué se rompió, qué plan falló — y la próxima corrida arranca de ahí. La memoria de gentle guarda los artefactos de fase; es almacenamiento, no un loop de feedback.
Autotune — ruteo de modelos adaptativo
zero aprende qué modelo le rinde a cada fase desde los pass-rates reales y ajusta el perfil solo. gentle tiene ruteo por agente, pero estático — lo configurás una vez. Nadie más tiene el ajuste adaptativo.
Auto-contenido y compacto
zero-pi trae pipeline + skill-loop + run-memory + autotune en un paquete y 4 fases. La experiencia completa de gentle-pi pide 6–7 companions y el camino in-SDD son 10 fases.
Cerrado — y lo que falta.
Esta comparativa fue la hoja de ruta de zero. Casi toda — ya ejecutada.
- Specs canónicas que evolucionan →
canonical-specs: store.sdd/specs/, deltas,/zero-sync, archivo con audit trail (v0.1.8) - Conciencia de carga de revisión → Review Workload Forecast, presupuesto de 400 líneas/task en la fase plan (v0.1.6)
- Granularidad de artefactos → la fase plan emite proposal / spec / design por separado, + el
.sdd/archive/(v0.1.8) - Resumir una corrida →
/forge --continue, retoma desde la fase/task incompleta (v0.1.7) - Trigger por lenguaje natural → skill
sdd-routing, arranca SDD desde "hacelo con sdd" (v0.1.9) - Menos prompt, más código → el motor de merge de specs vive en TS testeado (
spec-merge.ts)
Lo honesto: dos cosas que gentle todavía hace mejor.
TDD estricto con evidencia
gentle exige RED→GREEN→TRIANGULATE→REFACTOR con tabla de evidencia y auditoría de calidad de asserts (prohíbe tautologías, smoke tests, tests mock-heavy). El build de zero sigue en "test-first donde sea práctico" — el único hueco de disciplina que no cerramos.
Amplitud de agentes
gentle-ai instala en ~10 agentes; zero llega a 4 (Claude Code, pi, OpenCode, Codex). No es disciplina — es cobertura. Sumar agentes es mecánico: un adapter por agente.
Quién gana en qué.
gentle-ai sigue siendo el SDD más maduro como ciclo de vida de especificación. Pero zero cerró el hueco estructural: ahora tiene specs canónicas que evolucionan, presupuesto de revisión, corridas resumibles y artefactos granulares — todo lo que esta comparativa marcó como hoja de ruta.
Y lo propio de zero sigue intacto: el cap duro, el veredicto adversarial obligatorio, el run-memory y el autotune — ahora v2, con atribución de modelos por fase. gentle no tiene nada de eso.
Queda un gap honesto — el rigor TDD. Pero la jugada salió: zero adoptó la disciplina de spec de gentle sin perder su loop de aprendizaje. gentle es el mejor sistema de documentación de proceso; zero, el mejor sistema auto-mejorable.