Spec-Driven Development: casi 40 años después, volvemos a empezar por la especificación

Estoy leyendo un libro corto sobre Spec-Driven Development, una forma de desarrollar software con Inteligencia Artificial que propone algo que, a primera vista, parece bastante moderno.

En lugar de empezar escribiendo código, se comienza describiendo qué sistema queremos construir.

Se definen los requerimientos, el modelo de entidades, los casos de uso, las reglas, las restricciones y los criterios que debe cumplir la aplicación. Esa especificación —la Spec— pasa a ser uno de los principales artefactos del proyecto.

A partir de ella, los agentes de IA pueden generar código, pruebas, documentación y realizar verificaciones para comprobar que lo implementado cumple con lo especificado.

Mientras leía esto tuve una sensación curiosa: esto me resulta muy conocido.

Mi proyecto de grado, a finales de los 80

A finales de los años 80 hice mi proyecto de grado en la Facultad de Ingeniería de la Universidad de la República.

En aquella época, antes de comenzar a programar, nos exigían preparar una carpeta bastante importante.

Allí debíamos documentar, entre otras cosas:

• los requerimientos que debía cumplir el sistema;

• el modelo Entidad-Relación;

• los diagramas de flujo;

• el diccionario de datos;

• y diferentes aspectos del funcionamiento esperado de la aplicación.

Después de definir todo eso, comenzaba la programación.

No teníamos agentes de IA.

No teníamos GitHub.

No teníamos IDEs inteligentes.

Y, obviamente, tampoco teníamos modelos de lenguaje capaces de transformar una descripción en lenguaje natural en miles de líneas de código.

Pero el principio era sorprendentemente parecido:

primero intentar entender y especificar el problema; después construir la solución.

Han pasado casi 40 años.

Las herramientas cambiaron de una forma difícil de imaginar en aquel momento, pero una parte fundamental de la ingeniería de software sigue siendo la misma.

Lo que cambia con la IA

Durante buena parte de la historia del software existió un problema muy importante entre la especificación y el producto terminado.

Podíamos escribir excelentes requerimientos, modelos y documentos de diseño, pero después alguien tenía que transformar manualmente todo eso en código.

Ese proceso era lento, costoso y propenso a errores.

Además, la documentación y el software inevitablemente comenzaban a separarse.

Se modificaba el código y no se actualizaba el documento.

Se modificaban los requerimientos y la implementación quedaba atrasada.

Después de algunos años, nadie sabía exactamente cuál de los dos representaba el verdadero funcionamiento del sistema.

La IA puede modificar radicalmente esa ecuación.

Si un agente es capaz de leer una especificación suficientemente precisa y generar a partir de ella la implementación, los tests y parte de la documentación, el costo de traducir una especificación a software ejecutable disminuye enormemente.

Y eso hace que la calidad de la especificación pase a ser todavía más importante.

El cuello de botella se mueve

Hasta hace poco, una gran parte del esfuerzo de un desarrollador estaba dedicada a explicarle a una computadora, mediante un lenguaje de programación, exactamente qué debía hacer.

Los agentes de programación están automatizando una parte creciente de ese trabajo.

Pero eso no significa que desaparezca la ingeniería.

El cuello de botella simplemente se desplaza.

Cada vez será menos importante nuestra capacidad de escribir rápidamente cientos de líneas de código y más importante nuestra capacidad de definir:

qué problema queremos resolver,

qué comportamiento esperamos,

qué reglas deben cumplirse,

qué situaciones excepcionales existen,

cómo se relacionan los datos,

qué restricciones de arquitectura y seguridad debemos respetar,

y cómo podemos comprobar objetivamente que la solución es correcta.

En otras palabras:

programar puede volverse más fácil; especificar bien sigue siendo difícil.

De código como fuente a especificación como fuente

Durante décadas consideramos al código fuente como la representación definitiva del sistema.

Los documentos podían explicar el sistema, pero finalmente la verdad estaba en el código.

El Spec-Driven Development plantea una posibilidad diferente.

La especificación puede transformarse progresivamente en la fuente de verdad del sistema.

Podemos imaginar un ciclo como este:

Requerimientos → Modelo → Casos de uso → Criterios de aceptación → Código → Tests → Verificación

Pero existe una diferencia fundamental con el proceso que utilizábamos hace décadas.

Ahora gran parte de las últimas etapas puede ser ejecutada por agentes.

Incluso podemos pedirle a otro agente que revise si la implementación realmente cumple con la especificación original.

Eso cambia mucho más que la velocidad de programación.

Cambia qué artefacto consideramos realmente valioso.

Algo que quienes usamos desarrollo basado en modelos conocemos bien

Para quienes hemos trabajado durante años con herramientas de desarrollo basado en modelos, esta idea tampoco resulta completamente nueva.

Una herramienta como GeneXus parte de una representación de más alto nivel del sistema y genera a partir de ella implementaciones para distintas tecnologías.

La idea fundamental siempre fue intentar subir el nivel de abstracción.

En lugar de especificar cada instrucción que debe ejecutar una computadora, describimos el sistema en un lenguaje más cercano al problema y dejamos que una herramienta realice parte de la traducción hacia la tecnología concreta.

Los agentes de IA llevan esta idea todavía más lejos.

Ahora parte de esa especificación puede escribirse directamente en lenguaje natural, Markdown, ejemplos, modelos de datos, reglas y criterios de aceptación.

Ya no se trata solamente de generación de código.

Se trata de aumentar nuevamente el nivel de abstracción desde el cual construimos software.

La IA no elimina la necesidad de especificar

Existe una tentación comprensible cuando vemos lo rápido que un agente puede generar una aplicación.

Podemos escribir:

"Haceme un sistema que gestione clientes, facturas y pagos."

Y pocos minutos después tenemos algo funcionando.

Es extraordinariamente útil para experimentar y prototipar.

Pero a medida que el sistema crece comienzan las preguntas.

¿Qué significa exactamente cancelar una factura?

¿Puede modificarse después de contabilizada?

¿Qué ocurre si existe un pago parcial?

¿Quién puede ver determinada información?

¿Qué datos son obligatorios?

¿Qué debe registrarse para auditoría?

¿Qué ocurre cuando falla un servicio externo?

La IA puede generar respuestas para todas esas preguntas.

El problema es que quizás no sean nuestras respuestas.

Y allí reaparece la ingeniería de software.

Casi 40 años después

Resulta interesante mirar la evolución.

A finales de los 80 hacíamos modelos Entidad-Relación, diagramas de flujo, diccionarios de datos y documentos de requerimientos. Después pasábamos meses escribiendo manualmente la aplicación.

Durante las décadas siguientes creamos lenguajes mejores, frameworks, bibliotecas, generadores, herramientas low-code y plataformas basadas en modelos para reducir ese trabajo.

Ahora los agentes de IA empiezan a ser capaces de realizar gran parte de la traducción entre una especificación y una aplicación ejecutable.

La productividad puede cambiar radicalmente.

Existe una correspondencia casi 1 a 1 con lo que haciamos y ahora.  El MER pasa a ser Modelo de entidades, diagramas de flujo  son los casos de uso, reglas ahora se llaman requerimientos, lo unico que desaparece es el diccionario de datos independiente, porque esta embebido en la herramienta misma. 

Pero el punto de partida sigue siendo sorprendentemente parecido :

entender correctamente el problema y expresarlo con la mayor claridad posible.

Tal vez una de las consecuencias más interesantes de la IA en el desarrollo de software no sea que tengamos que escribir menos código.

Tal vez sea que finalmente podamos dedicar mucho más tiempo a pensar qué software queremos construir.

Y mucho menos tiempo a explicarle, instrucción por instrucción, a una computadora cómo construirlo.