Llevo seis meses integrando agentes de IA en los pipelines de integracion continua de varios proyectos y la experiencia ha sido una curva empinada: los primeros intentos fueron decepcionantes, las primeras iteraciones generaron mas ruido que valor, y solo despues de afinar el contexto y los limites aparecieron los patrones que de verdad ayudan. Este post recoge lo que he aprendido sobre donde y como usar agentes en CI sin convertir cada pull request en un debate con una maquina que no entiende del todo lo que revisa.
Por que justo ahora
La pregunta razonable es por que hablar de esto en 2025 y no antes. La respuesta es doble. Por un lado, los modelos actuales aguantan ventanas de contexto suficientes para analizar un diff real con sus archivos vecinos, sin tener que trocear artificialmente. Por otro, las integraciones de plataforma han madurado: GitHub Actions, Gitea Actions y equivalentes ya tienen runners pensados para ejecutar pasos con modelos, y el coste por pull request ha bajado al punto donde compensa para equipos pequenios.
Hasta 2024 montar un revisor con IA exigia trabajo de plomeria propio: extraer el diff, recortar para caber en la ventana, invocar el modelo, procesar la respuesta. En 2025 hay herramientas que hacen la primera capa de ese trabajo, con lo cual la barrera de entrada es mucho mas baja y el foco puede estar en configurar el comportamiento, no en armar el tuberia desde cero.
Revision de diffs como patron base
El patron mas util que he encontrado es la revision automatica de diffs en pull requests abiertos. Un trabajo de CI dispara un agente que lee el diff, los archivos cambiados en su totalidad y los archivos relacionados por imports. El agente publica un comentario con observaciones: posibles errores logicos, violaciones de convenciones del proyecto, pruebas que faltan, dependencias nuevas no justificadas.
La clave para que este patron funcione es el contexto. Un agente que solo ve las lineas cambiadas dice tonterias con frecuencia; un agente que ve los archivos completos y el historial reciente de la rama dice cosas utiles. En mis pruebas, pasar de contexto de 500 lineas a contexto de 3000 bajo la tasa de falsos positivos de cerca del 40% a menos del 10%.
El segundo factor critico es delimitar que revisar. Pedirle al agente que revise todo es pedirle que diga algo sobre todo, incluyendo cosas donde no sabe nada. Yo le doy una lista explicita: logica de control de errores, nombres de variables, coherencia con el patron del modulo, tests que cubran los cambios. Fuera de esa lista, silencio. Esto elimina ruido y mantiene la credibilidad del comentario.
Generacion de tests que faltan
El segundo patron que usa mi pipeline es la generacion de tests para funciones nuevas sin cobertura. Un trabajo separado detecta funciones publicas anadidas en el diff que no tienen tests asociados, genera casos de prueba con el agente, y propone el resultado como un commit adicional en el pull request.
Este patron es mas delicado que la revision. Los tests generados necesitan ser buenos, no solo existir, y hay que resistir la tentacion de subir cobertura con pruebas que no prueban nada sustancial. Lo que ha funcionado en mis proyectos es generar solo los casos felices y los bordes mas obvios, y pedir explicitamente al humano que anada los casos de error y los casos adversos.
El segundo cuidado es el de los tests que parecen correctos pero pasan siempre. La IA tiene tendencia a generar assertions tautologicas: comprueba que la funcion devuelve lo que devuelve. Revisar los tests generados antes de fusionarlos es obligatorio; confiar ciegamente en que la cobertura sube es el camino rapido a una base de tests peor que la anterior.
Arreglos propuestos como sugerencias
El tercer patron, menos maduro pero prometedor, es la propuesta de arreglos automaticos. Cuando el agente detecta un problema concreto, ademas de describirlo en texto, publica una sugerencia en el pull request que el autor puede aceptar con un clic. Este patron es potente porque convierte el comentario abstracto en codigo concreto.
El limite es que solo funciona bien en problemas pequenios y locales: formato, nombres, validaciones de entrada olvidadas. Para cambios arquitecturales o decisiones de diseno, el agente no tiene contexto para proponer el arreglo correcto y acaba sugiriendo cosas peores que el problema original. Mi regla es activar sugerencias automaticas solo para problemas que el agente puede explicar en una frase; para problemas que requieren parrafo, que el autor decida.
Costes reales y limites practicos
Hay que hablar del coste. Un agente de calidad para revision de un pull request mediano cuesta entre 5 y 30 centimos por ejecucion dependiendo del modelo y del tamanio del contexto. Para un proyecto con 50 pull requests a la semana, son entre 10 y 60 euros al mes. No es gratis pero tampoco es caro comparado con el tiempo de revision humana que ahorra en los pull requests pequenios.
El limite que mas me frustra es la memoria entre ejecuciones. Cada invocacion del agente es independiente: no recuerda decisiones previas del equipo, no aprende de las sugerencias rechazadas, no afina su criterio a las convenciones especificas del proyecto. Hay estrategias para paliarlo (incluir fragmentos del historial en el contexto, mantener un archivo de convenciones que se inyecta en cada llamada) pero ninguna es completa.
Lo que no conviene automatizar
Tras varios meses he acabado con una lista de cosas que no conviene pedirle al agente en CI. La revision de cambios de seguridad es la primera: los falsos negativos son caros y el agente no tiene el contexto completo de la politica de seguridad del proyecto. Para estos cambios sigo prefiriendo un linter de seguridad clasico y una revision humana dedicada.
La segunda es cualquier cambio que toque contratos publicos de la API. El agente puede detectar rupturas sintacticas pero no entiende las implicaciones semanticas de un cambio de contrato. Aqui el riesgo de un falso sentido de seguridad es alto, porque la IA puede aprobar un cambio que parece menor y acaba rompiendo clientes en produccion.
La tercera es el analisis de rendimiento. El agente puede leer codigo y especular sobre complejidad, pero no sabe medir. Para decisiones de rendimiento, hay que medir, no opinar. El agente es util para pedir confirmacion tras medir, no para sustituir la medicion.
Como configuro el pipeline
Mi configuracion actual tiene tres pasos diferenciados. El primero es un paso rapido, barato, que hace analisis sintactico y de estilo con herramientas clasicas. Este paso filtra el 80% de los problemas triviales antes de que el agente los vea, lo que ahorra coste y mejora la senial.
El segundo paso es el agente de revision, que se ejecuta solo si el primero pasa y si el pull request cambia mas de 20 lineas. Para cambios muy pequenios el coste no se amortiza. El agente recibe el diff, los archivos tocados enteros, el historial reciente de la rama y un archivo de convenciones del proyecto que se mantiene en el repositorio.
El tercer paso es el generador de tests, que solo se dispara si se detectan funciones nuevas sin cobertura y si la rama no es de hotfix. Los hotfix suelen ser rapidos y el autor sabe lo que hace; bloquear con propuestas generadas anade friccion innecesaria en ese camino critico.
Cuando compensa
Mi criterio para decidir si un proyecto se beneficia de agentes en CI es sencillo: equipos de tres o mas personas donde la revision humana es cuello de botella, codigo con convenciones claras y documentadas, y presupuesto para asumir entre 20 y 100 euros al mes en coste de modelo. Para equipos mas pequenios, la revision humana sigue siendo mas barata y precisa.
Para proyectos puntuales o exploratorios, los agentes en CI son ruido. El coste fijo de configurar el pipeline no se amortiza y el agente acaba comentando cosas que el autor ya sabe y ha decidido ignorar. La madurez del proyecto es un requisito que a veces se pasa por alto.
Creo que dentro de un anio el patron sera mas sofisticado: agentes que recuerdan decisiones previas, que afinan criterios con las correcciones del equipo, que coordinan revisiones largas en varias pasadas. Por ahora, los patrones simples y acotados son los que funcionan. Resistir la tentacion de pedirle al agente todo y concentrar su trabajo en tres o cuatro tareas donde aporta valor es la forma rapida de sacarle partido sin quemar credibilidad.
