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üedad, 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.
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.
