SDD e IA: cómo convertir el desarrollo de software en una factoría ágil

El desarrollo de software siempre ha sido un proceso artesanal. Cada línea de código, cada decisión de arquitectura, cada bug corregido dependía del criterio acumulado en la cabeza de un desarrollador. La IA generativa está cambiando eso de raíz: por primera vez es posible convertir ese proceso en algo parecido a una factoría, donde la especificación manda y la IA ejecuta. Eso es, en esencia, lo que propone el Specification Driven Development (SDD).

En este artículo exploro por qué creo que el SDD es el camino que va a definir la próxima década del desarrollo de software, qué aporta la librería speckit para llegar hasta ahí, cuál es su talón de Aquiles y cómo el bucle de Ralph combinado con skills de prompting bien diseñadas puede ser la pieza que faltaba para cerrar el ciclo con eficiencia real.

¿Qué es el SDD y por qué importa ahora?

El Specification Driven Development parte de una premisa simple: si la especificación es suficientemente precisa, la IA puede encargarse de la implementación. No se trata de pedirle a ChatGPT que "haga una app de recetas". Se trata de producir documentos estructurados —specs— que describan con exactitud qué tiene que hacer el sistema, qué restricciones debe respetar, qué casos de uso cubre y qué errores debe manejar.

El desarrollador deja de ser el que escribe código línea a línea y pasa a ser el que define, valida y refina especificaciones. La IA se convierte en el operario de la factoría. Este cambio de rol tiene implicaciones enormes:

• Velocidad: una spec bien escrita puede producir en minutos lo que antes llevaba horas de codificación manual
• Reproducibilidad: la misma spec, pasada al mismo modelo, produce resultados consistentes y auditables
• Escalabilidad: un único desarrollador puede gestionar múltiples flujos de implementación en paralelo, algo impensable en el modelo tradicional
• Documentación viva: la spec no es un artefacto separado del código; es el origen causal de todo el sistema

La IA actual —modelos como Claude, GPT-4o o Gemini— ya tiene la capacidad técnica de generar código de producción de calidad razonable. El cuello de botella no está en el modelo; está en cómo le damos el contexto. Y ahí es donde entra speckit.

Speckit: la librería que te amuebla la cabeza

Speckit es una librería de herramientas y plantillas diseñada para estructurar el proceso de especificación en proyectos SDD. Su propuesta de valor es clara: te da un vocabulario común, unas plantillas probadas y unos prompts predefinidos para que el paso de "idea en la cabeza del developer" a "spec consumible por la IA" sea predecible y repetible.

Lo que speckit hace especialmente bien es forzarte a pensar en términos de contratos: qué recibe cada componente, qué devuelve, qué invariantes debe mantener. Eso obliga a aclarar supuestos que normalmente quedan implícitos en el código y que luego son fuente de bugs y malentendidos. Si alguna vez has usado speckit para arrancar un proyecto desde cero, sabes que la disciplina que impone al inicio ahorra muchos quebraderos de cabeza después.

Usé speckit para estructurar parte de mi colección de proyectos indesia-all, un monorepositorio que agrupa varias ideas de producto en fases tempranas. La sensación inicial es de productividad disparada: arrancas con una spec, la pasas al modelo y en minutos tienes un esqueleto funcional que de otra forma habría costado una tarde entera.

El problema que nadie menciona: el contexto

Aquí viene la trampa. Los modelos de lenguaje tienen un límite de contexto, y dentro de ese límite, no todo el contexto vale lo mismo. Cuanto más rellenas el prompt con información que el modelo no necesita para la tarea concreta, más probabilidad hay de que pierda el hilo, genere código que ignora parte de los requisitos o simplemente produzca respuestas más genéricas.

Speckit, en su versión más ortodoxa, tiene un vicio estructural en este sentido: sus prompts predeterminados son muy generosos en contexto. La plantilla estándar de speckit incluye headers de proyecto, secciones de arquitectura global, convenciones de nombrado, restricciones de stack y un largo etcétera que son útiles para un humano que lee la spec, pero que para el modelo representan tokens que compiten con la instrucción real.

El resultado en la práctica: el modelo recibe tanta información sobre el ecosistema global del proyecto que le cuesta concentrarse en el problema puntual que tienes que resolver ahora. Y cuando las ventanas de contexto se llenan —lo que ocurre rápido en proyectos medianos—, el modelo empieza a "olvidar" partes de la spec que estaban al principio del prompt.

• Respuestas más largas de lo necesario, llenas de código boilerplate que no añade valor
• Inconsistencias entre diferentes partes del código generado porque el modelo perdió alguna restricción de la spec
• Mayor necesidad de revisión y corrección manual, lo que anula parte del beneficio de la automatización

El bucle de Ralph: menos contexto, mejores resultados

El bucle de Ralph es un patrón de trabajo con IA que propone lo contrario a la filosofía de "más contexto es mejor". Su premisa es que el flujo de desarrollo con IA funciona mejor cuando se organiza en iteraciones pequeñas y muy focalizadas, donde cada llamada al modelo tiene exactamente el contexto necesario para la tarea concreta, y nada más.

El ciclo en su forma más básica tiene tres fases:

• Define: delimita con precisión quirúrgica el problema que vas a resolver en esta iteración. No "implementa el módulo de autenticación"; sino "genera la función que valida el token JWT y devuelve el payload tipado en TypeScript"
• Genera: pasa al modelo exclusivamente el contexto relevante para esa tarea —los tipos implicados, la interfaz esperada, el contrato de error— más la instrucción precisa
• Valida e integra: revisa el output, lo ajusta si hace falta, lo integra en el código existente y toma nota de lo que has aprendido para refinar la siguiente iteración

La clave del bucle de Ralph no es la tecnología; es la disciplina de descomposición. Obligarte a fragmentar el problema antes de escribir el prompt te fuerza a entenderlo mejor tú mismo, lo que a su vez mejora la calidad de la instrucción y, por tanto, la del resultado.

Skills genéricas: el contexto reutilizable que sí vale la pena guardar

El bucle de Ralph por sí solo resuelve el problema del contexto excesivo, pero introduce uno nuevo: tienes que escribir bien el prompt cada vez, desde cero. Si trabajas en varios proyectos o con varios stacks, eso puede ser tan costoso como el problema original.

La solución es construir una biblioteca de skills genéricas: fragmentos de contexto altamente reutilizables que encapsulan conocimiento transferible entre proyectos. No son prompts de sistema globales que se inyectan siempre; son bloques de instrucción que el developer activa conscientemente cuando los necesita.

Ejemplos de skills que merece la pena tener en biblioteca:

• Skill de tipos estrictos: instrucción para que el modelo genere código con tipado exhaustivo en TypeScript o Kotlin, sin any ni casts implícitos
• Skill de manejo de errores: patrón concreto para Result types o sealed classes según el lenguaje, con exhaustividad en el when/switch
• Skill de tests unitarios: instrucción para generar tests con el framework del proyecto, cubriendo el happy path, el error path y los edge cases
• Skill de arquitectura limpia: restricciones de capas y direcciones de dependencia para que el código generado respete la arquitectura del proyecto

La diferencia con speckit es sutil pero importante: las skills genéricas son opt-in. Las incluyes en el prompt solo cuando son relevantes para la tarea que tienes entre manos. Un prompt para generar una función de utilidad pura no necesita la skill de arquitectura; un prompt para generar un caso de uso sí. Ese control granular es lo que mantiene el contexto limpio y el modelo enfocado.

SDD en la práctica: indesia-all como caso real

Todo esto no es teoría. En mi colección de proyectos indesia-all experimenté con diferentes aproximaciones al SDD: primero con el flujo estándar de speckit, luego combinando speckit con el bucle de Ralph y un conjunto reducido de skills genéricas.

La diferencia en calidad de output fue significativa. Con el flujo speckit puro, los módulos generados eran funcionalmente correctos pero tendían a ser más verbosos de lo necesario y a ignorar alguna convención del proyecto que estaba enterrada en la parte larga de la spec. Con el bucle de Ralph y skills opt-in, cada tarea producía código más ajustado, más fácil de revisar y que se integraba mejor con el resto del sistema porque el modelo tenía solo el contexto que importaba en ese momento.

El aprendizaje más valioso fue que el tiempo ahorrado en la generación de código se puede perder fácilmente en la revisión si el prompt no está bien calibrado. Un modelo con demasiado contexto no genérico produce código que tienes que leer dos veces para estar seguro de que hace lo que debe. Un modelo con contexto quirúrgico produce código que puedes integrar con confianza en mucho menos tiempo.

El desarrollador como arquitecto de specs

Lo que el SDD cambia profundamente no es el volumen de trabajo; es la naturaleza del trabajo. En el modelo tradicional, el valor del desarrollador está en su capacidad de escribir código correcto. En el modelo SDD, el valor está en su capacidad de descomponer problemas complejos en tareas atómicas, especificarlas con precisión y saber cuándo el output de la IA es suficientemente bueno.

Esas tres capacidades son genuinamente difíciles. No se aprenden en un fin de semana. Y son exactamente las que diferencian a un buen ingeniero de software de alguien que solo sabe usar un editor de código. La IA no elimina la necesidad de criterio técnico; la eleva a una capa de abstracción más alta.

El camino que viene

Creo que en los próximos dos o tres años vamos a ver cómo el SDD pasa de ser una práctica de early adopters a convertirse en el estándar de facto para equipos que quieran mantenerse competitivos. Los modelos seguirán mejorando, las ventanas de contexto seguirán creciendo y las herramientas de especificación se volverán más sofisticadas.

Pero los principios que hacen que el SDD funcione bien hoy —especificaciones precisas, contexto mínimo suficiente, iteraciones pequeñas, skills reutilizables— van a seguir siendo válidos independientemente de cuánto mejore la tecnología subyacente. Porque en el fondo no son principios de prompting; son principios de ingeniería de software aplicados a un entorno donde la IA actúa como implementador.

La factoría de software que promete el SDD no es una cadena de montaje ciega. Es una colaboración entre humanos que piensan y máquinas que ejecutan, donde el resultado es mejor que lo que cualquiera de los dos podría producir solo. Y eso, en el fondo, es lo que siempre hemos intentado construir con cada nueva herramienta que ha aparecido en nuestra profesión.