4 agentes IA revisando cada PR en GitHub Actions

Un desarrollador solitario resolvió el problema de la revisión de código con IA de una forma concreta: cuatro agentes con perspectivas diferentes comentando cada pull request automáticamente. El sistema usa dos archivos, cero infraestructura extra y cuesta aproximadamente USD 0,01 por PR con Gemini 2.0 Flash.

Gemini 2.0 es un modelo de lenguaje multimodal desarrollado por Google, presentado en diciembre de 2024, que procesa y genera texto, imágenes, video y audio.

¿Qué es un workflow agentico para revisión automática de código con IA?

Un workflow agentico es un sistema donde múltiples agentes de IA operan de forma coordinada, cada uno con un rol definido, en lugar de un único modelo que lo hace todo. En el contexto de revisión de código, eso significa que en vez de pedirle a un solo modelo “revisá este PR”, tenés cuatro perspectivas distintas ejecutándose sobre el mismo diff: una que mira el estilo y la corrección del código, otra que evalúa la arquitectura, otra que busca vulnerabilidades de seguridad, y otra que analiza escalabilidad.

La diferencia importa. Un revisor sintético único tiende a dar feedback genérico. Cuando cada agente tiene un prompt especializado con su “persona” definida, la profundidad del análisis cambia. El CSO no va a perder tiempo opinando sobre naming conventions. El Senior Developer no va a detenerse en cada endpoint para evaluar si resistiría tráfico 10x.

GitHub anunció las GitHub Agentic Workflows en technical preview en febrero de 2026, lo que muestra que la plataforma misma está apostando a esta dirección. Pero antes de que eso sea GA, hay formas de implementarlo hoy con Actions.

Arquitectura del sistema: dos archivos, cinco revisores

La implementación concreta de Ponali, publicada el 18 de mayo de 2026, es llamativamente simple. El sistema completo vive en dos archivos:

• .github/workflows/code-review-agents.yml: el YAML de GitHub Actions que maneja la orquestación
• .github/scripts/review_agent.py: un script Python de ~120 líneas que llama a Gemini una vez por revisor

No hay Lambda, no hay colas, no hay servicios externos. GitHub Actions es el runtime completo.

El workflow se dispara en tres eventos sobre PRs que apuntan a main o develop: cuando se abre un PR nuevo, cuando se sincronizan commits nuevos, o cuando un PR se reabre. Deliberadamente no dispara en comentarios, cambios de labels ni draft PRs, lo cual tiene sentido: no querés que un revisor IA se active cada vez que alguien le pone un 👍 a un comentario.

La ejecución tiene cinco tareas en total. Las primeras tres corren en paralelo (los revisores individuales). Después viene una cadena secuencial y un gate final. El creador reconoce que esa cadena secuencial es probablemente innecesaria y es uno de los puntos que cambiaría si lo rehiciese. Cubrimos ese tema en detalle en cómo integrar APIs de IA en tus workflows.

Las cuatro personas IA: perspectivas que no se pisan

Cada revisor tiene un prompt que define su rol, y recibe el diff del PR de forma independiente. No leen los comentarios de los otros agentes antes de comentar.

Senior Developer

Se enfoca en estilo, corrección y principios DRY. Busca duplicación de código, naming inconsistente, lógica que se podría simplificar. Es el revisor más parecido a un colega experimentado que mira si el código hace lo que dice que hace.

Engineering Lead

Evalúa la arquitectura y escalabilidad. ¿Este cambio va a crear deuda técnica? ¿La abstracción tiene sentido a medida que el proyecto crezca? ¿Hay acoplamiento que después va a doler?

Chief Security Officer

Mira OWASP Top 10, secretos hardcodeados, validación de inputs, manejo de errores que podría exponer información. Este es el revisor que en equipos chicos nadie tiene tiempo de ser pero que más falta hace.

Software Architect

Analiza las decisiones de diseño: si los patrones usados son los correctos para el problema, si hay mejores abstracciones disponibles, si el cambio es coherente con la arquitectura general del sistema.

El resultado visible en el PR son cuatro comentarios de bots, uno por persona, con feedback línea por línea cuando el API call tiene éxito. Cuando hay rate limiting (más sobre eso abajo), cada bot publica un mensaje de fallback explicando que no pudo completar la revisión.

Integración con Gemini API: cómo fluye y dónde tropieza

El script Python hace tres cosas: extrae el diff del PR usando gh pr diff, arma el prompt con la persona correspondiente y envía la request a Gemini, y publica el resultado como comentario en formato markdown. Ya lo cubrimos antes en por qué GitHub Actions sobre otras plataformas.

El costo con Gemini 2.0 Flash es de aproximadamente USD 0,01 por PR. Para un desarrollador solo o un equipo chico, eso es prácticamente gratis. En un equipo de 10 personas con 50 PRs por semana estamos hablando de USD 2 semanales.

¿Cuál es el problema real? El rate limiting del tier gratuito de la Gemini API. Con 4 llamadas casi simultáneas, es común recibir un 429. El sistema actual tiene un fallback que muestra el mensaje de error en vez del review, pero no reintenta. El propio autor lo señala como algo a mejorar: implementar backoff exponencial o espaciar las llamadas con un delay pequeño entre agentes.

Otro detalle técnico: el script llama a gh pr diff una vez por revisor, lo cual significa que el mismo diff se descarga cuatro veces. Redundante pero funcional. Si el diff es grande, eso agrega latencia innecesaria.

Cómo implementarlo: los pasos que no podés saltear

La configuración básica requiere cuatro cosas:

• Crear el YAML del workflow en .github/workflows/ con los triggers y jobs definidos
• Escribir el script Python con las llamadas a la API y los prompts por persona
• Agregar la Gemini API key como secret en el repositorio (Settings > Secrets and variables > Actions)
• Configurar el fetch-depth correctamente en el checkout para que gh pr diff tenga acceso al historial necesario

El punto del fetch-depth es uno que se pasa por alto seguido. Con el default de fetch-depth: 1, el diff puede salir incompleto o fallar en PRs con varios commits. Ponele fetch-depth: 0 o un número razonable según la profundidad de los PRs en tu repo.

El tiempo total de ejecución por PR es de 5 a 10 minutos dependiendo de la latencia de Gemini y si hay rate limiting. No es instantáneo, pero para revisión de código es perfectamente aceptable.

Alternativas en el ecosistema: qué más existe

Herramienta	Precio	Modelos	Open Source	Personalización
Solución propia (Gemini)	~USD 0,01/PR	Gemini 2.0 Flash	Sí (tuyo)	Total
Gemini Code Review Action	Costo API	Gemini	Sí	Media
PR-Agent	Gratis (self-hosted)	20+ modelos	Sí	Alta
CodeRabbit	USD 12/dev/mes	Múltiples	No	Media
Qodo	Freemium	Múltiples	No	Baja-Media

PR-Agent merece mención especial: es open source, soporta más de 20 modelos (incluyendo Claude, GPT-4, Gemini y modelos locales), y tiene integración directa con GitHub, GitLab y Bitbucket. La desventaja es que el setup es más complejo y el modelo de “personas especializadas” es algo que tenés que configurar vos.

Las GitHub Agentic Workflows oficiales están en technical preview desde febrero 2026 y eventualmente van a simplificar todo esto con integración nativa en la plataforma. Por ahora siguen siendo preview, con acceso limitado.

Para quién tiene más sentido esto

El caso de uso original es claro: Ponali mantiene Khetisahayak, una app agritech, solo. Sin equipo, sin revisores, revisando su propio código (que, seamos honestos, no es lo mismo que tener un segundo par de ojos). Los cuatro agentes IA le dan eso: perspectivas que no son las suyas propias. Esto se conecta con lo que analizamos en comparativa de modelos de IA para revisión.

Dicho esto, aplica igual de bien para equipos chicos donde hay PR review debt: las personas están ocupadas, los PRs esperan, el código llega a main sin review. Un workflow así no reemplaza la revisión humana para cambios críticos, pero actúa como primer filtro que atrapa lo obvio antes de que un humano siquiera lo mire.

Para proyectos personales, startups early-stage o equipos de 2-3 personas, USD 0,01 por PR con feedback real línea por línea es difícil de ignorar.

Limitaciones reales y qué cambiaría

El sistema tiene problemas concretos que vale aclarar:

La cadena secuencial es innecesaria. Los cuatro revisores podrían correr en paralelo completo. La cadena agrega tiempo de ejecución sin beneficio real porque los agentes no dependen entre sí.

El review gate no bloquea merges. Podés configurar el job final como “required status check” en GitHub, pero si el gate falla por rate limiting del API (no por problemas en el código), estás bloqueando merges por razones de infraestructura. Habría que separar el estado de “el review se completó” del estado de “el review encontró problemas críticos”.

El rate limiting es un problema sin resolver. Cuatro llamadas casi simultáneas en el tier gratuito de Gemini generan 429s con regularidad. Un backoff exponencial con reintentos resolvería el 90% de los casos.

El diff se descarga cuatro veces. gh pr diff ejecutado una vez por revisor. Se podría descargar una sola vez, guardar en un archivo temporal y que cada agente lo lea de ahí.

¿Son problemas de diseño o decisiones? La multiplicidad de perspectivas (4 agentes vs 1 sintético) es definitivamente una decisión. Los otros son limitaciones que tienen solución directa. En diferencias entre Claude Code y Gemini profundizamos sobre esto.

Errores comunes al implementar revisión automática de código con IA

Error 1: Usar el mismo prompt para todos los revisores. Si todos los agentes reciben el mismo prompt genérico “revisá este código”, vas a obtener cuatro opiniones casi idénticas. El valor del sistema viene de personas especializadas con criterios diferentes. Sin prompts distintos, es ruido.

Error 2: Tratar los comentarios de IA como verdad absoluta. Los modelos alucinan. El CSO puede “encontrar” una vulnerabilidad que no existe o categorizar mal un patrón. Usá el feedback como input, no como dictamen. Si el agente dice que hay un SQL injection, verificalo antes de cerrar el PR.

Error 3: No configurar el fetch-depth correctamente. Con fetch-depth: 1 (el default de actions/checkout), el diff puede salir incompleto o el comando gh pr diff puede fallar silenciosamente. El resultado son reviews vacíos o con contexto incorrecto. Siempre revisá este parámetro primero cuando algo no funciona.

Error 4: Ignorar el contexto del codebase en el prompt. Un diff sin contexto del proyecto hace que el agente no pueda evaluar si una decisión de arquitectura tiene sentido para ese sistema específico. Incluir un resumen del proyecto o las convenciones del equipo en el system prompt mejora notablemente la calidad del feedback.

Preguntas Frecuentes

¿Cómo automatizar la revisión de código en GitHub con IA?

Creás un workflow YAML en .github/workflows/ que se dispara en eventos de pull request, y un script que extrae el diff con gh pr diff y lo envía a una API de IA (Gemini, Claude, GPT-4). El script publica el resultado como comentario en el PR usando la GitHub API. El sistema de Ponali hace exactamente esto con dos archivos y sin infraestructura adicional.

¿Se puede usar Gemini para revisar pull requests automáticamente?

Sí. Existe una GitHub Action oficial de Gemini Code Review en el Marketplace y también podés integrar la API directamente. Con Gemini 2.0 Flash el costo es de aproximadamente USD 0,01 por PR. El problema principal en el tier gratuito es el rate limiting cuando hacés múltiples llamadas simultáneas.

¿Cuánto cuesta revisar código con IA en GitHub Actions?

Con Gemini 2.0 Flash, alrededor de USD 0,01 por PR. Con 4 revisores por PR, el costo se multiplica pero sigue siendo marginal: USD 2-5 por semana para un equipo con 50 PRs. Los minutos de GitHub Actions también tienen costo si superás el tier gratuito (2000 min/mes en repos privados).

¿Qué agentes IA puedo usar para revisar código en GitHub?

Las opciones principales son: Gemini (vía API directa o Action del Marketplace), PR-Agent (open source, soporta 20+ modelos), CodeRabbit (USD 12/dev/mes), y Qodo. También podés usar Claude vía Anthropic API o GPT-4 con la misma arquitectura de script Python. La elección depende de si preferís control total (API directa) o conveniencia (herramienta dedicada).

¿Cómo implementar un workflow de revisión automática con múltiples revisores IA?

Definís un job por revisor en el YAML, cada uno con su prompt especializado. Los jobs corren en paralelo para que no se lean entre sí antes de comentar. El script Python recibe el nombre de la persona como argumento, carga el prompt correspondiente, llama a la API y publica el comentario. El repositorio de Ponali muestra esta arquitectura completa en ~120 líneas de Python más el YAML de orquestación.

Conclusión

Lo que Ponali publicó no es un concepto teórico: es un sistema funcionando en producción sobre una app real, con costos concretos, limitaciones documentadas y código disponible. El modelo de múltiples personas especializadas sobre el mismo diff tiene sentido técnico, y el costo de USD 0,01 por PR hace que la barrera de entrada sea mínima.

El sistema tiene deuda técnica propia (cadena secuencial innecesaria, rate limiting sin reintentos, diff descargado múltiples veces) pero es funcional. Para desarrolladores solos o equipos chicos sin revisores disponibles, es mejor que ningún review. Para equipos más grandes, conviene evaluar PR-Agent o CodeRabbit antes de construir algo desde cero.

Lo que sí queda claro es que la revisión automática de código con IA dejó de ser ciencia ficción. Con dos archivos, una API key y 30 minutos de setup, podés tener cuatro perspectivas sobre cada PR que llega a tu repositorio. El próximo paso natural es integrar esto con los GitHub Agentic Workflows cuando salgan de technical preview.

Fuentes

• Pratyush Ponali en Dev.to – Implementación completa del sistema de 4 revisores IA
• GitHub Blog – Agentic Workflows en technical preview (febrero 2026)
• GitHub Blog – Automatizar tareas con GitHub Agentic Workflows
• GitHub Marketplace – Gemini AI Code Review Action
• Google Codelabs – GenAI para revisión de código en GitHub