Un equipo integra un agente de IA en el desarrollo e introduce dos etapas de revisión

El agente escribió el código rápidamente. Ahora alguien tiene que comprobar si modificó el servicio correcto, si consultó la base de datos adecuada y si no bloqueó la interfaz con una operación larga. En un artículo en Habr, el equipo describió cómo resolvió estos problemas en su propio agente para IntelliJ IDEA. Uno de los pasos principales es aprobar la especificación en un pull request aparte antes de empezar a implementar. Este orden también se puede probar con un agente que ya tengas instalado.

La historia comenzó en 2024 con un plugin para generar pruebas. Después apareció un chat dentro del IDE y, tras conocer Windsurf en enero de 2025, el equipo se puso con un agente completo: búsqueda por el proyecto, modificación de archivos y ejecución de comprobaciones. Con el uso se fue viendo qué partes del trabajo había que explicar de nuevo y dónde la herramienta necesitaba límites.

Contexto del proyecto: encontrar el código y elegir la base de datos correcta

Para la búsqueda, el equipo recurrió a los índices de IntelliJ IDEA y a PSI, la representación estructural del código dentro del IDE. Los índices ayudan a encontrar clases, métodos y archivos, mientras que PSI muestra los elementos del programa y las relaciones entre ellos. El agente transmite esta información al modelo de lenguaje.

Imaginemos una tarea: cambiar el procesamiento de pedidos. Conviene localizar el propio método, sus llamadas y las clases relacionadas antes de editar el primer archivo que parezca adecuado. Es una ilustración del enfoque; los autores no aportan mediciones concretas de la calidad de esta búsqueda.

Para las fuentes externas, el equipo añadió MCP, una forma de conectar servidores que ofrecen herramientas al agente. A través de ellos se pueden obtener tareas de GitHub, consultar una base de datos o comprobar una aplicación web en el navegador. Las acciones disponibles dependen del servidor concreto y de los permisos concedidos.

Pero conectar la base de datos no resolvió por sí solo el problema del contexto. Según los autores, una consulta fue una vez a un entorno equivocado y devolvió un resultado convincente, pero incorrecto. El agente también confundía nombres de columnas. Los desarrolladores tenían que repetir las explicaciones, sobre todo tras abrir un chat nuevo.

Los procedimientos repetitivos el equipo los plasmó en skills: instrucciones con un orden de acciones y condiciones de verificación. Además, apareció una memoria local del proyecto para restricciones y soluciones encontradas. Las reglas prohíben guardar credenciales, aunque el texto disponible no revela mecanismos técnicos de protección de la memoria.

Primero revisar la tarea, después la implementación

Ahora el trabajo en una función empieza por la especificación. El desarrollador la redacta junto con el agente y abre un pull request aparte. Un compañero revisa el documento y, tras la aprobación, comienza la implementación. Las decisiones y aclaraciones quedan en el repositorio para que el siguiente participante pueda reconstruir el contexto.

Tomemos un cambio de API. Antes de generar código, el equipo puede acordar los campos de la respuesta, el manejo de errores y el comportamiento esperado del cliente. El desarrollador de frontend recibe una descripción que un compañero ya ha revisado. Aparece así un punto de control temprano: un error en los requisitos puede detectarse antes de que se extienda por varios archivos.

Para la revisión de código, los autores utilizaron sus propios comentarios de pull requests anteriores. Al desarrollar el plugin eran frecuentes las operaciones largas en el hilo de la interfaz EDT y las llamadas a la API de IntelliJ sin el read action necesario. Esos casos se convirtieron en instrucciones para el agente revisor.

Más tarde, la revisión se repartió entre varios subagentes con distintos roles. Los resultados se reúnen en un informe común, tras el cual el desarrollador elige las correcciones. Los autores afirman que los errores conocidos son ahora menos frecuentes, pero no muestran estadísticas, muestra de control ni el coste de las revisiones. Con el artículo no se puede estimar la magnitud del efecto.

Qué se puede trasladar a tu equipo

El elemento más práctico de la historia es el control de las acciones a nivel del plugin. Una herramienta se puede desactivar o exigir confirmación antes de invocarla. La decisión de ejecutar la toma la capa de software. Esto da al desarrollador un punto de control concreto al trabajar con comandos y servicios externos.

El equipo también separó la lógica del agente de la interfaz y publicó una CLI. Según su descripción, la versión de terminal conserva el trabajo con archivos, skills, modelos y MCP. Sin embargo, el fragmento proporcionado se interrumpe: aquí faltan el nombre del producto, las condiciones de acceso y una imagen completa de su explotación.

Un experimento práctico puede empezar por un error recurrente de tu propio equipo: describir una regla de revisión, añadir la aprobación de requisitos y comparar los resultados en las siguientes tareas. Conviene medir el tiempo hasta el cambio aceptado, el número de devoluciones desde la revisión y los defectos tras la fusión. Justo esas mediciones faltan todavía a esta historia para juzgar si compensa tener un agente propio.