spec-driven-development-spectrum

II. Dependencias Mínimas

Preferir la biblioteca estándar de Python. Una dependencia de terceros PUEDE ser añadida solo cuando elimina claramente más complejidad de la que introduce, y DEBE ser registrada en el archivo de dependencias del proyecto (por ejemplo, requirements.txt o pyproject.toml).

Una política de dependencias, escrita en el lenguaje DEBE/PUEDE de un estándar formal, a partir de un aviso donde
dije que no tenía restricciones. No está en
la plantilla local ni en el archivo de habilidades — pero el Artículo I de los nueve artículos constitucionales de GitHub
sí pide implementaciones *"con límites claros y **dependencias mínimas**."* Así que es consistente con la filosofía publicada en lugar de inventada en el momento. No puedo decirte el
mecanismo, solo lo que entró y lo que salió.

Una ejecución, una tarea trivial, y no me costó nada porque nada estaba en juego. El caso de Punnen
muestra lo que este tipo de sesgo cuesta cuando el problema es lo suficientemente difícil como para que esté equivocado. El mío solo
muestra que aparece sin ser solicitado — lo que importa porque, como señala Böckeler, la constitución de Spec Kit es
su **banco de memoria**, *"un archivo de reglas muy poderoso"* aplicado a cada cambio. Una preferencia no solicitada no se sienta en un documento que vas a descartar. Se convierte en una regla permanente.

## Ambos recurrieron a los años 90

Aquí está lo que me convenció de que esto vale la pena tomarlo en serio en lugar de descartarlo o evangelizarlo.

Böckeler, que trabajó en desarrollo dirigido por modelos al principio de su carrera, ve MDD:

> Me pregunto si la especificación como fuente, e incluso el anclaje de especificaciones, podrían terminar con las desventajas de ambos
> MDD y LLMs: inflexibilidad y no determinismo.

Punnen, con veinte años en telecomunicaciones, recurre independientemente a Rational Rose y UML — *"tratados como
la bala de plata de su década: dibujar cuadros, flechas y diagramas, y la herramienta los convertiría mágicamente
en código funcional."*

Ninguno cita al otro. Diferentes herramientas, diferentes problemas, diferentes países. Ambos aterrizan en
la misma era: la última vez que nuestra industria creyó que un documento podría ser la fuente y el código la
salida.

Böckeler es cuidadosa con la comparación — *"No tengo nostalgia por mi experiencia con MDD."* Su
punto es que las herramientas de hoy eliminan las partes que hicieron que MDD fuera doloroso: ya no necesitas un lenguaje de especificación especial o un generador construido para un propósito. Lo que se pregunta es si el intercambio es bueno,
ya que el antiguo enfoque al menos producía la misma salida cada vez.

Punnen nombra la trampa subyacente:

> La especificación tiene que ser muy rigurosa en primer lugar, pero para volverse rigurosa necesita
> ser refinada iterativamente junto con el código generado.

Un Catch-22, en otras palabras: según su relato, no puedes escribir una especificación rigurosa para un problema que
aún no entiendes, y la comprensión llega mientras construyes. Rastreó el pensamiento hasta Fred Brooks, hace cuarenta años: *"las descripciones de una entidad de software que abstraen su complejidad a menudo abstraen su esencia."*

## Donde discrepan — y por qué importa para ti

En una pregunta, estos dos están en oposición directa.

Böckeler, generando código repetidamente a partir de una especificación de Tessl: *"He visto el no determinismo en
acción… un ejercicio interesante iterar sobre la especificación y hacerla cada vez más específica para
aumentar la repetibilidad de la generación de código."*

Punnen: *"Este no es un problema importante en la práctica. Los marcos de SDD actúan como avisos estructurados, y
los modelos modernos producen salidas altamente consistentes cuando son guiados por ellos."*

GitHub toma el lado de Punnen y va más allá, afirmando *"Consistencia a través de LLMs: Diferentes modelos de IA
producen código arquitectónicamente compatible."* No el mismo modelo dos veces — diferentes modelos.
No se ofrece evidencia.

Dos ingenieros experimentados, conclusiones opuestas, una afirmación de proveedor más fuerte que cualquiera de las dos, y no hay un número entre ellos. Importa más de lo que parece. Mantener una especificación y su código en sincronía — la idea de especificación anclada — depende de pruebas automatizadas para detectar la deriva. Eso funciona para código determinista, donde la misma entrada da la misma salida.

Apúntalo a una característica de LLM y la verificación deja de funcionar. `assert response == expected` no significa nada cuando la respuesta difiere en cada ejecución. A menos que cambies las pruebas por **evaluaciones**, donde cada criterio de aceptación se convierte en una afirmación puntuable: ¿lo clasificó correctamente, devolvió JSON válido contra el esquema, se negó cuando debería haberlo hecho?

Ese puente sobrevive al no determinismo, y es el arnés que he pasado varios tutoriales construyendo
en la API de Inferencia WEC. También hace que el desacuerdo sea *medible*: escribe la especificación, convierte sus
criterios en afirmaciones de evaluación, y ejecútalas a lo largo de una sesión larga para ver si la adherencia se mantiene
o se desvanece.

Esa es la próxima publicación.

## Si vas a intentarlo

Las conclusiones prácticas de Punnen son mejores que cualquier cosa que yo inventaría, y se las ganó:

- **Trata las reglas de "sin nuevas dependencias" como sesgos, no como neutrales.** Si la respuesta correcta necesita una dependencia,
  tendrás que defenderla — el marco no lo hará.
- **Trata los criterios de éxito generados como suposiciones** hasta que un ingeniero los ratifique. El agente te los citará más tarde como si fueran medidos.
- **Lee cada menú de aclaración como una propuesta de diseño disfrazada.** Si la opción que deseas no está
  listada, ese es el fallo — no un aviso para elegir la mejor de tres.
- **Resiste durante la aclaración, no durante la planificación.** Los planes son largos, internamente consistentes y
  agotadores de revisar.

Una de mis propias: **escribe tus principios con una fecha y una justificación, para que un tú posterior pueda
superarlos.** IBM sugiere tratar las especificaciones como *"artefactos versionados apilables, como registros de decisiones de arquitectura"* — y un ADR es algo que puedes marcar como superado. La metodología llama a estos principios inmutables. Tu problema no lo es.

Agrega la prueba de costo de IBM, la línea práctica más aguda que cualquiera de ellos escribió: *el costo de refinar la
especificación siempre debe ser menor que el costo de corregir malentendidos en la implementación. Cuando
ese equilibrio se invierte, deja de pulir y comienza a construir.*

Y verifica la organización antes de instalar. El repositorio que circula en LinkedIn es un **fork** con
once estrellas; el proyecto real es [`github/spec-kit`](https://github.com/github/spec-kit). Eso importa más aquí que para la mayoría de las herramientas: el trabajo de Spec Kit es escribir archivos de instrucciones que tu agente luego obedece, y en la primera ejecución apruebas esa carpeta con una pulsación de tecla sin haberlas leído.

---

¿Así que reemplaza el código vibe? No de la manera que sugiere la propuesta. No ayuda cuando no entiendes tu problema — ayuda cuando lo entiendes y lo comunicas mal. Esos son fallos diferentes, y solo uno de ellos tiene una plantilla.

Ambos encontraron un valor real en las fases iniciales — Punnen califica el paso de aclaración como el más útil de todos — y ambos encontraron que los artefactos parecían más autoritarios exactamente donde las decisiones subyacentes eran más arbitrarias. Punnen: *"son más peligrosos cuando parecen más rigurosos."*

Böckeler recurre a una palabra compuesta alemana para ello — **Verschlimmbesserung**. Hacer algo peor en el intento de hacerlo mejor.

La parte difícil nunca fue escribir el código.