Agentes de IA en GitHub Actions: así hemos empezado a automatizar la revisión de código
Una issue que se resuelve sola: el sistema abre la PR, la resuelve y la audita. Así funciona ya un workflow real que corre en la organización de GitHub de un cliente.
DANIEL ALARCÓN
Software Architect
Llevamos muy poco tiempo con esto en marcha —estamos empezando a probarlo ahora mismo, no lleva semanas rodando— pero ya deja ver hacia dónde va la ingeniería en los próximos años: agentes de IA en GitHub Actions revisando pull requests y, en algunos casos, resolviendo issues sin que nadie escriba una línea de código a mano. Lo montamos en varios repositorios de un cliente y lo estamos extendiendo al resto; aunque es una primera versión con bastantes aristas, el mecanismo ya funciona de punta a punta.
Revisar pull requests con un modelo no es nada nuevo: herramientas como GitHub Copilot lo hacen desde hace tiempo, con la revisión corriendo en la nube del proveedor y facturando por cada llamada a su API. Lo que cambia aquí es que todo el sistema de inferencia vive dentro de la infraestructura del propio cliente: sin coste variable por proveedor externo y sin que los datos de revisión salgan de ahí.
Hay además un segundo cambio, más de proceso: un mismo pipeline recibe la petición de arreglar algo, genera el cambio, lo abre como PR y lo somete al mismo filtro que cualquier código escrito por una persona, sin que nadie tenga que orquestar cada paso a mano.
Cómo revisamos ahora cada pull request
Lo primero que montamos fue un workflow reutilizable de GitHub Actions que envuelve PR-Agent y lo conecta a la máquina de inferencia interna de un cliente: no es una herramienta que hayamos construido desde cero, sino que aprovechamos algo ya maduro y lo enchufamos a la infraestructura del cliente. Cualquier repositorio de la organización puede añadirlo con unas pocas líneas y empieza a recibir comentarios de revisión automática en cuanto se abre un pull request.
El workflow admite configuración sobre tres ejes:
- El comportamiento de la revisión: qué tipo de problemas prioriza y con qué nivel de exigencia
- El prompt que define el criterio con el que revisa el código
- El modelo de inferencia que usa por debajo
De momento lo tenemos todo con la configuración por defecto —no hemos tocado ni prompt ni modelo—, y aun así el resultado ya aporta valor: señala problemas reales antes de que una persona llegue a mirar el PR. Una cosa que nos gusta de PR-Agent es que etiqueta el esfuerzo de revisión de cada PR, y con el volumen de PRs que maneja un equipo, esa etiqueta ayuda mucho a priorizar qué mirar primero.
Usar la máquina de inferencia del cliente para esto tampoco es solo para revisar código: nos sirve además para medir el dimensionamiento y las capacidades reales de esa máquina, algo difícil de probar sin carga real. Es la misma pregunta que nos hacíamos al escribir sobre si el clean code sigue importando cuando es un agente el que escribe el código: revisar con el mismo criterio, escriba quien escriba.
Sigue nuestro viaje construyendo agentes IA desde dentro
Agentes de IA en GitHub Actions: cuando el propio pipeline resuelve el issue
La segunda pieza va un paso más allá. Es otro workflow que escucha comentarios en issues y, cuando detecta la señal correcta, dispara una resolución autónoma:
- Alguien comenta en un issue pidiendo que se resuelva
- El workflow se activa y pasa el contexto a opencode, apoyado también en la máquina de inferencia de ese cliente
- Opencode genera el cambio y abre una pull request
- La action de revisión del primer punto entra en acción sobre esa misma PR, sin que nadie la invoque a mano
Ese último paso es el que más me gusta de este primer montaje: las dos piezas se realimentan. La PR que nace de una resolución automática pasa por el mismo filtro que cualquier PR humana. No hay un camino menos vigilado para el código que escribe el agente.
Lo que todavía no funciona bien
Esto es una primerísima versión y prefiero decirlo con la misma claridad con la que lo compartí con el equipo: hay bastante por afinar. El prompt no es solo revisar código: hay que afinarlo para asegurarnos de que el código que genera el agente quede moldeado como queremos, no solo que «pase la revisión».
El modelo también nos limita bastante —estamos atados a la capacidad de la máquina de inferencia del cliente, sin acceso a modelos frontier—, así que estamos probando alternativas abiertas como Kimi, GLM o Qwen para ver cuáles dan mejores resultados con las herramientas que tenemos. Y hay un problema más de fondo con el propio setup: ejecutar opencode dentro de una GitHub Action tiene un límite práctico, porque si la resolución de un issue se alarga, la action se alarga con ella.
Existe también una cuestión de proceso que todavía no hemos resuelto: estamos probando opencode a través de tickets de GitHub, pero si el flujo de trabajo real pasa por Jira, lo que se hace en GitHub no deja traza ahí. Es trabajo transparente que el cliente no ve, y el tiempo que se dedica a revisar y desplegar ese código —que es justo donde vamos a emplear más tiempo en el futuro— hay que ponerlo en valor de alguna forma, no dejarlo invisible.
Lo siguiente es afinar el prompt y probar otros modelos de la máquina de inferencia para la revisión y repensar dónde vive la ejecución de opencode para no depender de los límites de una GitHub Action. Ya lo tenemos corriendo en varios repositorios de la organización de ese cliente y lo estamos extendiendo al resto.
El valor de fondo no es solo automatizar un paso: es empezar a modelar un enfoque de trabajo distinto, con el sistema revisando pull requests de forma proactiva dentro de la infraestructura propia del cliente, no en la nube de un tercero. A partir de ahí, la idea es delegar trabajo por las noches y cambiar el porcentaje de tiempo que dedicamos a codificar, aunque sea trabajando dentro de una sesión de Claude: pasar de ejecutores —aunque ejecutemos con Claude Code o herramientas similares— a una ejecución completamente delegada, revisando el trabajo en otro momento.
Es un cambio de mindset importante, probablemente el que más les va a costar a las organizaciones. Y ya estamos mirando un paso más allá: agentes que se levanten bajo demanda para ejecutar tareas en cuanto las detecten, con herramientas como Hermes u OpenClaw. Pero ese es el paso dos; haber llegado al paso uno ya reestructura tanto el mindset que lo siguiente viene casi solo.
