¿Podemos confiar en las revisiones con IA?
(medium.com)Compartimos el proceso de medir cuantitativamente y mejorar la calidad mientras operábamos una herramienta interna de revisión con IA, para responder preguntas como: "¿Podemos confiar en las revisiones con IA?" y "¿De verdad está validando bien?"
Contexto
- El código generado por IA tiene 1.7 veces más issues por PR y 75% más errores de lógica que el código humano (CodeRabbit)
- Tras una falla provocada por código de IA, Amazon hizo obligatoria la aprobación de PR por parte de seniors, y Shopify prohibió el auto-merge de PR generados por IA
- En este contexto, la revisión con IA se introdujo como un medio de validación para detectar issues y errores de forma temprana
- Sin embargo, como la revisión con IA en sí es no determinista, primero había que medir si "este medio de validación realmente está validando bien"
Construcción de un benchmark propio
- Hotfix PR → rastreo retrospectivo al PR original para medir si "la revisión con IA habría podido detectar este bug en el momento original"
- Solo se incluyeron casos que podían juzgarse únicamente con el diff del PR; se excluyeron los que requerían contexto externo
- La evaluación se hizo con GPT-4o mini como LLM-as-a-Judge. Aunque los valores absolutos no sean precisos, sí bastan para comparaciones relativas
- La puntuación inicial fue 33. La sensación de que "lo estaba haciendo bien" era una ilusión causada por unos pocos casos exitosos
Fallo 1 (orquestación de subagentes)
- Se intentó una estructura con subagentes especializados por área, dirigidos por un agente principal
- Resultado: tasa de detección ↓, costo 1.5~3 veces ↑
- Tres causas
- Pérdida de información por compresión de contexto
- Reducción del campo de visión por limitar los intereses
- Vacíos de responsabilidad entre áreas cruzadas
Fallo 2 (contaminación del benchmark)
- Al automatizar el ajuste de prompts en bucle, convergió en una lista de instrucciones del tipo "revisa Division by Zero"
- SWE-bench también ya está contaminado
- Se confirmó que con benchmarks externos no se puede justificar la elección de modelo
Nueva métrica (Adoption Rate)
- adopted: la revisión llevó a cambios reales en el código
- engaged: no hubo cambios, pero sí interacción en respuestas (se reconoció el valor de la validación cruzada)
- noised: no hubo ni cambios ni respuestas
- Método de evaluación: comparar el commit SHA del momento de la revisión con el SHA del merge, y considerar adopted si hubo cambios dentro de ±3 líneas de la línea comentada
A/B entre Opus 4.6 y GPT-5.2 Codex
- Se dividieron los modelos según PR con número par/impar y se compararon cerca de 100 PR
- Opus 4.6: rápido y creativo, pero menos meticuloso; aprueba con facilidad
- GPT-5.2 Codex: más lento pero meticuloso; incluso al volver a solicitar revisión seguía señalando puntos válidos adicionales
- Tras fijarlo en Codex, la tasa de adopción semanal alcanzó un máximo de 60%
Tres medidas que elevaron la tasa de adopción
- Question: cuando no hay certeza, formular preguntas en vez de señalar directamente
- Secciones Intent/Decisions en la plantilla de PR
- Intent: con la skill
create-pr, insertar la respuesta a la pregunta "¿por qué es necesario?" - Decisions: con el hook Claude Stop, extraer automáticamente las decisiones de la sesión de conversación
- Los falsos positivos causados por falta de contexto del revisor se redujeron hasta en ~29%
- Intent: con la skill
- Resolución automática de hilos: cuando se confirma que la revisión fue aplicada, la IA cierra el hilo por sí sola
Resultado
- Se logró una tasa de adopción mensual de 63% (al 2026-04-17)
- Como todas las acciones se basan en datos, también es posible decidir los siguientes experimentos con fundamento
- También hay que tener cuidado con que Adoption Rate tampoco garantiza que "adopción = respuesta correcta", por lo que esta métrica también puede contaminarse
4 comentarios
Vaya... suena como "¿quién vigila a los vigilantes?"
Con la "herramienta de verificación" que mencioné arriba me refería a un revisor de IA. Como la IA no es determinista, mi intención era decir que primero se necesita una línea base (benchmark) para medir la calidad de las revisiones hechas por IA, pero desde la perspectiva de quien lo lee también podría interpretarse como que primero hay que cuestionar la validez del benchmark en sí.
Creo que redacté la frase de forma ambigua y eso pudo haber causado confusión. ¡Gracias por señalarlo..!
En lo personal, uso modelos distintos para escribir código y para revisarlo.
Por experiencia, Claude tiende a considerar como bien escrito el código que hizo Claude, y ChatGPT tiende a ver como mejor escrito el código que hizo ChatGPT.
Estaba usando Codex para la etapa de planificación y la etapa de verificación, así que parece que lo estaba haciendo bien.