SDD Me parece bien pero no lo uso

Spec Driven Development me recuerda a esos sistemas de productividad donde terminás gastando más energía en mantener el sistema que en el trabajo real. La idea es sólida. La ejecución en la diaria es otra historia.

Qué es SDD, brevemente

Spec Driven Development propone que antes de pedirle a un modelo que genere código, construyas una especificación detallada: comportamientos esperados, restricciones, casos de uso. El modelo trabaja contra esa spec como contrato. En teoría, el output es más predecible y los errores se detectan antes.

No es una mala idea. Es una idea que viene de un problema real: los modelos producen resultados mejores cuando el input es claro. El debate es si la manera de lograr ese input claro requiere el proceso que SDD propone.

El problema del overhead

Cuando lo intenté en proyectos reales, el patrón fue siempre el mismo: la spec tardaba más en armarse que la feature que quería construir. Y eso incluye el costo de tokens de cargar esa spec en cada conversación con el modelo.

No es un costo marginal. Una spec bien armada puede pesar varios miles de tokens. En proyectos con muchas iteraciones, ese contexto se carga una y otra vez. El costo se acumula, y lo más importante es que el tiempo de construirla y mantenerla también.

Para trabajo individual y ágil, ese overhead cambia completamente la ecuación.

Lo que aprendí del enfoque “grill-me”

Matt Pocock tiene un skill llamado “grill-me” que funciona de manera distinta: en lugar de que vos construyas la spec, el modelo te hace preguntas para construirla con vos. Es conversacional, adaptable, y respeta lo que ya sabés.

Adapté esa idea a algo todavía más simple. Armo un archivo de texto con lo que quiero construir, le pido al modelo que identifique los puntos ambiguos, respondo sus preguntas, y con eso tenemos suficiente claridad para trabajar. El proceso entero toma minutos, no la media hora o más que puede llevar armar una spec formal.

La diferencia clave es la dirección del esfuerzo. En SDD, yo construyo el contexto para el modelo. En el enfoque conversacional, el modelo me ayuda a construir el contexto conmigo. El segundo es más eficiente porque el modelo sabe qué necesita saber para producir un buen output. Yo no siempre lo sé de antemano.

Los modelos frontier cambian el cálculo

Parte del razonamiento detrás de SDD viene de una época en que los modelos necesitaban inputs muy específicos para producir outputs útiles. Esa limitación ya no es tan pronunciada.

Los modelos frontier actuales pueden manejar ambigüedad razonable, hacer suposiciones explícitas, pedir aclaraciones en contexto, y ajustar en función del feedback. Son interlocutores, no simplemente ejecutores de instrucciones precisas. Diseñar un proceso pesado asumiendo que el modelo no puede navegar cierta ambigüedad subestima lo que esos modelos pueden hacer hoy.

El input importa mucho. El mejor camino hacia un buen input no siempre es el más formal.

Cuándo SDD sí tiene sentido

Ser justo con la técnica: SDD probablemente encaja bien cuando el proyecto es grande, el equipo es múltiple, y los requisitos necesitan acuerdo explícito entre varias personas antes de escribir una línea de código. En esos contextos, la spec no es solo guía para el modelo. Es un documento de alineación entre personas, y eso cambia su valor completamente. Aunque con una condición: si el proceso de alineación termina tardando más que construir el producto, el problema sigue siendo el mismo.

Pero eso es un caso específico. Aplicarlo como práctica general para trabajo individual y proyectos acotados es sobreadaptar una solución a un problema que en esa escala no existe de la misma manera.

El criterio que me quedó

El proceso tiene que costar menos que el problema que resuelve. Si paso más tiempo construyendo la spec que desarrollando lo que quiero, el proceso perdió. Si el archivo de texto y diez minutos de preguntas del modelo me dan el 80% de la claridad con el 20% del esfuerzo, eso es lo que voy a usar.

SDD es interesante. Para mi flujo de trabajo actual, es demasiado caro.