Tenía un problema que no sabía nombrar.
Cada vez que quería implementar algo — una feature nueva, una mejora al sitio, una herramienta para mi stack — arrancaba con energía y terminaba a mitad de camino descubriendo aristas que no había considerado. Los criterios no estaban definidos desde el inicio, así que la implementación terminaba siendo algo distinto a lo que había planeado. No por falta de capacidad técnica. Por falta de claridad.
La frustración no era técnica. Era no saber cómo iban a terminar los proyectos que quería construir. Esa incertidumbre hacía que cada decisión a mitad de implementación se sintiera como improvisar, no como ejecutar.
Necesitaba un sistema que me obligara a resolver las ambigüedades antes de escribir la primera línea de código.
El framework que ya existía
Recientemente empecé a aplicar SDD — Specification-Driven Development — adaptado a Power Platform en mi trabajo. La idea es simple: antes de implementar cualquier solución, defines una especificación completa con criterios de aceptación verificables. Nada se construye sin spec aprobado.
Lo que no tenía era ese mismo rigor para mis proyectos personales. La brecha fue obvia una vez que la vi.
Cómo funciona el sistema
El ciclo produce tres artefactos en orden estricto. plan.md y constitution.md se combinan para generar tasks.md — las tareas no se derivan solo del plan, sino del plan validado contra las reglas absolutas del framework.
El spec usa criterios EARS, un formato donde cada criterio es verificable sin ambigüedad. Así se ve uno real del blog que construí hoy:
WHEN Eric crea un archivo Markdown con frontmatter válidoTHE sitio SHALL incluir ese post en el listado al siguiente deploy.
WHEN el frontmatter carece de título o fechaTHE sitio SHALL NOT incluir ese post ni generar una ruta para él.Sin espacio para interpretar. Sin espacio para improvisar.
La pieza central: el agente que no te deja avanzar
Construí el sistema como un Claude Code Subagent — un archivo Markdown con un system prompt que vive en mi entorno de desarrollo. Su única responsabilidad: hacerme preguntas hasta que no quede ninguna ambigüedad, y solo entonces generar el artefacto correspondiente.
Las reglas más importantes de su constitution:
THE agent SHALL never asumir decisiones técnicas.Esto incluye agregar campos no documentados en el spec,establecer valores por defecto no especificados, o adoptarconvenciones no acordadas.
THE artifacts SHALL generarse en orden estricto:spec.md → plan.md → tasks.md.Ningún artefacto se genera sin el anterior aprobado.La prueba real
El primer ciclo lo hice hoy mismo: agregar una sección de blog a este sitio.
El agente me hizo nueve preguntas antes de escribir una sola línea del spec. Audiencia, criterio de éxito medible, alcance explícito, decisiones técnicas con trade-offs. Cuando llegamos al plan, detectó algo que yo no había documentado: el método de deploy. No asumió nada. Preguntó. Documentamos que el deploy es manual con Docker. Eso evitó exactamente el tipo de supuesto incorrecto que antes me costaba descubrir a mitad de implementación.
El momento en que supe que funcionaba fue cuando probé los cambios en producción y funcionaron sin problemas a la primera.
Lo que cambió
Antes arrancaba rápido e improvisaba cuando aparecían los problemas. Ahora planifico con claridad y solo implemento una vez, sin contradicciones. El tiempo que antes perdía descubriendo problemas a mitad de camino lo invierto en definir bien el problema antes de empezar.