Un Pull Request con 47 archivos modificados llega a la cola de revisión. El revisor lo abre, ve el diff y pasa los primeros 15 minutos solo entendiendo qué cambió y por qué. ¿Qué archivos son refactorizaciones estructurales? ¿Cuáles contienen el cambio de lógica real? ¿La cobertura de pruebas es adecuada?
Para un equipo que hace 10 PRs por semana, ese tiempo de orientación — los 15 minutos antes de que la revisión real comience — suma 2.5 horas semanales. La revisión de código es valiosa. La fase de orientación no lo es.
Qué hace el flujo de trabajo
El flujo de trabajo PR Review Summarizer se activa en eventos de PR y produce un resumen de revisión estructurado:
-
PR abierto o actualizado — Se activa via webhook de GitHub, obtiene el diff completo, la descripción del PR, issues vinculados e historial de commits.
-
La IA analiza el diff — La IA lee cada archivo modificado y produce:
- Resumen: 2-3 párrafos describiendo qué hace el PR y por qué
- Desglose de cambios: archivos agrupados por propósito — pruebas, configuración, lógica principal, refactorización
- Evaluación de riesgo: calificación alto/medio/bajo con razones específicas
- Problemas potenciales: preocupaciones específicas que el revisor debería examinar
- Cobertura de pruebas: si el código nuevo tiene pruebas correspondientes
-
Resumen publicado como comentario del PR — El análisis se publica como comentario formateado en el PR, visible inmediatamente para los revisores.
El análisis toma 30-60 segundos.
Tiempo ahorrado
10 PRs por semana: tiempo de orientación sin resumen aproximadamente 15 min/PR = 2.5 h/semana, con resumen aproximadamente 3 min/PR = 30 min/semana. Ahorro neto: 2 horas/semana. La mejora de calidad es más difícil de medir pero real.
Lo que el humano sigue haciendo
La IA resume y señala, los humanos revisan. Las decisiones de arquitectura, la validación de lógica de negocio, los estándares del equipo y las aprobaciones siguen siendo responsabilidad del revisor. Los resúmenes de PR complementan la revisión humana.