Veai muestra cómo prueba un agente de IA en los IDE de JetBrains sin depender del modelo

Veai ha contado cómo construyó las pruebas de UI de su agente de IA dentro de los IDE de JetBrains para que las comprobaciones no dependan de los caprichos del modelo de lenguaje. El equipo separó las pruebas de la interfaz, de la lógica de negocio y del propio LLM, y con ello montó un pipeline estable para los PR y las ejecuciones nocturnas.

Por qué es difícil

El principal problema de estos productos es que una misma petición a un LLM puede devolver redacciones distintas, respuestas de distinta longitud e incluso un formato de salida diferente. Si se prueba un plugin de IA como un chatbot corriente y se espera un texto concreto, las pruebas de UI se convierten enseguida en una lotería.

Al mismo tiempo, buena parte del producto es perfectamente determinista: los ajustes del usuario, las transiciones entre estados del chat, los botones, las insignias de skills, el historial de diálogos y la lógica de negocio interna del plugin. Veai decidió llevar justo esta parte a una capa de automatización aparte.

El equipo parte de un principio sencillo: la calidad de la respuesta del modelo y el funcionamiento de la interfaz son tareas distintas, y no conviene mezclarlas en una misma prueba. El proyecto ya tenía comprobaciones en otros niveles, como pruebas del modelo del IDE, escenarios para distintos proveedores de LLM y un benchmark de agentes independiente. Por eso la automatización de UI se convirtió en la cima de la pirámide de pruebas y no en un intento de sustituir todo lo demás.

Este enfoque importa en un plugin de IDE: el agente responde tanto en la ventana de chat como a través del terminal, así que hay bastantes más puntos donde una prueba puede fallar de forma intermitente que en una interfaz web corriente.

Cómo se organizaron las pruebas

Para no mezclar objetivos, Veai dividió las ejecuciones en varios modos. Las pruebas smoke se ejecutan en cada pull request y comprueban el funcionamiento básico de la interfaz sin una llamada real al LLM. Las ejecuciones full se lanzan por la noche, trabajan ya con un servidor real y recorren toda la cadena, desde el plugin hasta la respuesta del modelo. Aparte existe un benchmark: no son pruebas de UI, sino una evaluación de escenarios de usuario y de la calidad del agente según el principio LLM-as-a-Judge.

De este modo, el equipo detecta antes las regresiones de UI durante el día y no pierde la verificación de extremo a extremo del producto por la noche.

• Smoke en cada PR: comprobación de la UI y de la lógica básica sin carga sobre el LLM
• Full por la noche: trabajo con un servidor real y espera de la respuesta en la interfaz
• Benchmark aparte: evaluación de los escenarios del agente y de la calidad del resultado
• Ejecución en paralelo en distintos IDE: mayor cobertura sin más trabajo manual rutinario

En la ejecución completa, los desarrolladores usan una petición muy corta: 2+2=? Ответь покороче se traduce como «Responde brevemente». Pero el objetivo de la prueba no es ver precisamente el número 4. El sentido es otro: tras las precondiciones necesarias, el agente debe pasar al estado Ready, recibir la respuesta del servidor, terminar correctamente el streaming de los tokens y mostrar el resultado en la interfaz. Este escenario no comprueba la creatividad del modelo, sino que la combinación del plugin del IDE, el servidor de licencias, el servidor del LLM y las bibliotecas internas no se haya roto tras el último cambio.

«No intentamos obtener la respuesta 4».

Qué ayudó en CI

En lo técnico, Veai se apoya en las bibliotecas JetBrains Starter y Driver. Starter prepara el IDE, configura el proyecto de prueba y recoge los artefactos de la ejecución, mientras que Driver trabaja con la interfaz real y permite describir elementos mediante Page Object y un enfoque DSL. Si los localizadores no bastan, el equipo añade accessibleName al código del producto o ajusta las reglas de ofuscación para que los elementos sigan siendo localizables.

Parte del estado se prepara de antemano mediante los ajustes XML del plugin, de modo que las pruebas no tienen que pasar cada vez por la pantalla Welcome ni por el onboarding.

Otro elemento importante es el acceso al estado interno del IDE mediante JMX. Permite no solo hacer clic en la interfaz, sino también comprobar qué se ha registrado realmente en el chat del agente, qué proveedor está seleccionado y cómo es el estado JSON desde el punto de vista del plugin.

Para CI, el equipo mantiene una matriz con distintas versiones de IntelliJ Platform, varios IDE de JetBrains, feature flags y compilaciones ofuscadas. Las comprobaciones pesadas se ejecutan por la noche, en Linux se usa Xvfb y, para reducir el ruido, hay reintentos limitados: no más de un reinicio por prueba y no más de tres fallos en toda la ejecución.

El efecto práctico ya es visible: varias decenas de pruebas de UI cubren los ajustes del plugin, las transiciones entre estados del chat, las llamadas a skills, el historial de diálogos y la entrada de un usuario nuevo. En los primeros meses, estas comprobaciones encontraron errores muy concretos: tras añadir el drag and drop de archivos, se rompió el copy and paste; la barra de progreso del contexto no tenía en cuenta a todos los proveedores de LLM; la selección del agente en la UI tampoco funcionaba en todas las configuraciones; y el escenario de recuperación tras un error empezó a parpadear visualmente junto con las pruebas. Las ejecuciones nocturnas incluso pusieron de manifiesto la inestabilidad de una de las configuraciones de prueba del servidor del LLM.

Qué significa

Para los productos con funciones de IA, es una buena referencia: no conviene obligar a las pruebas de UI a juzgar la calidad del modelo cuando basta con comprobar la estabilidad de la interfaz y de la cadena de integraciones. Separar las partes deterministas y no deterministas del sistema hace las pruebas más rápidas, más útiles y bastante más honestas, tanto para los desarrolladores como para QA.