Dejé de hacer vibe coding. Este es el framework que construí para reemplazarlo.

Jose Luis Oronoz Troconis — Sat, 28 Mar 2026 13:54:27 +0000

El problema que nadie quiere admitir

Llevas meses usando IA para codear. Claude, Copilot, Cursor — lo que sea. Y funciona. Las primeras 2 horas van genial.

Después pasan cosas como estas:

Le pides que implemente un servicio y te escribe // TODO: implement later
Le pides tests y los escribe después de ver el código — básicamente confirma lo que ya hizo
Le preguntas si funciona y te dice "sí, debería funcionar" — sin evidencia, sin tests, sin nada
Cierras la sesión, vuelves al día siguiente, y Claude no recuerda nada de lo que decidieron juntos

Eso es vibe coding. Y es el enemigo del software de calidad.

La pregunta incómoda

¿Cuándo fue la última vez que tu IA escribió un test que falló primero?

Si la respuesta es "nunca" o "no recuerdo", entonces tus tests no están validando comportamiento. Están confirmando implementación. Es como calificar tu propio examen — siempre vas a pasar.

Lo que construí

Después de meses de frustración, construí Don Cheli — un framework de Desarrollo Dirigido por Especificaciones (SDD) que transforma el caos asistido por IA en ingeniería de software real.

La premisa es simple: no puedes escribir código sin haber escrito el test primero. Y no puedes escribir el test sin haber definido la especificación.

Spec → Test → Code. En ese orden. Sin excepciones.

Las 3 Leyes de Hierro

Llamo "leyes de hierro" a las reglas que el framework no permite saltarse bajo ninguna circunstancia:

1. TDD Obligatorio

No es una recomendación. No es un "best practice" que se ignora cuando hay prisa. Es una restricción dura en el pipeline.

/dc:start "Implementar autenticación JWT"

Se genera spec Gherkin con criterios de aceptación
Se escriben tests DESDE la spec (la IA NO ha visto código aún)
Los tests fallan (RED) ← esto es correcto
Se escribe el código mínimo para pasar (GREEN)
Se refactoriza (REFACTOR)

La diferencia clave: cuando la IA escribe tests después del código, los tests están acoplados a la implementación. Cambias la implementación → los tests se rompen aunque el comportamiento sea correcto. Con spec-first, los tests validan comportamiento, no detalles de implementación.

2. Debugging: causa raíz primero

Nada de "prueba cambiando esto a ver si funciona". El framework fuerza un proceso:

Reproducir → Aislar → Entender → Corregir → Verificar

3. Verificación: evidencia antes de afirmaciones

"Los tests pasan" > "creo que funciona". Si no hay evidencia, no se avanza.

Pre-mortem: anticipar el fracaso antes de codear

Esta es la feature que más me gusta y que ningún otro framework tiene.

/razonar:pre-mortem "Migración de PostgreSQL a MongoDB"

La IA imagina que tu proyecto ya falló. Analiza por qué falló. Y te da un plan para prevenirlo. Todo esto antes de escribir una sola línea de código.

Don Cheli tiene 15 modelos de razonamiento:

Modelo	Para qué
Pre-mortem	Anticipar fracaso
5 Porqués	Encontrar la causa raíz real
Pareto	Enfocarse en el 20% que produce el 80%
Inversión	¿Cómo garantizaríamos el fracaso?
Primeros principios	Descomponer al fundamento
Segundo orden	Consecuencias de las consecuencias
Costo de oportunidad	¿Qué pierdo por NO elegir la otra opción?
Reversibilidad	¿Puedo deshacerlo? Calibrar nivel de compromiso
Minimizar arrepentimiento	¿Qué decisión lamentaré menos en 10 años?
Círculo de competencia	¿Esto lo conozco de verdad o solo creo que lo conozco?
Mapa-territorio	¿Mi modelo refleja la realidad?
Probabilístico	Asignar probabilidades en vez de certezas
RLM (3 modelos)	Razonamiento con sub-LLMs para problemas complejos

Ningún otro framework de IA tiene esto. GSD no lo tiene. BMAD no lo tiene. Spec Kit no lo tiene.

Estimación: nadie más lo hace

/dc:estimate docs/prd.md

4 modelos que se complementan:

Modelo	Técnica
Puntos de Función	Complejidad funcional
Planning Poker IA	3 agentes estiman independientemente
COCOMO	Líneas de código estimadas → esfuerzo
Histórico	Comparación con tareas similares

El resultado es un rango: estimado optimista, esperado y pesimista con desglose por feature. Pregunté a cada framework competidor si pueden estimar esfuerzo. La respuesta: ninguno.

*## Debate adversarial: roles que se enfrentan
*
/dc:debate "¿Monolito o microservicios para el MVP?"

Esto invoca roles senior que deben encontrar problemas con las propuestas de los demás:

CPO: "El monolito nos deja lanzar 2-3x más rápido"
Arquitecto: "Pero sin boundaries, la extracción futura será un rewrite"
QA: "Monolito es más fácil de testear end-to-end"
Seguridad: "Un solo deploy = una sola superficie de ataque... pero también un solo punto de falla"

La regla: "no tengo objeciones" no es una respuesta válida. Cada rol DEBE encontrar al menos un problema. Esto saca a la luz riesgos que un solo agente nunca genera.

## Mesa técnica: expertos con +15 años

/dc:tech-panel "¿Redis o Memcached para caching de sesiones?"

5 expertos senior debaten tu decisión técnica:

Tech Lead — Visión holística, impacto en velocity del equipo
Sr. Backend — Patrones de resiliencia, connection pooling, race conditions
Sr. Frontend — Core Web Vitals, SSR vs CSR, design systems
Arquitecto — System design, C4 diagrams, ADRs
Sr. DevOps/SRE — IaC, SLOs/SLIs, zero-downtime deploys

Cada uno respalda sus argumentos con incidentes reales, benchmarks o post-mortems públicos. Argumentos sin respaldo se marcan como [teórico] y tienen menor peso.

Auditoría OWASP integrada

/dc:security-audit

Escanea las 10 categorías de OWASP:

A01 Broken Access Control — endpoints sin auth, IDOR, CORS
A02 Cryptographic Failures — passwords en plaintext, JWT sin expiración
A03 Injection — SQL, XSS, command injection
A04-A10 — Configuración, componentes vulnerables, logging

Cada hallazgo incluye: severidad, archivo, línea y fix sugerido. No es un plugin externo — está integrado en el pipeline.

El pipeline: 6 pasos, 6 puertas de calidad


mermaid
flowchart LR
    A["SPECIFY"] -->|Gate 1| B["CLARIFY"]
    B -->|Gates 2+3| C["PLAN"]
    C -->|Gate 4| D["BREAKDOWN"]
    D -->|Gate 5| E["IMPLEMENT"]
    E -->|Gate 6| F["REVIEW"]
    F -->|Fail| E
Cada puerta bloquea el avance si no se cumplen los criterios. No hay atajos.

Pero — y esto es importante — no necesitas memorizar nada de esto. Solo ejecutas:


/dc:start "Implementar autenticación JWT"
El framework detecta la complejidad automáticamente y ejecuta el pipeline apropiado. Para tareas simples, es ligero. Para tareas complejas, es exhaustivo. Se adapta.

Comparación honesta con otros frameworks
BMAD    GSD GSD-2   spec-kit    Don Cheli
Stars   42K 39K 3K  82K Nuevo
Comandos    ~20 ~80 ~40 ~10 72+
Skills  ~15 ~15 ~10 ~6  43
Razonamiento    — — — — 15 modelos
Estimación — — — — 4 modelos
Quality gates   — 1   2   4   6
TDD obligatorio — — — — Ley de hierro
OWASP   — — — — Integrado
i18n    — — — — EN/ES/PT
Multi-plataforma    — — — — Claude, Cursor, Antigravity

**Sí, tenemos menos stars. Somos nuevos. Pero en features, ninguno se acerca.**

Multilenguaje real (no solo READMEs traducidos)
Al instalar, eliges tu idioma. Todo el framework se adapta:

Nombres de carpetas: habilidades/ (ES) → skills/ (EN)
Nombres de comandos: /dc:iniciar (ES) → /dc:init (EN) → /dc:iniciar (PT)
Contenido de reglas: traducido a tu idioma
CLAUDE.md: en tu idioma
.cursorrules: en tu idioma

No es un README traducido con los archivos en otro idioma. Es i18n real, todo para que entiendas la estructura, entiendas los comandos y empieces a codear de verdad sin ninguna limitante de idioma o conocimientos avanzados.

Multi-plataforma
Don Cheli funciona con:

Plataforma  Soporte
Claude Code Completo — 72+ comandos, 43 skills, 7 agentes
Google Antigravity  14 skills + 9 workflows + router a 43 habilidades (Aqui no pudo ampliarlo mas pero es un buen nivel de avance)
Cursor  .cursorrules completo (115 líneas) con todos los comandos
Codex/Otros Instrucciones genéricas vía AGENTS.md

**Instalación en 1 minuto
**

curl -fsSL https://raw.githubusercontent.com/doncheli/don-cheli-sdd/main/scripts/instalar.sh | bash -s -- --global --lang es
O si prefieres verificar antes de ejecutar:


curl -fsSL https://raw.githubusercontent.com/doncheli/don-cheli-sdd/main/scripts/instalar.sh -o instalar.sh
cat instalar.sh  # Revisa antes de ejecutar
bash instalar.sh --global
Después, en cualquier proyecto:


/dc:start "Tu tarea aquí"

**Eso es todo. No necesitas leer documentación de 50 páginas. El framework te guía.**

Open source
Apache 2.0. Gratis. Sin tiers pagos. Sin limitaciones.

GitHub: github.com/doncheli/don-cheli-sdd
npm: npx don-cheli-sdd init
Web: doncheli.tv

72 comandos. 43 habilidades. 15 modelos de razonamiento. 4 de estimación. 6 puertas de calidad. TDD como ley de hierro.

Hecho en Latinoamérica para el mundo, si te gusta apoyame con un Star en Github, para poder expandir el framework a muchas mas personas. 

Deja de adivinar. Empieza a hacer ingeniería.

I stopped letting AI write tests after the code. Here's what happened.

Jose Luis Oronoz Troconis — Thu, 26 Mar 2026 18:40:18 +0000

The dirty secret of AI-generated tests

Your AI coding assistant writes tests. Great. But when does it write them?

After the code. After looking at the seeded data. After seeing the implementation.

That's not testing. That's the AI confirming its own work. It's like grading your own exam — you'll always pass.

Write the tests BEFORE looking at the data

I built Don Cheli, an open-source framework where TDD is an iron law:

Describe what you want
Spec gets generated (Gherkin with acceptance criteria)
Tests are written from the spec — the AI hasn't seen any data yet (RED)
Code is the minimum to make tests pass (GREEN)
Refactor

The framework blocks you from advancing if tests don't exist first. No shortcuts. No // TODO: add tests later.

But wait, there's more

Before you even start coding:

/razonar:pre-mortem — Imagine the project already failed. Why? Fix it now.
/dc:estimate — 4 models estimate effort independently (COCOMO, Planning Poker AI, Function Points, Historical)
/dc:debate — PM vs Architect vs QA argue your design. Each MUST find at least one problem.

After coding:

/dc:security-audit — OWASP Top 10 scan with file, line, and fix
/dc:review — 7-dimension peer review (performance, architecture, security, style, tests, correctness, clean diff)

The numbers

72+ commands
43 modular skills
15 reasoning models
6 formal quality gates
Works with: Claude Code, Cursor, Google Antigravity
Languages: EN, ES, PT (commands translate to your language)

Try it


bash
curl -fsSL https://raw.githubusercontent.com/doncheli/don-cheli-sdd/main/scripts/instalar.sh | bash -s -- --global --lang en
GitHub: https://github.com/doncheli/don-cheli-sdd

Open source. Apache 2.0. Stop letting AI grade its own homework.

I stopped vibe coding. Here's the framework I built instead.

Jose Luis Oronoz Troconis — Wed, 25 Mar 2026 23:15:35 +0000

I built a framework that forces Claude Code / Cursor And Google Antigravity to do TDD before writing any production code.

After months of "vibe coding" disasters, I built Don Cheli — an SDD
framework with 72+ commands where TDD is not optional, it's an iron law.

What makes it different:

Pre-mortem reasoning BEFORE you code
4 estimation models (COCOMO, Planning Poker AI)
OWASP Top 10 security audit built-in
6 quality gates you can't skip
Adversarial debate: PM vs Architect vs QA
Full i18n (EN/ES/PT)

Open source (Apache 2.0): github.com/doncheli/don-cheli-sdd

Happy to answer questions about the SDD + TDD methodology.

DEV Community: Jose Luis Oronoz Troconis