El regreso de las especificaciones en la era de la Inteligencia Artificial Generativa.

Durante años aprendimos que construir software no comenzaba escribiendo código. Comenzaba mucho antes: entendiendo una organización, sus objetivos, sus procesos, sus actores y los problemas que necesitaba resolver.

En los modelos tradicionales de desarrollo, particularmente en waterfall, esa premisa tomaba la forma de una etapa extensa y claramente delimitada de relevamiento, análisis y especificación de requerimientos. Antes de diseñar o construir una solución había que definir qué debía hacer, qué reglas tenía que respetar, con qué otros sistemas debían interactuar y cuáles eran sus restricciones.

La ingeniería de requerimientos buscaba evitar algo que continúa siendo tan sencillo de explicar cómo difícil de resolver: desarrollar un software excelente pero inútil (o tarde).

El problema de waterfall no era la existencia de esta disciplina, sino la pretensión de que los requerimientos podían conocerse por completo al comienzo del proyecto, documentarse y permanecer estables durante meses o incluso años (parece increíble que hace tan poco tiempo este aún era el patrón). Factores económicos, tecnológicos, políticos, legales, culturales, reputacionales, de talento y poder entre otros, fueron alejando a las organizaciones de aquella expectativa cada vez menos realista.

El agilismo apareció, entonces, para cuestionar la rigidez de esos procesos. Puso en valor la colaboración con el cliente, la adaptación al cambio, las entregas incrementales y el software funcionando tempranamente. Fuimos muy rápido entregando y un poco más lentos para mejorar nuestras entregas. A veces acumulando deuda técnica o debiendo sacrificar calidad, y casi siempre documentación. El propio Manifiesto Ágil, sin embargo, nunca sostuvo que la documentación no tuviera valor: propuso valorar más el software funcionando que la documentación extensiva.

Pero el tiempo degradó nuestro recuerdo del por qué lo hicimos al punto que menos documentación terminó siendo interpretado como menos análisis. La ingeniería de requerimientos se fragmentó en historias de usuario, conversaciones, backlogs y criterios de aceptación (también valen chats de último minuto). Este dinamismo permitió ganar velocidad, pero también hizo que muchas veces se perdieran la visión integral, la trazabilidad, los requerimientos no funcionales y las consecuencias arquitectónicas de cada decisión.

Y entonces llegó la Inteligencia Artificial Generativa.

Hoy cualquier persona puede “vibe codear“, describir una necesidad en lenguaje natural (el prompt) y, utilizando diferentes herramientas agénticas, diseñar una interfaz, construir un prototipo, generar código, crear pruebas, integrar servicios y desplegar una aplicación. Puede recorrer en pocos días —o incluso en pocas horas— actividades que anteriormente requerían la intervención de distintos perfiles especializados, activando tiempos y medios hasta llegar a un resultado similar.

Esto no significa que hayan desaparecido las disciplinas involucradas. Significa que ahora pueden concentrarse, al menos para determinadas soluciones, en una sola persona que no necesariamente domina en profundidad cada lenguaje, framework o componente tecnológico que utilizó. “Nos cambiamos el sombrero”, suelo decir para describir la manera en la que durante el día “los de sistemas” actualmente recorremos diferentes roles del ciclo de ingeniería de software (incluso más de una vez en el mismo día), agotando tokens de Claude, Gemini, el último GPT o el modelo que esta semana esté desbordando las redes.

Claro, la capacidad de construcción se democratiza. Y con ella también aparece un nuevo riesgo: ahora podemos desarrollar software equivocado mucho más rápido.

En este contexto comienza a tomar fuerza el Spec-Driven Development (SDD), o desarrollo guiado por especificaciones. El enfoque vuelve a colocar la especificación en el centro del proceso: primero se define qué se necesita construir, luego se traducen esas necesidades en decisiones de diseño, tareas, pruebas y criterios de validación y, finalmente, se pasa a la implementación. Todo esto acelerado por IA.

No se trata de regresar al documento de requerimientos de cientos de páginas que se entregaba al comienzo de un proyecto y quedaba desactualizado poco tiempo después. Las especificaciones actuales pueden ser iterativas, versionadas, verificables y evolucionar junto con el producto. Recuperan la rigurosidad de la ingeniería de requerimientos, pero la incorporan a un ciclo continuo de diseño, construcción y aprendizaje. Los agentes de IA reciben, a través de las especificaciones, el contexto para construir, y el humano es quien lidera el proceso. Puede intervenirlo, disparar múltiples escenarios de construcción y despliegue, decisiones de lenguajes y frameworks, etc. todo en paralelo, a velocidades inigualables.

Lo que quiero decir es que esta evolución vuelve a poner en valor una capacidad central de nuestra profesión: saber especificar.

Y especificar no es simplemente “escribir un buen prompt”. Es comprender qué problema vale la pena resolver, para quién, con qué reglas de negocio, utilizando qué datos y dentro de qué arquitectura. Es identificar integraciones, restricciones, riesgos, condiciones de seguridad, necesidades de interoperabilidad, criterios de calidad y resultados esperados por el negocio. También cómo medir el impacto y cómo atribuirlo al software que lo apalanca.

Cuanto más fácil sea escribir código, más importante será decidir qué código generar (y descartar).

Para el estudiante o graduado LSI, esta transformación representa una enorme oportunidad. Nuestra formación no está orientada a construir aplicaciones, sino a comprender cómo los sistemas de información y la tecnología acompañan la estrategia de una organización. Nuestra carrera nos prepara para profundizar esta mirada: integrar conocimientos, analizar organizaciones y tratar con profesionales de diferentes disciplinas, utilizar marcos y metodologías, gestionar proyectos y recursos tecnológicos e incorporarlos a las organizaciones de manera crítica, ética y responsable.

Creo que estamos en unos de esos momentos históricos en que nuestra profesión es de las más relevantes (o “sexy”, como adjetiva Harvard Business Review).
La Inteligencia Artificial Generativa probablemente continúe reduciendo las barreras técnicas para diseñar, prototipar, programar y desplegar soluciones. Pero qué transformación necesita una organización, qué procesos debe modificar, cómo debe evolucionar su arquitectura o qué activos tecnológicos necesita gestionar para sostener su estrategia, siguen siendo preguntas que necesitan de nuestro liderazgo humano, crítico y sensible.

Al final, lo que prevalece es el entendimiento de la problemática del negocio, la arquitectura y la gestión de la tecnología.

Específicamente, aquello para lo que nuestra Facultad nos prepara.
_____________________________________________________________________________________________________

Bárbara Michalla
Licenciada en Sistemas de Información de las Organizaciones FCE UBA
Posgrado en Explotación de Datos y Descubrimiento del Conocimiento FCE UBA
Se especializa en el desarrollo de soluciones de analítica e inteligencia artificial, con más de 15 años de experiencia en organizaciones de gran escala.
Actualmente lidera el diseño, construcción e implementación de la plataforma de IA de Mercado Libre.
A lo largo de su carrera, ha liderado equipos de desarrollo, análisis funcional y arquitectura de datos, tanto en el sector público como privado, incluyendo su paso por la Administración Federal de Ingresos Públicos (AFIP).
Además, se desempeña como docente universitaria UBA y participa activamente en espacios de formación y difusión vinculados a analítica de datos e inteligencia artificial, combinando una sólida base académica con una mirada práctica orientada a generar impacto real en el negocio.