Por qué dos IAs pueden revisar el mismo código y decirte cosas completamente distintas

#ai #llm #softwareengineering #codereview

En mi trabajo actual estamos probando distintas IAs para el code review. Mismo prompt, mismo pull request... y cada modelo marca observaciones distintas. Algunas hasta reportan bugs que no existen — falsos positivos que terminan generando más trabajo del que ahorran.

Lo primero que uno piensa es "algo estamos configurando mal". Pero después de leer varios papers y experimentos de otros equipos, la conclusión es otra: esto no es un error de configuración, es una propiedad del sistema.

- "La IA te hace 10x más rápido."
+ El cuello de botella no desapareció.
+ Solo se movió: de escribir código a
+ entender el código de otro (o de otra IA).

No es cosa nuestra: hay investigación seria detrás

Los mismos commits, temperatura en cero, y aun así resultados distintos

Un grupo de investigadores evaluó cuatro modelos —GPT-4o, GPT-4o mini, Claude 3.5 Sonnet y LLaMA 3.2 90B— revisando los mismos 70 commits de Java. Configuraron la temperatura en cero (el parámetro que en teoría reduce la aleatoriedad al mínimo), repitieron el mismo prompt cinco veces por modelo, y aun así las evaluaciones de calidad y mantenibilidad del código variaron entre corridas. Si la temperatura en cero no garantiza el mismo resultado, "correr el mismo prompt dos veces" no es una forma confiable de verificar nada.

Buena parte de las tareas de generación de código simplemente no son reproducibles

Otro estudio, esta vez sobre generación de código con ChatGPT, corrió 829 problemas en tres benchmarks distintos (CodeContests, APPS y HumanEval) pidiendo el mismo código varias veces. Dependiendo del benchmark, entre el 48% y el 76% de las tareas arrojaron resultados que no pasaban las mismas pruebas entre una ejecución y otra — es decir, casi la mitad (y en el peor caso, tres de cada cuatro) de las veces el modelo te da algo funcionalmente distinto para el mismo pedido.

3, 6, 11: el experimento que lo resume todo

Semgrep documentó un caso muy directo: corrieron el mismo prompt de seguridad sobre el mismo código, tres veces, sin cambiar nada. Los resultados fueron 3, luego 6, y luego 11 hallazgos distintos. Su hipótesis es algo llamado "context compaction": cuando el modelo procesa mucho código a la vez, comprime esa información de forma que pierde detalles específicos en el camino — y esa pérdida no es igual cada vez.

En la práctica pasa exactamente lo mismo

No es solo en papers académicos. Alguien corrió cuatro herramientas de IA para code review (CodeRabbit, GitHub Copilot, Codacy y Cursor) sobre unos 40 pull requests reales durante ocho semanas, en una base de código de ~180K líneas. El patrón fue el mismo que describo arriba: algunas herramientas atrapaban patrones de inyección SQL de inmediato; otras aprobaban código con condiciones de carrera evidentes porque estaban más enfocadas en si la funcionalidad estaba completa.

En otra prueba, sobre un monorepo de 450K archivos, una de las herramientas evaluadas sí encontraba errores de lógica reales que las herramientas basadas en reglas no detectaban — pero cerca de un tercio de sus sugerencias necesitaban verificación humana para saber si eran relevantes o falsos positivos.

El problema no es "qué tan buena es la IA"

Hay un experimento interesante donde tres modelos distintos (Claude, Codex y Gemini) revisan el mismo diff por separado, sin contaminarse entre sí. Seguían sin coincidir. La conclusión de quien hizo la prueba no fue "necesito un modelo mejor", sino que sin una definición explícita de qué significa "correcto" para ese cambio de código, cada reviewer —humano o IA— está respondiendo una pregunta distinta aunque parezca la misma.

¿Por qué pasa esto?

Juntando lo anterior, hay al menos cuatro causas que se solapan:

Muestreo probabilístico: un LLM no ejecuta una lógica fija, elige cada palabra siguiente de una distribución de probabilidad. Incluso a temperatura cero, diferencias a nivel de hardware en cómo se distribuye el cálculo entre GPUs pueden introducir variación.
Context compaction: al procesar diffs o archivos grandes, el modelo comprime información, y esa compresión no siempre conserva los mismos detalles de una corrida a otra.
Efecto de anclaje: si el modelo "engancha" con un tipo de problema al inicio (por ejemplo, null-safety), tiende a seguir buscando variantes de ese mismo problema y a pasar por alto otros, como condiciones de carrera.
Falta de un contrato compartido: sin una especificación explícita de qué debe hacer el código, cada reviewer (humano o IA) define "correcto" a su manera. ## Qué dice la evidencia que ayuda (y qué estamos probando)

Ningún estudio dice "no uses IA para code review". Todos apuntan a lo mismo: un solo pase, con un prompt genérico, no es suficiente.

Rúbricas estructuradas en vez de prompts abiertos. Un prompt tipo "revisa este código" da resultados inconsistentes. Uno con categorías explícitas, niveles de severidad y formato de salida fijo da resultados más comparables entre corridas.
Agregar varias corridas en vez de confiar en una sola. Un estudio (SWR-Bench) reportó que correr la revisión diez veces y combinar los resultados aumentó el recall (el % de bugs reales detectados) en 118% frente a un solo pase.
Prompts especializados por tipo de problema, en vez de un prompt genérico que intenta cubrir seguridad, lógica y diseño a la vez. Separar "revisor de seguridad", "revisor de lógica", "revisor de I/O" da mejores resultados que pedirle todo a un solo prompt.
Un humano que arbitra, no que revisa línea por línea. El rol cambia: la IA saca candidatos a la superficie, la persona decide cuáles importan y cuáles son ruido. Eso sigue siendo supervisión real, solo que distinta a leer las 600 líneas del diff.
Definir el contrato antes de programar. Si el equipo (o el prompt) no tiene claro qué debía hacer el cambio, cualquier reviewer —humano o IA— está adivinando qué significa "correcto". ## Para cerrar

Si en tu equipo también están viendo que dos IAs revisan el mismo PR y te dicen cosas distintas, no es que estén usando mal la herramienta — es un fenómeno documentado tanto en papers académicos como en pruebas de otros equipos en producción. La pregunta que vale la pena hacerse no es "¿cuál IA es la correcta?", sino "¿tenemos un criterio compartido de qué es 'correcto' antes de preguntarle a cualquiera de ellas?".

¿Ya les pasó algo parecido? Cuéntenme cómo lo están manejando en los comentarios.

DEV Community