Cada commit que envío ahora es revisado por una IA antes de que cualquier humano lo vea. No porque no confíe en mi propio código, sino porque no confío en mi propia atención a las 11 PM de un viernes cuando intento enviar una corrección antes del fin de semana.
El revisor de IA detecta cosas que yo paso por alto: una variable declarada pero nunca utilizada, una clave API accidentalmente dejada en un comentario, una función que maneja la ruta feliz pero falla con entradas vacías. Cosas pequeñas. El tipo de cosas que la revisión de código existe para atrapar, pero que los revisores humanos cansados también pasan por alto.
Aquí te muestro cómo conecté OpenClaw a GitHub Actions para una revisión de código automatizada asistida por IA.
La Configuración
Disparador: Un flujo de trabajo de GitHub Action que se ejecuta en cada pull request. Cuando se abre o se actualiza un PR, el flujo de trabajo se activa.
Qué hace: El flujo de trabajo extrae el diff del PR, lo envía a OpenClaw para su revisión y publica la revisión como un comentario en el PR. Tiempo total de ejecución: 30-60 segundos, dependiendo del tamaño del diff.
Qué revisa OpenClaw:
1. Errores: referencias nulas, errores de uno fuera, casos límite no manejados
2. Seguridad: secretos codificados, patrones de inyección SQL, configuraciones inseguras por defecto
3. Estilo: inconsistencias con la base de código, nombres de variables poco claros, comentarios faltantes en lógica compleja
4. Rendimiento: ineficiencias evidentes, bucles innecesarios, consultas no optimizadas
Qué no revisa: Decisiones arquitectónicas, diseño de características, corrección de la lógica de negocio. Estas requieren un contexto humano que la IA no tiene.
El Flujo de Trabajo de GitHub Action
El flujo de trabajo es sencillo:
1. Revisar el código
2. Extraer el diff entre la rama del PR y la principal
3. Enviar el diff a OpenClaw a través de su API (o CLI)
4. Formatear la respuesta como un comentario en el PR
5. Publicar el comentario
La extracción del diff es el paso importante. No envías toda la base de código, solo los cambios. Esto mantiene la cantidad de tokens razonable (y el costo bajo), mientras se enfoca la revisión en lo que realmente cambió.
Para PRs grandes (500+ líneas de cambios), divido el diff por archivo y reviso cada archivo por separado. Esto produce una retroalimentación más enfocada que lanzar todo al modelo de una vez.
La Calidad de la Revisión
Después de 3 meses y aproximadamente 200 PRs revisados:
Verdaderos positivos (detectados problemas reales): Alrededor del 25% de las revisiones. Aproximadamente uno de cada cuatro PRs tiene algo que la IA detecta y que es importante. Lo más común: manejo de errores ausente, nombres inconsistentes, variables no utilizadas.
Sugerencias útiles (no errores, sino mejoras): Alrededor del 40% de las revisiones. Mejoras de estilo, sugerencias de legibilidad, brechas en la documentación. No son críticas, pero son útiles.
Falsos positivos (incorrectos o irrelevantes): Alrededor del 35% de las revisiones contienen al menos una sugerencia incorrecta. La IA malinterpreta el contexto, sugiere cambios que romperían la funcionalidad o señala patrones intencionales como problemas.
La tasa de falso positivo del 35% suena alta, pero en la práctica es manejable. Los comentarios están claramente etiquetados como generados por IA, y los desarrolladores aprenden rápidamente qué sugerencias tomar en serio y cuáles ignorar.
Haciendo que Sea Útil en Lugar de Molesto
La diferencia entre un revisor de IA útil y uno molesto:
Prioriza los hallazgos. Etiqueta cada hallazgo como: 🔴 Error (arreglar antes de fusionar), 🟡 Advertencia (considerar arreglar), 🟢 Sugerencia (mejora opcional). Los desarrolladores abordan los ítems rojos, consideran los amarillos y hojean los verdes.
Sé específico. “Puede haber un problema con el manejo de errores” es inútil. “La función `processOrder()` en la línea 47 no maneja el caso en que `order.items` está indefinido, lo que generará un TypeError” es accionable.
No repitas lo obvio. Los desarrolladores saben que deben escribir pruebas. No se lo digas en cada PR. Concéntrate en hallazgos específicos y no obvios.
Limita la cantidad de comentarios. Establece un límite de 5 comentarios por revisión de IA por PR. Si hay más problemas que eso, prioriza y muestra los 5 principales. Un PR con 20 comentarios de IA se ignora por completo; un PR con 3-5 comentarios enfocados se lee.
Más Allá de la Revisión de Código
Una vez que la integración de GitHub Actions está funcionando, puedes extenderla:
Generación de descripción del PR. Cuando se abre un PR con una descripción vacía, la IA lee el diff y genera un resumen: qué cambió, por qué probablemente cambió y qué buscar durante la revisión.
Análisis de cobertura de pruebas. La IA verifica si el código cambiado tiene cambios de prueba correspondientes. “Modificaste `auth.js` pero no actualizaste `auth.test.js` — ¿la actualización de la prueba fue intencional o olvidada?”
Sugerencia de entrada para el changelog. Basada en el diff, la IA sugiere una entrada para el changelog en el formato apropiado. El desarrollador la aprueba o la edita.
Compilación de notas de lanzamiento. Cuando es el momento de liberar, la IA compila todos los PRs fusionados desde el último lanzamiento y genera notas de lanzamiento. Esto ahorra entre 30 y 60 minutos por lanzamiento.
El Costo
Costo promedio por revisión de PR: alrededor de $0.08.
Costo mensual por 200 PRs: alrededor de $16.
Para contexto, un humano que pasa 15 minutos revisando cada uno de esos PRs gastaría 50 horas al mes en revisión de código. La IA no reemplaza la revisión humana, la pre-procesa, atrapando los problemas mecánicos para que los humanos puedan enfocarse en el diseño y la lógica.
El proceso de revisión de mi equipo ahora: revisión de IA primero (automatizada, 30 segundos). Revisión humana segundo (enfocada en lo que la IA no puede evaluar, típicamente de 5 a 10 minutos en lugar de 15). Calidad total de la revisión: más alta que antes, en menos tiempo.
🕒 Published: