Code review con IA: el paper que lo da por muerto falla

Acabas de leer el titular de un paper que dice que el code review humano ha terminado, y ya tienes el dedo encima de quitar la revisión obligatoria de tu pipeline y dejar que un agente apruebe los PR. Antes de hacerlo: el paper que te lo sugiere no aporta un solo estudio empírico propio. Lo dice su propio abstract.

TL;DR

• Qué es: un paper titulado "The End of Code Review" sostiene que los agentes de codificación ya cubren todos los objetivos del code review humano y que mantenerlo obligatorio sale económicamente negativo para cambios rutinarios.
• El matiz que importa: es un position paper argumentativo, no un estudio con datos. Reconoce textualmente que no presenta evidencia empírica nueva, solo sintetiza capacidades ya publicadas.
• Qué te llevas: una tabla de decisión para saber cuándo dejar que un agente revise solo, cuándo usarlo como segunda opinión y cuándo el humano sigue siendo obligatorio.

Qué ha pasado

Martin Monperrus, investigador del KTH Royal Institute of Technology, publicó "The End of Code Review: Coding Agents Supersede Human Inspection" en arXiv. La tesis es directa: los agentes de codificación (un LLM en un bucle que lee, escribe, ejecuta tests y repara código) han cruzado un umbral de capacidad en el que el review humano deja de ser una pieza necesaria del pipeline de calidad.

El argumento se apoya en dos claims. Primero, que cada objetivo declarado del code review puede servirlo un agente a menor coste y mayor throughput: detectar defectos, transferir conocimiento, mantener estándares. Segundo, que el modelo intermedio (agentes escriben pero un humano revisa obligatoriamente) es inestable, y que la economía del review humano obligatorio "ya se ha vuelto negativa" para cambios rutinarios.

El detalle clave está en una frase del propio paper: "No presentamos un nuevo estudio empírico; en su lugar, sintetizamos evidencia de capacidades existente". Es una posición, no una medición.

Evidencia y límites

Lo confirmado es poco y lo provisional es mucho. El paper no mide que un agente revise mejor que un humano. Enumera capacidades de agentes documentadas en otros trabajos y deduce la conclusión. En la discusión en Hacker News, varios revisores lo describen como un ensayo persuasivo de nivel introductorio disfrazado de paper académico, porque la sección sobre capacidades de review específicas se reduce a un párrafo sin datos que demuestren superioridad.

La evidencia independiente que sí existe pinta un cuadro más matizado, y conviene separarla del marketing de cada herramienta. Los benchmarks comparativos muestran un trade-off consistente: los LLMs mejoran el recall (encuentran más cosas) pero generan más falsos positivos que los analizadores deterministas. La síntesis de Augment Code sobre esa literatura cita un preprint de enero de 2026 (todavía sin revisión por pares) según el cual los enfoques híbridos LLM más análisis estático eliminan entre el 94% y el 98% de falsos positivos manteniendo alto recall. Trátalo como un rango direccional, no como un número cerrado.

Donde un agente revisor se queda corto está bastante claro en los reportes prácticos: detecta bien problemas de seguridad y errores de lógica, pero flojea en condiciones de carrera y patrones async, justo los bugs sutiles que tampoco pega el humano de un vistazo. Y hay un fallo de raíz que el paper ignora: si el mismo modelo que escribió el código lo revisa, no es review, es sesgo de confirmación a escala. El que escribe rara vez puede juzgar su propia obra con objetividad.

Qué cambia para builders

Que el code review humano "muera" no es la decisión que tienes delante. La decisión real es qué cambios puede aprobar un agente solo y cuáles no, y eso depende del blast radius del cambio, no de lo capaz que sea el modelo en abstracto. Tratarlo como un interruptor de todo o nada es el error.

La parte sólida del paper es esta: para cambios rutinarios y de bajo riesgo (renombrados, bumps de dependencias con tests verdes, fixes mecánicos), exigir que un humano lea cada diff sí es un cuello de botella caro. Ahí un agente revisor como puerta de entrada tiene sentido. La parte que se pasa es extender eso a decisiones de diseño, cambios en límites de servicios o lógica de negocio, donde el contexto que falta no está en el diff.

Esta es la regla de decisión que puedes copiar tal cual:

Tipo de cambio	Quién revisa	Por qué
Renombrados, formato, bumps con tests verdes	Agente solo (auto-merge con política)	Bajo blast radius, verificable por tests. El coste humano no compensa.
Bugfix acotado, refactor interno de un módulo	Agente + humano por excepción	El agente filtra; el humano mira solo si el agente marca duda o toca rutas críticas.
Lógica de negocio, auth, límites entre servicios	Humano obligatorio + agente como segunda opinión	El contexto de negocio no está en el diff. El agente aporta, no decide.
Código generado por IA del mismo modelo	Revisor de otro modelo o humano	Mismo modelo = errores correlacionados. Evita el sesgo de confirmación.

La última fila es la que casi nadie aplica. Si Opus escribe el código, que lo revise un modelo de otra familia (o un humano), no el mismo. Es el mismo principio de separar responsabilidades: quien produce tiene puntos ciegos para validar su propio output. Y si vas a montar el revisor como pieza propia, encaja bien con un esquema de subagentes especializados donde el agente de review corre aislado del que escribió.

Qué haría (y qué no) ahora mismo

Lo que sí: meter un agente revisor en CI como segunda opinión, no como reemplazo. Que comente en el PR, que clasifique findings por severidad, que se centre en bugs, seguridad y correctness, y que excluya estilo y formato (eso lo resuelve un linter más barato). Para cambios triviales con tests sólidos, dejar que apruebe bajo una política explícita de auto-merge.

Lo que no: quitar el humano de los cambios donde el coste de un error es alto solo porque un paper sin datos diga que la economía "ya cambió". Tampoco confiar en el promedio de un benchmark de marketing. Antes de mover nada en producción, mídelo en tu repo: igual que tu evaluación offline puede mentir respecto a producción, el recall de un revisor en un benchmark público no predice cuántos de tus bugs pilla. Coge 20 o 30 PR históricos con bugs conocidos y mide qué encuentra el agente y cuánto ruido mete. Esa es tu cifra, no la del vendedor.

Y elige el modelo del revisor con el mismo criterio escéptico con el que eliges un modelo de coding por benchmark: el que lidera una tabla agéntica no es automáticamente el mejor detectando tus race conditions.

Preguntas abiertas / qué vigilar

• Errores correlacionados: ¿cuánto degrada el review que el revisor y el autor compartan modelo? No hay un estudio sólido todavía; mídelo tú con revisores cruzados.
• Falsos positivos a escala: el rango 94-98% de reducción con híbridos es un preprint sin revisar. Trátalo como hipótesis hasta que se replique.
• Transferencia de conocimiento: el paper asume que las explicaciones del agente sustituyen al aprendizaje que ocurre cuando un humano revisa. Eso está sin demostrar y es donde más críticas recibe.
• Responsabilidad: si un agente aprueba y el cambio rompe producción, ¿quién responde? La política de auto-merge necesita un dueño humano.

Preguntas frecuentes

¿El paper "The End of Code Review" prueba que los agentes revisan mejor que los humanos?

No. Es un position paper que sintetiza capacidades publicadas y argumenta una conclusión; su propio abstract reconoce que no presenta un estudio empírico nuevo. Es una postura defendible, no una medición.

¿Puedo dejar que un agente apruebe pull requests sin humano?

Para cambios de bajo riesgo con tests verdes (formato, renombrados, bumps), con una política de auto-merge explícita y un dueño humano de esa política, tiene sentido. Para lógica de negocio, auth o cambios entre servicios, el humano sigue siendo obligatorio porque el contexto no está en el diff.

¿Por qué no debe revisar el código el mismo modelo que lo escribió?

Porque comparte los mismos puntos ciegos: los errores quedan correlacionados y el revisor valida sus propios sesgos. Es confirmación a escala. Usa un modelo de otra familia o un humano para la segunda pasada.

El takeaway

La pregunta útil no es si el code review humano ha muerto, sino qué cambios puede aprobar un agente sin que te explote nada y cuáles no. El paper acierta en que revisar a mano cada renombrado es un coste que ya no compensa, y se pasa al estirar eso hasta las decisiones de diseño. Mete el agente como segunda opinión, mídelo con tus propios PR antes de darle la llave del merge, y no dejes nunca que el modelo que escribió el código sea el único que lo bendiga. El revisor que no puede equivocarse en contra del autor no está revisando nada.