E203 - Spec-Driven Development (SDD)

Resumen

El episodio 203 de enCoders presenta Spec-Driven Development (SDD), una técnica para desarrollar con agentes de IA que se apoya en especificaciones escritas en lugar de prompts sueltos (vibe coding). Rodo la compara con TDD: cambia la herramienta que define qué hacer (specs en vez de tests), pero la filosofía es la misma. Defiende que fragmentar la documentación por feature (spec, design, tasks) y mantener un contrato global, ADRs y una carpeta de archivo permite abrir sesiones nuevas sin perder contexto, y sirve tanto a agentes como a humanos. Presenta el flujo de OpenSpec (explorar, proponer, escribir spec, implementar, archivar), skills complementarias (contrato, setup, validación, test, seguridad/OWASP, detección de drift) y skills abiertas de Matt Pocock (grilling, Wayfinder). Concluye que el vibe coding sirve para prototipos, pero para producción hace falta un humano en el loop que lea las specs, revise el código y automatice validaciones. El episodio incluye una pausa de memes (gastos de APIs en la nube, "graph engineering") y una demo en Codex.

Capítulos

• 00:00
  IntroPresentación del tema: SDD como técnica para desarrollar con agentes de IA, por qué creen que es mejor que el vibe coding y cuándo conviene o no.
• 00:45
  SDD vs TDD y documentaciónSDD es similar a TDD pero se definen especificaciones en vez de tests. Documentar es opcional si se trabaja solo, pero necesario cuando varias personas comparten un repositorio.
• 03:40
  Trabajo en equipo con IALa IA tiene ventana de contexto acotada y hay que recontextualizarla en cada sesión. Un archivo tipo context/claude/agent con memoria a largo plazo ayuda, pero es demasiado genérico para detalles específicos.
• 06:15
  Contexto modular por featureSe propone fragmentar la documentación en archivos por feature, entregando a la IA solo el contexto general más el de la feature en que se trabaja. Cris comenta que mantiene un archivo de arquitectura y un skill que lo actualiza tras los cambios.
• 08:21
  Specs Design TasksCada feature tiene spec (resultado final), design (cómo llegar, con pseudocódigo) y tasks (lista de tareas concretas por prioridad). Se discute por qué Markdown es mejor formato que JSON o texto plano.
• 12:05
  Cuándo usar SDDMezcla OpenSpec con otras herramientas propias; no tiene sentido en casos simples. A menudo parte con vibe coding para un prototipo y luego pide ordenarlo con una especificación.
• 13:36
  Contrato del proyectoArchivo .md análogo al canvas de analytics: objetivo de negocio, tipo de modelo, nube, restricciones de ciberseguridad e infraestructura, más listas always/maybe/never (ej. nunca commitear contraseñas ni datasets; siempre usar uv).
• 18:18
  ADRs y decisionesLos Architecture Decision Records registran qué decisión de arquitectura se tomó y por qué (ej. gestión de librerías, preproceso). Cada ADR puede tener varias specs asociadas, y sirven también a otras personas del equipo.
• 22:11
  Archivar y limpiar specsLas specs terminadas pasan a una carpeta archive; OpenSpec deja solo la spec macro. Borrar lo archivado reduce el riesgo de que el agente lo lea por error, ya que siempre se puede recuperar desde el historial de git.
• 26:12
  Skills y validaciónSkills propias: contrato, setup, validación contra el contrato, test (unitarios/integración) y una de drift que revisa periódicamente o en CI/CD que el repositorio siga cumpliendo contrato y specs. OpenSpec trae explore, proposal, apply y archive.
• 31:01
  Flujo OpenSpec en GitHubFlujo estándar: explorar, proponer un cambio (ej. dark mode), aplicar y archivar. La herramienta muestra qué specs siguen activas y su avance.
• 32:51
  Skill de seguridad y OWASPSkill de seguridad que verifica no commitear contraseñas, datasets ni .env; el .env con tokens debe estar fuera del proyecto porque el agente lo leerá. Menciona el OWASP Top 10 (Broken Access Control, Security Misconfiguration, Software Supply Chain Failures) y recomienda fijar versiones y no usar siempre la última.
• 38:37
  Humano en el loopSi el trabajo es para un cliente o alguien depende de él, debe haber una persona que revise y se haga responsable; para prototipos no es necesario.
• 39:32
  Pausa de memes y comunidadInvitación a dar like, suscribirse y unirse al Discord; inicio de la sección de memes.
• 40:16
  Memes data engineer y gastosMeme "¿Qué queremos? Un data engineer", que para Rodo es la primera contratación en un área de datos. Cris cuenta el susto de ver una cuenta de ~10.000 que resultó estar en pesos chilenos.
• 41:45
  Controlando gastos de APIsCris armó un mini tracker de sus APIs y puso prepago y uso máximo en todas las cuentas; algunas plataformas de IA ofrecen límite duro de gasto.
• 42:50
  Límites en la nubeLas nubes grandes permiten observar el gasto pero no limitarlo, y crear un kill switch es complejo; Cris investiga nubes más pequeñas con costos más claros.
• 43:50
  Graph engineering explicadoRodo explica el nuevo término como un grafo de dependencias entre agentes (orquestadores, subagentes, capas que esperan respuestas), algo que considera sentido común y que ya existía en herramientas como n8n.
• 45:46
  Cansancio de buzzwordsCrítica a los influencers que inventan términos nuevos (loop engineering, graph engineering, "fanning") para subirse a la ola; lo importante es la lógica para construir agentes robustos con buen harness.
• 47:51
  Thumbnails y marketingCris dice que los thumbnails exagerados de youtubers le dan "cringe". Rodo señala que algunas imágenes naturales funcionan bien y que la mayoría son falsas.
• 49:40
  Memes y specsMemes sobre "mean/meme driven development" y un dev con mala spec. Rodo recomienda leer siempre la spec generada para asegurarse de que pide lo que uno quiere.
• 51:03
  Susto con GPT EnterpriseCris vio "2 millones de créditos" en una cuenta con límites, hasta notar que la coma y el punto como separadores estaban invertidos y eran 2000.
• 53:05
  GLM vs Sonnet costosRodo usa GLM en un servidor interno de Globant (casi gratis); probó Sonnet 5 en una tarea compleja, le costó 2,7 por un prompt y le rompió el código, así que volvió a GLM. Usa CODA, el harness interno de Globant.
• 54:56
  Filosofía anti perfeccionismoRodo cuenta que en la universidad dejó de ser perfeccionista tras cursos complejos y ahora intenta hacer lo mejor posible sin estresarse si no es perfecto.
• 56:54
  Skills de Matt PocockPresenta skills abiertas de Matt Pocock, de la categoría de ingeniería, que usa al partir un proyecto o cuando está estancado.
• 58:23
  Grilling para ADRsSkill de "grilling": el modelo entrevista sin descanso hasta llegar a un acuerdo; la variante con documentos la usa para generar ADRs. Su definición es muy corta.
• 01:01:01
  Modelos resolviendo matemáticasCris pregunta por la noticia de un modelo de OpenAI que resolvió 10 problemas matemáticos difíciles. Rodo ve el avance como evolución natural, pero insiste en que hay que poder validar la respuesta; Cintia sugiere Lean para verificar pasos.
• 01:06:08
  Wayfinder y plan paraleloWayfinder ayuda cuando el camino al objetivo es difuso: crea un plan dividido en tickets (grilling, research, task) que subagentes trabajan en paralelo.
• 01:07:50
  De demos a producciónEl vibe coding da demos buenas que no sirven en producción. Conviene entregar valor temprano y usar SDD para añadir funcionalidades de forma incremental; los clones no venden, hace falta creatividad.
• 01:11:48
  Demo en CodexRodo inicia la demo en Codex (prestado por Maca) porque no puede mostrar CODA ni sus skills por propiedad intelectual de Globant.
• 01:13:20
  Codex vs VS CodePrefiere harness de terminal o VS Code por su flexibilidad de configuración; ve la app de escritorio de Codex pensada para usuarios que no tocan archivos de configuración.
• 01:15:09
  Contrato con OpenSpecPide a Wayfinder configurar OpenSpec y un contrato para un proyecto Python de clasificación binaria con uv y notebooks Quarto, que luego se desarrolla por features hasta tener un pipeline completo.
• 01:16:50
  Modelos y costosUsa un modelo liviano a propósito para la demo. Comentan que los harness traen skills incorporadas y que usar el modelo más caro para todo sería un gasto excesivo.
• 01:20:22
  Commit y flujoHace el commit de la configuración inicial y deja trabajar al agente mientras muestra un proyecto previo; OpenSpec instala sus skills al inicializarse.
• 01:21:18
  Tickets y subagentesMuestra los tickets de Wayfinder (research, grilling, task) que pasan de abierto a cerrado cuando el subagente termina, y el ADR generado con contexto, alternativas, consecuencias y trazabilidad.
• 01:23:40
  Estructura OpenSpecExplica la carpeta de OpenSpec: changes con las specs en trabajo (proposal, design, tasks) y specs con lo terminado; el movimiento a archive está definido en la skill de archive.
• 01:26:03
  Cómo revisar IARodo lee siempre las specs, ojea design y tasks, verifica que funcione y luego revisa a grandes rasgos el código. Pide limpiar archivos innecesarios; para producción exige leer el código y crear validaciones automáticas.
• 01:29:27
  CierreCris destaca la importancia de especificar bien y leer la spec antes de construir; se discute si las skills mejor construidas justifican la inversión cuando los modelos evolucionan. Raid de Aníbal, resumen del flujo, conversación sobre forecasting de inundaciones y heladas, y despedida.

Palabras clave