Specification-Driven Development: un nuevo orden en el desarrollo de nuevo software con IA

Specification-Driven Development: un nuevo orden en el desarrollo de nuevo software con IA

Dime de dónde vienes y te diré para dónde vas

En el pasado “soñábamos” con pasar de los diseños de software modelados en alguna herramienta de “cuarta generación” al código sin tener que escribirlo. Mis primeros intentos de generar software datan de 1987 cuando trabajé con mi profesor de algoritmos y luego de sistemas expertos Fabián Ríos y mi amigo Fabio Ruíz en un compilador para el lenguaje LEXICO (creado por Fabián) para el cual también hicimos algunos traductores a los lenguajes populares de la época: C, Pascal, C++ y BASIC, entre otros, y creamos un entorno de programación que permitía a los nuevos estudiantes de Ingeniería de Sistemas correr y probar sus programas escritos en  LEXICO.

Con Fabián y Fabio y otros amigos fundamos el entonces Equipo de Ambientes de Programación, dedicado a estos menesteres, en los que también hicimos nuestros primeros pinitos en inteligencia artificial con el lenguaje PROLOG y con Lisp. De hecho, Fabián escribió el primer intérprete de LEXICO en PROLOG y nosotros lo probamos, mucho antes de construir el compilador.

En los 90 pasamos por las herramientas generadoras de código a partir de diagramas, en los 2000 estos diagramas eran descritos usando lenguaje UML, incluyendo los casos de uso, una técnica de especificación de requisitos funcionales y no funcionales que usábamos con la metodología RUP. Fueron intentos incipientes. Normalmente teníamos que escribir el 99,9 % del código fuente, o todo.

Escribí miles de líneas de código en más de una docena de lenguajes de programación de todo tipo. Pero dejé de programar hace 2 décadas, aunque he seguido acompañando equipos de desarrollo de software, incluso de vez en cuando todavía me llaman para resolver algún problema de rendimiento en bases de datos relacionales.

Hoy las cosas han cambiado con la inteligencia artificial. Es evidente que la tarea principal del programador cambió. De hecho, ya hemos sido advertidos de que algunas herramientas de IA podrán reemplazar a los programadores puros y duros en muy poco tiempo. Por ejemplo, y a propósito de compiladores, en Anthropic acaban de construir un compilador C con Opus 4.6 usando equipos de agentes IA en solo dos semanas, algo que dice mucho sobre el futuro del desarrollo autónomo de software. Nuestros amigos de Anthropic dicen que hasta el 90 % de su código será escrito por sus nuevas herramientas en los próximos tres a seis meses. Es solo cuestión de “cuando” el resto de nosotros lo hará. Pero llegaré a esto un poco más tarde.

El caso de los requisitos de software, los casos de uso y las historias de usuario

Cuando de desarrollar software se trata, mi mayor interés siempre fue la comunicación. Primero entre personas y luego entre personas y las máquinas. Por eso este asunto de los requisitos en todos sus colores, tamaños y sabores siempre ha estado en la palestra de mis prácticas favoritas. Y durante las tres últimas décadas he estudiado el asunto a fondo, he realizado miles de experimentos, pero también he ayudado a implementar cientos de productos de software en algunas de las más grandes empresas de Colombia y algunas de Latinoamérica.

En los 90 con requisitos a la usanza tradicional, grandes documentos de texto en “lenguaje natural”. Hice lo mejor que pude. Pero desde finales de esa década y toda la siguiente usé casos de uso. Escribí, revisé, corregí y ayudé a escribir miles de casos de uso y también diseñé, planteé arquitecturas de software, programé y probé a partir de ellos. Escribí mucho sobre el tema en mi blog Gazafatonario. Finalmente, toda esta experiencia quedó consignada en mi libro Asuntos de la Ingeniería de Software, Volumen II, aunque todos los artículos originales siguen en mi blog.

Los casos de uso eran una buena práctica, aunque bastante exigente para todos los involucrados, incluyendo el mismo usuario. Así que entré en la era “ágil” y empecé a trabajar con historias de usuario. Fui a la fuente. Extreme Programming. Lo primero que supe fue que se plantearon originalmente de manera escueta, diciendo que “son como casos de uso”, en la primera edición del libro de Kent Beck. Me pareció natural y rápidamente adopté e implementé el concepto en los equipos que acompañaba.

También, casi todo esto quedó registrado en los libros que publicara con mi gran amigo Jorge Abad, Historias de usuario: una visión pragmática, Volumen I y Volumen II. Y también, casi todo el material de estos libros pueden leerlo en nuestros blogs. El de Jorge es Lecciones Aprendidas.

Distintas técnicas, mismo objetivo: lograr que todos los involucrados entiendan lo que quiere el usuario y conseguir que todos entiendan exactamente lo mismo. Siempre fue difícil. Aunque con el enfoque ágil abreviamos los tiempos de desarrollo y entrega, en el proceso la información transmitida igual se corrompía. Lo solucionábamos más rápido, pero el retrabajo siempre estaba a la orden del día.

No me malentiendan. Yo sí puedo decir que tanto aquellas técnicas como estas son muy buenas y funcionan, con los equipos donde participé pusimos en producción muchos sistemas de información que hoy se continúan usando. De hecho, incluso los casos de uso, ni hablar de las historias de usuario, hoy reciben un nuevo aire con esto de la Spec-Driven Development con IA, que es el asunto que nos convoca.

Entra la inteligencia artificial generativa

Sé que me extendí en la historia, pero para mí era muy importante contarles de dónde vengo, ahora sí, para decirles hacia dónde voy.

Así que me voy a saltar toda la perorata de los últimos tres años, la IA no viene a reemplazarte y todo ese blablablá ampliamente difundido, comentado y embutido hasta la saciedad en nuestras mentes, e iré directo al punto: allí estaba la herramienta con la que había soñado hace cuatro décadas para generar código, pero los primeros intentos no funcionaron. Por muy buenos que eran los “prompts”, no salía nada más allá de lo que yo mismo podía hacer con otras herramientas.

Y empecé a iterar, a refinar, a usar la IA como colaboradora de primera categoría. A descargar en ella todo lo que creía que era útil para que pudiera construir mejores productos, al menos, mejores MVP. Y entonces hace por allá un año escuché o leí de SDD y las cosas tomaron su curso natural, en el fondo, era lo que había estado haciendo en los dos últimos años, alimentar o instruir a la IA con especificaciones más precisas, no ambiguas… ¡Hey, esperen! Esto me recuerda algo:

• Instrucciones legibles
• Otra información relevante que posea alguna influencia sobre esas instrucciones
• Identificación unívoca de cada instrucción
• Instrucciones correctas
• No ambiguas
• Completas
• Consistentes
• Verificables
• Modificables
• Trazables

Es difícil lograr todo eso de una buena vez, alguna vez, pero hay que hacer el mejor trabajo posible. Recordé aquel modelo de la IEEE 830 de 1998, el estándar de requisitos según el prestigioso Instituto de Ingeniería Eléctrica y Electrónica, bajo el cual escribí y modelé requisitos con distintas técnicas y en diferentes formatos durante muchos años.

Pero también empecé a hablarle a la IA de usabilidad, de confiabilidad, de desempeño, de capacidad de soporte e, incluso, de restricciones de diseño y requisitos de implementación. Y entonces también recordé ese otro modelo FURPS+ que complementó aquel estándar. ¡Ah, y la arquitectura! Ya llegaremos a ese nivel.

De todo esto ya escribí y publiqué. Por eso era necesario contar toda aquella historia previa. Lo de ahora es “empaquetar” todo eso en una especificación estructurada, práctica y sistemática y entregársela a una IA para que genere el código que queremos, el producto que necesitamos. Eso es, más o menos, Specification-Driven Development o SDD y no me voy a desgastar nombrándola en español como hice antes muchas veces con incontables conceptos que nacieron en inglés.

“Hola, mundo” con SDD

Un ejemplo para terminar. Así empecé hace tres décadas escribiendo sobre requisitos y casos de uso, y hace década y media sobre historias de usuario. Vendrá mucho más sobre esto, pero los dejaré con un ejemplo breve. La gran diferencia ahora es que podemos tener el resultado de esa especificación en minutos, cuando no en segundos. Y podemos iterar, ajustar, repetir, y en medio de todo ello, verificar, en muy muy muy corto lapso de tiempo. Veamos el ejemplo.

Hoy por hoy, escribir un mensaje en WhatsApp o un correo electrónico se ha convertido en algo común, pero nunca estás seguro de si suenas demasiado agresivo, muy tímido o poco profesional. La solución: una caja de texto donde escribes o pegas tu mensaje y la IA te ofrece 3 versiones instantáneas: una «Directa y Ejecutiva», otra «Empática y Amigable» y una más «Mínima (estilo Gen-Z)». ¿Te gusta la idea? A mí sí. Es un “Sintonizador de Tono Comunicacional”. Les dije que este asunto de la comunicación entre personas está en mi ADN. Aquí vamos entonces.

Una Specification para IA incluye (o debe incluir) la visión de lo que quieres:

Una herramienta de productividad diseñada para eliminar la ansiedad en la comunicación digital. Permite a los usuarios transformar mensajes crudos o mal estructurados en versiones optimizadas según el contexto social, asegurando que el mensaje sea efectivo y el tono sea el adecuado.

Incluso puedes probar eso como un prompt directo a tu IA favorita. Las posibilidades son infinitas. Pero con eso no vas a obtener lo que quieres, al menos no de inmediato. Ni siquiera en las mejores herramientas IA que existen hoy para crear productos digitales.

Una Spec también incluye la Estructura de la Interfaz (UI). Vamos con una parte de esta:

A. Panel de Entrada
Área de Texto: Un `textarea` sin bordes pesados, con una tipografía Serif o Sans-serif elegante.
Contador de caracteres: Discreto en la esquina inferior.
Botón de Acción: "Sintonizar Mensaje" (Efecto de brillo suave al pasar el mouse).

B. Panel de Resultados
Un grid de 3 columnas (o 1 columna en móvil) que muestra tres variantes:
1. Variante: Directa & Ejecutiva
Color: Azul Cobalto (Focus en eficiencia y claridad).
Badge: "Profesional".

Como esta App usa IA necesitamos un “system prompt” mínimo viable. Es otra parte de la Spec. Les dejaré esta sección aquí completa:

3. Lógica de Inteligencia Artificial (Prompt de Sistema)
Para generar los resultados, la aplicación debe enviar este contexto al LLM:
> "Actúa como un experto en comunicación asertiva y psicología organizacional. Tu tarea es reescribir el mensaje del usuario en 3 versiones estrictamente diferenciadas.
> Reglas:
> 1. Directo & Ejecutivo: Elimina rellenos, ve al grano, usa lenguaje formal pero activo. Ideal para correos a superiores o clientes.
> 2. Empático & Amigable: Usa lenguaje cálido, validación de sentimientos y suaviza peticiones. Ideal para equipos cercanos o situaciones delicadas.
> 3. Minimalista: Reduce el mensaje a su esencia absoluta (máximo 15 palabras). Ideal para Slack, WhatsApp o equipos rápidos.
> 
> Output: Devuelve un JSON con las llaves: `profesional`, `amistosa`, `minimalista`."

Sí, por supuesto puedes probar el prompt directamente en la IA de turno.

Pero la Spec también puede incluir requisitos técnicos e interacciones, como “Cada tarjeta de resultado debe tener un botón de ‘Copiar’”, ¿lo recuerdan? Precisión, cero ambigüedades, completitud, etcétera, etcétera; también pueden tener historias de usuario o hasta casos de uso, pero eso será motivo de próximos artículos; incluso puede tener y es bueno que tengan instrucciones para la IA que se va a usar. Y mucho más.

Todo esto lo almacenan en un documento Markdown (.md) y se lo pasan a la IA. Esta vez usé Lovable, es apenas el “Hola, mundo” de SDD. Les dejo el documento completo para su descarga.

[Enlace a la especificación]

El resultado, en modo oscuro y colores vibrantes, dos de los requisitos precisos, consistentes y verificables que encontrarán en la Spec completa:

Me cuentan cómo les va corriendo la Spec que les dejé. En el próximo artículo les hablaré más en detalle de la anatomía de una Spec y avanzaremos en esto.

Hace poco, mi también gran amigo Daniel Ramírez decía en un artículo que “La vibra no escala, la arquitectura sí” y preguntaba al final: “¿En qué punto una automatización deja de ser una PoC y se convierte en un sistema que requiere una arquitectura de verdad?” Bueno mi estimado Daniel, SDD es un paso, uno grande, en esa dirección.

Déjenme saber en el foro qué se les ocurre que hagamos con esto.

Lucho Salazar

Villa de Nuestra Señora de La Candelaria de Medellín, 5 de febrero de 2026

39 años después.