Un agente de IA para revisar especificaciones técnicas: por qué automatizar lo que no funciona a mano

Una mala especificación técnica es una bomba de relojería. No estalla de inmediato, sino semanas o meses después, cuando el equipo de desarrollo descubre que el cliente se refería a algo completamente distinto, que los requisitos se contradicen entre sí y que la mitad de los escenarios críticos ni siquiera están descritos. Según diversas estimaciones, hasta el 40 por ciento de los retrabajos en proyectos de IT se debe a una documentación deficiente al inicio. Una desarrolladora decidió que se podía hacer algo al respecto y construyó un agente de IA que revisa las especificaciones antes de que alguien empiece a escribir código con ellas.

La historia, publicada en Habr a principios de marzo de 2026, conquista por su honestidad. La autora advierte desde el principio de que no es un producto terminado ni una solución universal. Es un experimento nacido de una molestia personal, de trabajar con documentación en la que cada segundo punto admite dos interpretaciones. La idea es simple y elegante: lanzar un modelo de lenguaje sobre el texto de la especificación y pedirle que encuentre contradicciones, lagunas lógicas, formulaciones ambiguas y casos límite ausentes. Lo que a un analista humano le lleva horas de lectura atenta, un agente de IA puede hacerlo en minutos.

Técnicamente, el enfoque encaja en el paradigma, cada vez más popular, de los agentes de IA: sistemas autónomos basados en grandes modelos de lenguaje que no se limitan a responder preguntas, sino que ejecutan una secuencia de acciones para lograr un objetivo. Aquí, el agente divide la especificación en bloques lógicos, analiza la coherencia interna de cada uno, luego comprueba la consistencia entre bloques y, por último, genera un informe estructurado que señala los puntos problemáticos concretos. No es solo un prompt en ChatGPT: es una cadena de razonamiento con contexto y memoria.

Lo que hace realmente interesante este experimento es que refleja un cambio fundamental en cómo los desarrolladores piensan en aplicar los modelos de lenguaje. La primera ola de entusiasmo giró en torno a la generación de código: GitHub Copilot, el autocompletado, la conversión de descripciones en funciones operativas. La segunda ola, la que vemos ahora, apunta a los procesos alrededor del código: revisión de documentación, análisis de requisitos, comprobación de la completitud de los casos de prueba, auditoría de decisiones de arquitectura. Es menos vistoso que «la IA escribe el código por ti», pero potencialmente mucho más valioso para el negocio.

La calidad de las especificaciones técnicas es uno de esos problemas que el sector lleva décadas intentando resolver con metodología. Agile lo sorteó en parte al sustituir las especificaciones monolíticas por historias de usuario iterativas. Pero incluso en los equipos ágiles alguien tiene que redactar criterios de aceptación claros y alguien tiene que revisarlos. En la externalización y el desarrollo a medida, donde la especificación sigue siendo un documento legal, lo que está en juego es aún mayor. Una redacción imprecisa en una especificación no es solo deuda técnica: es un posible conflicto entre cliente y contratista que puede acabar en los tribunales.

Por supuesto, el enfoque tiene limitaciones, y la autora no las oculta. Un modelo de lenguaje no entiende el contexto de negocio del proyecto como lo entiende un analista con experiencia. Puede señalar una contradicción formal donde no la hay, o pasar por alto un problema camuflado bajo una redacción correcta. El agente de IA no sustituye la experiencia humana: la refuerza, como primer filtro que atrapa los problemas evidentes y deja al analista tiempo para los que no lo son.

También resulta interesante que herramientas así empiecen a aparecer no solo como proyectos paralelos de entusiastas. Las grandes plataformas de gestión de requisitos ya integran funciones de IA para analizar la calidad de la documentación. Jira, Confluence, Notion: todas avanzan en esa dirección. Pero los agentes a medida, afinados para los procesos concretos de un equipo concreto, pueden resultar más eficaces que las soluciones universales. Por eso es valiosa la experiencia de montar un agente así «a las bravas»: demuestra que la barrera de entrada ha bajado tanto que un solo especialista puede armar un prototipo funcional en unas pocas tardes.

Este experimento es una ilustración pequeña pero reveladora de hacia dónde va el uso aplicado de la IA en el desarrollo. No se trata de sustituir a los programadores ni de generar automáticamente productos terminados, sino de reforzar de forma puntual a las personas allí donde tradicionalmente fallan. Revisar especificaciones es solo uno de esos nodos. Los siguientes podrían ser la auditoría automática de contratos, la validación de requisitos de negocio frente a normas regulatorias o la revisión de materiales de marketing en busca de riesgos legales. El modelo de uso es siempre el mismo: dejar que la IA lea lo que escribió una persona y pedirle que encuentre los puntos débiles. Simple, pero sorprendentemente eficaz.