Los agentes reemplazan al revisor, no a la revisión

En junio de 2026, Martin Monperrus, investigador de ingeniería de software conocido por la reparación automatizada de programas, publicó un artículo titulado El fin de la revisión de código: los agentes de programación reemplazan la inspección humana. El argumento es que los agentes de programación han cruzado un umbral de capacidad en el que tener a un humano que examine un diff antes de hacer merge ya no es una compuerta de calidad necesaria, y que el esquema habitual en el que los agentes escriben código y los humanos siguen siendo los revisores obligatorios es un callejón sin salida.¹

El artículo acierta en más cosas de las que sus críticos admitirán, y se equivoca en un punto específico que sí importa. Los agentes han reemplazado al revisor: el humano que lee un diff línea por línea buscando defectos hace un trabajo que un conjunto de agentes ahora realiza mejor y en cada commit. Pero el artículo confunde ese rol con la revisión misma. Cuando de verdad ejecutas el flujo de agentes que prescribe, el trabajo humano no desaparece. Se reubica, desde inspeccionar el código hacia hacerse responsable de la intención que el código debía satisfacer. Yo ejecuto ese flujo. El revisor está muriendo. La revisión está subiendo en la pila.

Quiero tomar en serio el artículo, porque la mayoría de las respuestas que recibirá no lo harán. La réplica refleja es “pero los agentes alucinan”, y Monperrus ya lo concede. El compromiso honesto empieza por reconocer lo que él acierta.

En resumen

• Monperrus sostiene que los agentes de programación han acabado con la necesidad de la revisión humana de código, porque cada objetivo de la revisión (detección de defectos, estilo, seguridad, transferencia de conocimiento) lo atienden mejor y de forma más barata los agentes, y la capacidad de revisión humana no puede escalar al ritmo del rendimiento impulsado por agentes.¹
• Tiene razón en que la casilla obligatoria de aprobación humana está acabada, y tiene razón en que los agentes hacen la inspección sistemática mejor que un humano cansado que ojea un diff grande.
• No es ingenuo al respecto: el artículo concede la alucinación, la inyección de prompts, la correlación de puntos ciegos de seguridad, y reserva a los humanos para los cambios de alto riesgo, novedosos, regulados y éticos.¹
• La brecha es que trata el rol humano residual como un pequeño conjunto de escalamientos. En producción es el centro que soporta la carga: el agente optimiza para la especificación que se le dio, y escribir esa especificación y hacerse responsable de ella es el acto irreductiblemente humano.
• El rol de revisor se está automatizando. La revisión, entendida como el juicio sobre si el software es correcto para su propósito, se está reubicando hacia donde el agente no puede seguir.

En qué acierta el artículo

Monperrus se apoya en la enumeración de Bacchelli y Bird sobre por qué los equipos revisan código: detección de defectos, aplicación de estilo y estándares, transferencia de conocimiento y conciencia de equipo, con la seguridad como quinta dimensión.¹² Su movimiento consiste en tomar cada objetivo y argumentar que un agente lo cumple mejor. Los agentes inspeccionan cada commit sin fatiga ni demora por husos horarios. Enumeran clases de vulnerabilidades de forma más sistemática que un humano haciendo una pasada improvisada. Generan resúmenes arquitectónicos y documentación actualizada en el momento del merge. El artículo despliega la curva de capacidad de SWE-bench para sostener el caso del umbral, desde que el mejor modelo resolvía menos del 2 por ciento de los issues reales de GitHub cuando el benchmark se lanzó en 2023 hasta que los mejores agentes superaron el 70 por ciento a finales de 2025.¹³

No tengo nada que objetar a esta parte, porque la veo funcionar a diario. Mi bucle de construcción autónomo ejecuta una compuerta de tres revisores: agentes separados verifican la corrección, las convenciones y la seguridad antes de que el código haga merge, y un segundo bucle envía la implementación a un modelo independiente para una pasada adversarial. Esos agentes detectan defectos reales, y los detectan en cada cambio, no solo en los cambios para los que un humano tuvo tiempo. Las dos publicaciones que precedieron a esta en este sitio pasaron cada una por un evaluador agente que las calificó contra una rúbrica y señaló problemas factuales específicos que luego tuve que corregir. La afirmación del artículo de que los agentes producen resultados de revisión accionables y estructurados, comparables a los de un revisor entrenado, no es especulativa para mí. Es mi martes cualquiera.

El argumento del rendimiento también es correcto, y es la parte que la gente subestima. Un desarrollador asistido por agentes produce más pull requests por día de los que puede absorber la capacidad de revisión humana. Cuando quien escribe es rápido y quien revisa es un humano, la cola de revisión se convierte en la restricción limitante, y la revisión degenera en una formalidad realizada bajo presión de tiempo.¹ Monperrus tiene razón en que el arreglo ingenuo, los agentes escriben y un humano da el visto bueno, no ofrece ninguna garantía real. Un humano que aprueba porque el código parece correcto y las pruebas pasan no está revisando. Está firmando.

El flujo que describe es el que yo ejecuto

Lo que el artículo propone para reemplazar la revisión humana no es “confía en un solo modelo”. Es un flujo de verificación con agentes en el bucle: múltiples agentes independientes, idealmente modelos distintos, que producen un visto bueno calibrado y estructurado (cobertura de pruebas, escaneos de seguridad, trazas de razonamiento como JSON o SARIF, el formato estándar de intercambio de resultados de análisis estático) en lugar de hilos informales de comentarios, con agentes instruidos para abstenerse cuando hay incertidumbre y humanos reservados para los casos difíciles.¹

Esa es, con otros nombres, la arquitectura que he estado construyendo y sobre la que he estado escribiendo durante un año. He argumentado que las pull requests de los agentes necesitan superficies de revisión más pequeñas, que la revisión automatizada necesita disenso en lugar de un único juez seguro de sí mismo, y que los paquetes de revisión de evidencia estructurada están reemplazando al comentario informal sobre el diff. Así que no estoy argumentando en contra del flujo. Yo ayudé a construir el caso a su favor. Estoy discutiendo qué le queda al humano una vez que el flujo existe, porque he vivido dentro de la respuesta, y no es la respuesta que da el artículo.

Dónde se rompe el argumento: la revisión nunca fue solo inspección

Monperrus reserva al humano para los cambios de alto riesgo, la arquitectura novedosa, las rutas de código reguladas y el juicio ético, y los enmarca como escalamiento: excepciones derivadas a una persona cuando los agentes las señalan.¹ El encuadre hace que el rol humano suene como una interrupción rara en una línea por lo demás automatizada.

Operar la línea enseña lo contrario. El agente no genera su propio propósito. Optimiza para la especificación que se le entrega, y en cada cambio que importa, alguien tiene que decidir qué significa correcto antes de que los agentes puedan verificar algo contra ello. El propio artículo admite el límite en su sección de discusión: los agentes optimizan para métricas de calidad técnica y no están equipados de forma confiable para notar que un cambio de telemetría viola la expectativa razonable de privacidad de un usuario, o que un ajuste de ranking amplifica un sesgo.¹ Eso se presenta como una limitación en los bordes. No está en los bordes. La pregunta “¿es este cambio correcto para lo que realmente queremos?” se sitúa en el centro de cada merge no trivial, y es exactamente la pregunta que un agente calibrado a una especificación no puede hacer sobre la especificación.

Sentí esto de forma concreta en las dos publicaciones que lancé antes de esta. El revisor agente las calificó y detectó un exceso factual en cada una: una afirmación institucional no verificada en una, una estadística mal atribuida en la otra. La detección fue del agente. La corrección no. Decidir cómo corregir un exceso de manera veraz, qué fuente respaldaba en realidad la afirmación, cuál era la versión honesta de la frase, requirió un juicio sobre la intención que la rúbrica podía señalar pero no resolver. El agente encontró que algo estaba mal. Un humano decidió cómo se veía lo correcto. Esa división del trabajo es la reubicación, y ocurrió en contenido rutinario, no en un caso límite regulado.

Así que el humano no abandona el bucle. El humano se mueve del final al principio. La revisión solía ser el último punto de control, una persona inspeccionando código terminado. En un flujo de agentes la inspección está automatizada y el trabajo humano irreductible se mueve al frente: especificar la intención con suficiente precisión como para que los agentes tengan algo verdadero contra lo que verificar, y hacerse responsable de las consecuencias cuando el resultado entregado cumple con la especificación pero no da en el blanco. La responsabilidad no puede delegarse a un sistema que optimiza para métricas, porque la responsabilidad es la disposición a equivocarse a propósito y responder por ello.

La versión honesta de la afirmación

Quita la provocación del título y la afirmación defendible es más estrecha que “el fin de la revisión de código”. La afirmación defendible es el fin del humano como inspector de diffs y casilla obligatoria de aprobación. Ese rol está genuinamente acabado, y fingir lo contrario para proteger un ritual cómodo es su propia forma de deshonestidad. Los equipos que mantienen a un humano en el asiento de inspección como teatro, aprobando código de agentes que en realidad no pueden escrutar, ya han perdido la garantía que creen tener.

Pero “revisión de código” siempre fue una palabra sustituta. Nombraba un punto de control y significaba un juicio: ¿este cambio hace lo que necesitamos, de forma segura, de una manera que podamos respaldar? Automatiza el punto de control y el juicio no se evapora. Se reubica hacia la especificación de la intención a la entrada y la responsabilidad a la salida, y en un equipo que se mueve a velocidad de agente se vuelve más importante, no menos, porque los agentes construirán fiel y rápidamente lo que diga la especificación, incluida la cosa equivocada. Cuanto más rápido es quien escribe, más se convierte el cuello de botella en saber qué pedir. Monperrus tiene razón en que el revisor está siendo reemplazado. Se equivoca en que la revisión está terminando. Se está moviendo hacia el único asiento que el agente no puede ocupar.

Conclusiones clave

Para líderes de ingeniería: - Deja de dotar de personal a la revisión humana como inspección de diffs. Los agentes lo hacen mejor y de forma continua; una casilla de aprobación humana sobre código de agentes es teatro de garantía. - Reasigna esa capacidad humana a la especificación de la intención y la responsabilidad, las partes de la revisión que determinan si lo correcto según la especificación es correcto de hecho.

Para constructores de herramientas para desarrolladores: - Construye el flujo de revisión en conjunto que describe el artículo: múltiples modelos, abstención calibrada, visto bueno estructurado. El disenso entre revisores es la señal. - Diseña el frente del flujo, no solo la compuerta. La superficie de mayor valor es donde un humano convierte la intención en una especificación contra la que los agentes pueden verificar.

Para ingenieros: - Tu habilidad de revisión no se está volviendo inútil; está cambiando de domicilio. El valor se mueve desde detectar el error en el diff hacia definir qué se suponía que el código debía hacer y hacerse responsable del resultado.

Preguntas frecuentes

¿Significa este artículo que la revisión humana de código terminó?

El humano como inspector de diffs línea por línea y aprobador obligatorio terminó, que es el punto más fuerte del artículo: los agentes hacen la inspección sistemática mejor y en cada commit. Lo que no termina es el juicio del que la revisión de código era un sustituto, a saber, si un cambio es correcto para su propósito real. Ese juicio se reubica hacia especificar la intención y hacerse responsable de las consecuencias en lugar de desaparecer.

¿Qué argumenta Monperrus en realidad?

Que los agentes de programación ahora atienden cada objetivo declarado de la revisión de código (detección de defectos, estilo, transferencia de conocimiento, seguridad) a menor costo y mayor rendimiento, y que mantener a los humanos como revisores obligatorios del código escrito por agentes es un callejón sin salida porque no da ninguna garantía real y no puede escalar. Propone un conjunto de agentes que produce un visto bueno estructurado, con humanos reservados para los casos de alto riesgo y éticos. Es un artículo de posición, no un estudio empírico.¹

¿Dónde es más débil el argumento?

En tratar el rol humano residual como un escalamiento raro. En la práctica el rol humano soporta la carga en cada cambio no trivial, porque el agente optimiza para una especificación que no puede crear ni cuestionar. Definir la especificación y responder por el resultado es trabajo central, no un caso límite.

¿Deberían los equipos mantener un paso de aprobación humana en las pull requests de los agentes?

No como teatro de inspección. Si el humano no puede escrutar genuinamente el cambio, la aprobación es una firma, no una revisión. Es mejor invertir el esfuerzo humano aguas arriba, en especificar la intención con precisión, y aguas abajo, en hacerse responsable del resultado entregado, mientras se deja que un conjunto de agentes haga la inspección.

Fuentes

• Martin Monperrus, “The End of Code Review: Coding Agents Supersede Human Inspection”, arXiv, 11 de junio de 2026: arxiv.org/abs/2606.13175. Un artículo de posición que sintetiza la evidencia de capacidad existente; enumera los objetivos de la revisión de código a partir de Bacchelli y Bird, cita la curva de capacidad de SWE-bench y analiza limitaciones que incluyen la alucinación, la inyección de prompts y la responsabilidad ética.
• Alberto Bacchelli y Christian Bird, “Expectations, Outcomes, and Challenges of Modern Code Review”, ICSE 2013, la fuente empírica de la taxonomía de objetivos de revisión sobre la que se construye el artículo: Microsoft Research
• Carlos E. Jimenez et al., “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?”, ICLR 2024, el benchmark detrás de la curva de capacidad (el mejor modelo resolvió el 1,96% en su lanzamiento): arxiv.org/abs/2310.06770
• Escritos relacionados sobre la revisión con agentes desde la experiencia en producción: superficies de revisión más pequeñas, la revisión necesita disenso, paquetes de revisión, y el bucle de construcción autónomo cuya compuerta de tres revisores es el flujo que esta publicación describe ejecutar.