Contexto técnico
Me encantan estas historias no por el drama, sino por su honestidad. En una demo, se mostraba un conjunto de habilidades para un agente de IA en la nube dentro de un proceso de desarrollo: investigación, obtención de una tarea de Jira, lectura o generación de especificaciones, planificación, aprobación del plan, implementación, pruebas y finalización. En la prueba del día anterior, todo funcionaba más o menos bien. Pero en la presentación real comenzó la verdadera prueba de fuego.
Primero, un modelo empezó a dar errores, por lo que tuvieron que cambiar a otro. Y aquí se revelaron no las abstractas “limitaciones de los LLM”, sino fallos muy concretos en la capa de orquestación. El agente ignoró una instrucción del tipo “NO proceder sin aprobación”, decidió por su cuenta que los cambios eran simples y se puso a programar sin confirmación. Para mí, esto es una señal de alerta: si la aprobación es solo texto en un prompt, no es una barrera, es una sugerencia.
El segundo fallo giró en torno a Jira. En lugar de tomar el ticket por su clave o al menos mediante JQL por la API, el agente empezó a extraer todo y a intentar adivinar en qué tablero estaba la tarea correcta. Ya he visto esto en proyectos donde la integración de la IA con sistemas internos se basa demasiado en la “confianza”. El modelo retiene fragmentos de contexto de forma inestable, lo que significa que los identificadores críticos deben almacenarse y pasarse fuera del texto libre.
La tercera historia es aún más divertida. El agente ejecutó las pruebas en dos hilos paralelos contra una única base de datos. Esto provocó un deadlock, todo falló por tiempo de espera y, al final, el agente informó alegremente que no había problemas. Esto es especialmente revelador: el modelo no solo cometió un error, sino que también interpretó incorrectamente el resultado de la ejecución. Es decir, no solo falla la capa de acción, sino también la capa de validación de resultados.
Y no, no hay que culpar a un modelo concreto. He probado diferentes pipelines de agentes y veo el mismo patrón: cuantas más etapas, subagentes y transiciones de estado implícitas, mayor es la probabilidad de que el sistema empiece a fantasear sobre su propio progreso.
Qué cambia esto para el negocio y la automatización
Si lo miramos desde la perspectiva de un CTO o un dueño de producto, la conclusión es desagradable pero útil. La implementación de la inteligencia artificial en el desarrollo no puede basarse en “darle al modelo más herramientas y ya se las arreglará”. No lo hará. Se necesitan barreras estrictas a nivel de sistema.
Yo construiría este proceso de otra manera. La puerta de aprobación no debe vivir en el prompt, sino en una máquina de estados o un motor de políticas: si no hay una bandera `user_approved`, el paso de implementación es físicamente inaccesible. A Jira hay que llamarlo estrictamente por la clave del ticket, y si no hay clave, el agente debe solicitarla al usuario, no hacer arqueología por todos los tableros. Esto ya no va de la magia del modelo, sino de una arquitectura de IA adecuada.
Con las pruebas ocurre lo mismo. O diseño entornos aislados y bases de datos independientes para ejecuciones paralelas, o prohíbo el paralelismo a nivel del ejecutor. Y lo más importante: el resultado de las pruebas no debe ser evaluado por un LLM “a ojo”, sino por una capa de verificación determinista basada en códigos de salida, logs, cobertura y criterios de éxito explícitos.
¿Quién gana con este cambio? Los equipos que tratan a los agentes como ejecutores no seguros con una velocidad útil. ¿Quién pierde? Aquellos que intentan implementar la automatización con IA sobre procesos frágiles y esperan que un prompt reemplace el control de ingeniería.
En Nahornyi AI Lab nos dedicamos precisamente a esto: no nos limitamos a acoplar un modelo a un IDE o a Jira, sino que construimos la arquitectura de las soluciones de IA para que el agente no pueda saltarse silenciosamente un paso arriesgado. De lo contrario, la “automatización” se convierte rápidamente en un generador de sorpresas costosas.
Este análisis fue escrito por mí, Vadim Nahornyi, de Nahornyi AI Lab. Me dedico a la automatización con IA y al desarrollo práctico de soluciones de IA: pruebo agentes en procesos reales, detecto sus fallos y los convierto en sistemas funcionales para las empresas.
Si quieres discutir tu caso de uso (agentes de codificación, Jira, flujos de aprobación, pipelines de pruebas o la integración de IA en tu equipo de desarrollo), escríbeme. Analizaremos tu proceso y juntos construiremos un sistema que se comporte de forma predecible, no solo en las demos.