Lecciones de una biblioteca sin código: el desarrollo guiado por especificaciones no es una ecuación, es un triángulo

En la era de los agentes de codificación con IA, ver el desarrollo guiado por especificaciones (Spec-Driven Development) simplemente como una línea recta de “especificación → código” es una perspectiva equivocada.

Argumento central

El desarrollo guiado por especificaciones no es una ecuación estática, sino un triángulo dinámico.
Un bucle de retroalimentación donde tres ejes se afectan mutuamente de forma constante:

• Especificación (Spec)
• Código (Code)
• Pruebas (Tests)

Estos tres elementos solo funcionan bien cuando se mantienen sincronizados.

Casos y experimentos principales

• whenwords, una biblioteca sin código creada por Drew Breunig
  → Publicó solo la especificación (Markdown) y 750 pruebas (YAML), sin código, para que un agente de IA generara la implementación
  → Atrajo el interés de Andrej Karpathy + más de 1k estrellas en GitHub + contribuciones activas

Pero en estos experimentos se repiten varios problemas:

• La implementación es rápida, pero apenas sube un poco la complejidad, arreglar una parte rompe otra
• Al final, la mayoría de los proyectos quedan inconclusos y terminan abandonados
• Por buena que sea la especificación, las discusiones sobre cómo implementar siguen apareciendo

¿Por qué un triángulo?

Al crear el código → se descubren ambigüedades/errores en la especificación → se corrige la especificación → hacen falta nuevas pruebas → se vuelve a corregir el código → …
→ Porque este proceso es un bucle que se repite sin parar.

Propuesta de solución: la herramienta Plumb

Plumb, una herramienta CLI creada por Drew

• En cada commit de Git, analiza el registro de conversaciones con el agente y los cambios en el código
• Extrae las decisiones implícitas que tomó el agente → el desarrollador las aprueba
• Las decisiones aprobadas → actualizan automáticamente la especificación
• Ofrece reportes sobre brechas de cobertura entre especificaciones y pruebas
  → Con un “modo de fallo del commit”, obliga a que las decisiones importantes siempre pasen por revisión humana

Contexto histórico

Ahora mismo estamos volviendo a vivir la “crisis del software” de los años 60.
En ese entonces, el código se volvió tan grande que ya no cabía en la cabeza de una persona → de ahí nacieron waterfall, agile y CI/CD
Ahora ni siquiera leer el código es posible → hace falta un proceso nuevo
→ El argumento es que herramientas como Plumb muestran hacia dónde va ese camino.

Conclusión en una línea

Estamos en una era en la que la IA puede generar código a una velocidad enorme,
pero lo verdaderamente difícil es mantener sincronizado el triángulo de especificación-código-pruebas.

https://aisparkup.com/posts/9837