¿Deberías seguir revisando el código de tu agente de IA?

El argumento comienza de la misma manera en cada equipo. Un lado dice que los agentes ahora envían código más limpio que la mitad de las solicitudes de extracción que solíamos aprobar sin mirar, así que, ¿por qué seguimos leyendo cada línea? El otro lado dice que porque somos los que firmamos.

Ambos lados tienen razón. Esa es exactamente la razón por la que el argumento nunca termina. No termina porque la pregunta es incorrecta, y una vez que arreglas la pregunta, la respuesta se vuelve casi aburrida.

El caso por enviar sin leer cada línea

Comienza con la versión más fuerte del argumento optimista, porque es más fuerte de lo que la mayoría de los revisores admiten.

En una tarea delimitada con una especificación clara y un conjunto de pruebas, un agente de codificación moderno produce código más consistente que el humano medio trabajando bajo una fecha límite. No se aburre en el camino de error. Escribe la verificación nula a las 6 p.m. de un viernes. Sigue las convenciones del proyecto que se le dieron, cada vez, sin las pequeñas rebeliones silenciosas que un desarrollador cansado se permite.

La revisión humana también estaba rota antes de que llegaran los agentes. Cualquiera que haya trabajado en un equipo real conoce el reflejo LGTM: la atención del revisor colapsa después de unas pocas cientos de líneas, y las aprobaciones que siguen son sociales, no técnicas. No perdimos una edad dorada de revisión rigurosa. Perdimos un ritual que ya era mayormente teatro.

Luego está el volumen. Un desarrollador que ejecuta cinco agentes en paralelo genera más diferencias por hora de las que cualquier humano puede leer cuidadosamente. Si tu regla es "lee todo", te has reinstalado silenciosamente como el cuello de botella que acabas de automatizar. Un humano que hojea una diferencia de 900 líneas produce una firma sin producir conocimiento, y eso es peor que no revisar en absoluto, porque fabrica una seguridad donde no la hay.

El caso por mantener a un humano en la diferencia

Ahora el otro lado, que también es más fuerte de lo que los entusiastas admiten.

La responsabilidad no se transfiere. El modelo no recibe alertas a las 3 a.m. No está en la revisión del incidente, no habla con el cliente cuyos datos se filtraron, y no lleva la consecuencia del cambio al siguiente trimestre. Quien fusiona posee el resultado, y revisar es cómo se ejerce la propiedad en lugar de simplemente declararse.

Los revisores de agentes fallan en la misma dirección que los autores de agentes. Este es el argumento que realmente resuelve la propuesta de "solo deja que otro agente lo revise". Dos agentes de la misma familia de modelos, entregados el mismo contexto, comparten antecedentes, comparten datos de entrenamiento y comparten puntos ciegos. Sus errores están correlacionados. Un segundo agente captará felizmente una prueba faltante o un error no manejado, y aprobará felizmente el malentendido sutil de tu dominio que produjo el error en primer lugar, porque hizo el mismo malentendido. Dos revisores que están equivocados en la misma dirección no suman a una revisión.

Las mediciones tampoco son halagadoras. Los datos de la industria muestran que los revisores intercambian significativamente más rondas sobre cambios generados por IA que sobre los escritos por humanos: el código llega más rápido y tarda más en volverse confiable. Un estudio de enero de 2026 fue más allá y encontró que los cambios generados por agentes llevan más redundancia y más deuda técnica acumulada por cambio que los escritos por humanos, mientras que los revisores informan sentirse mejor al aprobarlos. Esa brecha, entre cuán bueno se siente el código y cuán bueno es, es todo el riesgo en una oración.

El debate está mal enmarcado

Aquí está el replanteamiento que termina la reunión.

No estás revisando el código porque desconfíes del autor. Estás revisándolo porque eres el que firma. Esas son actividades completamente diferentes, y todo el argumento proviene de confundirlas.

Una vez que lo ves de esa manera, "¿es el agente mejor que un humano?" deja de ser la pregunta decisiva. La pregunta decisiva es: si este cambio es incorrecto, ¿cuánto cuesta descubrirlo y cuánto cuesta deshacerlo? Un error tipográfico en un encabezado de marketing se descubre en segundos y se revierte en segundos. Una verificación de permisos invertida en un middleware de autorización es descubierta por un cliente, o por un regulador, y nunca se revierte realmente, porque para entonces los datos ya han sido leídos.

Así que la respuesta no es "revisar todo" ni "confiar en el agente". Es:

Dejas de revisar líneas. Comienzas a revisar riesgos.

Concretamente, la revisión se mueve del medio del trabajo a sus dos límites. Antes: lee el plan, porque un plan incorrecto ejecutado perfectamente es el modo de falla más costoso que existe, y un plan son quince líneas en lugar de novecientas. Después: lee la diferencia en proporción al radio de explosión. En medio, las líneas pertenecen a la máquina.

Cómo se ve realmente "el agente se equivocó"

Lo más útil que puedes llevar de vuelta a tu equipo no es una opinión, es una lista de señales objetivas. No "el código se siente mal", sino señales que puedes verificar en una diferencia en menos de un minuto. Estas son las que han ganado su lugar.

1. Las pruebas cambiaron en el mismo commit que el código que cubren. El verde fue construido, no observado. Esta es la señal de mayor impacto en la lista, y es la primera que debes verificar.
2. Se debilitó una afirmación o se deshabilitó una prueba. Un skip, un only, una afirmación ampliada para aceptar lo que el nuevo código devuelve, un try/catch que traga el error que la prueba debía exponer.
3. La diferencia es más grande que la tarea. Se tocaron archivos que nadie pidió. La expansión del alcance en un agente no es entusiasmo, es una señal de que el agente reinterpretó el objetivo en algún momento.
4. Una superficie inventada. Un método de API, una opción de configuración o una ruta que no existe. Se compila en la cabeza del agente y en ningún otro lugar.
5. El entorno fue arreglado en lugar del código. Una ruta absoluta codificada, un valor específico de máquina, un token personal, un nombre de usuario. El síntoma desapareció en la máquina del agente y se trasladó a la de los demás.
6. Apareció una dependencia sin ser solicitada. Nueva cadena de suministro, nueva licencia, nueva superficie de mantenimiento, decidida por algo que no la mantendrá.
7. Duplicación en lugar de reutilización. Reimplementó un ayudante que ya existía veinte líneas más arriba. Este es el mecanismo detrás de la deuda medida: cada cambio parece razonable localmente y la base de código gana silenciosamente una tercera forma de hacer lo mismo.
8. El resumen no coincide con la diferencia. "Arreglado y probado" cuando no se ejecutó ninguna prueba. La narración se genera con la misma confianza, ya sea que el trabajo haya sucedido o no, así que trátala como una afirmación a verificar, nunca como un informe.
9. Las instrucciones dejaron de seguirse. Pequeñas convenciones silenciosamente abandonadas son cómo una sesión se degrada antes de que comience a alucinar abiertamente. Si usas un canario en tu archivo de contexto, esto es exactamente lo que está allí para atrapar.
10. Se tocó terreno sensible de pasada. Una lectura de .env, una nueva llamada de red saliente, una nueva línea de registro que lleva datos de usuario, una migración agrupada en un commit de función.

Nota lo que no está en la lista: estilo, nombres, formato, "yo lo habría hecho diferente". Esas siempre fueron la parte más débil de la revisión humana y ahora son genuinamente una pérdida de un humano. Elimínalas de tu revisión y recuperarás la atención que necesitas para los diez elementos anteriores.

¿Cuánta revisión merece un cambio?

El radio de explosión, no el tamaño de la diferencia, decide. La tabla que tu equipo puede adoptar esta tarde:

El tamaño de la diferencia te dice cuánto tiempo toma la revisión. El radio de explosión te dice si es opcional.

Las filas no se tratan de niveles de confianza. Se tratan del costo de estar equivocado, que es una propiedad del código y no de quién lo escribió. Eso es lo que hace que la tabla sea utilizable: nadie tiene que estar de acuerdo en cuán buenos son los agentes para estar de acuerdo en la tabla. Si tu equipo está estancado en la cuestión filosófica, salta eso y negocia las filas en su lugar. Te sorprenderá lo rápido que converge.

Si tu producto maneja datos personales en Europa, se escribe una fila más para ti por ley en lugar de por gusto: lo que una función construida por IA tiene que respetar bajo el GDPR no es una decisión de juicio, y "un agente lo escribió" nunca ha sido una defensa.

Qué cambia cuando cinco agentes funcionan a la vez

Todo lo anterior asume que puedes ver el cambio. Con agentes paralelos, esa suposición se rompe primero, y se rompe de una manera específica: la diferencia deja de tener un solo autor. Tres agentes han tocado el árbol de trabajo desde tu último commit, y la pregunta "¿quién cambió este archivo, y como parte de qué tarea?" ya no tiene una respuesta obvia. Revisar sin atribución no es revisión, es arqueología.

Ese es un problema de herramientas, y es la razón por la que AgentsRoom coloca la revisión donde están los agentes en lugar de al final de una solicitud de extracción:

• Review Mode muestra cada cambio que hicieron tus agentes, como una diferencia legible, antes de que se comita algo. Es el paso de "lee la diferencia en proporción al radio de explosión", hecho lo suficientemente barato como para que la gente realmente lo haga.
• Revisión por agente filtra esa diferencia por agente y te permite comitar el trabajo de cada agente por separado. Cinco agentes paralelos se convierten en cinco unidades revisables en lugar de un árbol de trabajo ilegible, y un cambio malo permanece atribuible a la tarea que lo produjo.
• El mensaje de commit se genera a partir de la diferencia real con el botón de brillo en el campo de commit, así que la historia describe lo que cambió en lugar de lo que el agente dijo que estaba haciendo. Esa distinción importa a las 3 a.m., seis meses después.

Nada de esto reemplaza el juicio. Elimina las excusas para no ejercerlo.

Haz que la máquina sea dueña de las líneas

Si quieres dejar de leer líneas, algo más tiene que leerlas. En la práctica, cuatro cosas llevan esa carga:

Pruebas que el agente no escribió en el mismo aliento que el código. Escritas primero, o escritas por un agente diferente, o al mínimo revisadas como su propio cambio. En el momento en que el código y sus pruebas provienen de la misma generación, dejan de ser evidencia independiente.

Un revisor con un modelo diferente. Esta es la respuesta práctica al problema de fallo correlacionado. Si un segundo agente revisa, ejecútalo en un proveedor o familia de modelos diferente al del autor. No podrás decorrelacionar los errores por completo, pero un revisor de la familia Codex en código escrito por Claude captura una clase de problema mediblemente diferente que un revisor del mismo modelo, precisamente porque no comparte los antecedentes del autor.

Puertas que no se cansan. Tipos, lint, escaneo de secretos, pisos de cobertura, un CI que rechaza una migración agrupada con una función. Cada regla que puedas expresar como una puerta es una regla que nunca tendrás que notar de nuevo.

Un bucle que se cierra sobre sí mismo. Un agente que construye, ejecuta su propio trabajo contra el plan e itera antes de entregar cualquier cosa elimina toda la categoría de "ni siquiera se ejecutó" de tu revisión. Ese es el bucle de agente autocorrector, y es la diferencia entre un agente que produce una diferencia y uno que produce un resultado. No responde a la pregunta de si un humano debería firmar. Solo significa que el humano está firmando algo que ya funciona.

Entonces, ¿sigues revisando?

Sí, y menos de lo que haces hoy.

Deja de leer líneas para sentirte responsable. Lee el plan antes, porque ahí es donde se cometen los errores costosos. Lee la diferencia después en proporción a lo que puede romper, usando la escalera en lugar de tu estado de ánimo. Mantén a un humano, personalmente, en autenticación, pagos, permisos, datos personales y cualquier cosa irreversible, porque un modelo no puede asumir responsabilidad y un segundo agente comparte los puntos ciegos del primero. Da todo lo demás a pruebas, tipos, puertas y un revisor que no comparta el modelo del autor.

Los equipos que se equivocan en esto fallan en una de dos direcciones, y ambas son evitables. Uno revisa todo, se convierte en el cuello de botella y comienza a aprobar sin leer, que es lo peor de ambos mundos. El otro no revisa nada, envía rápido durante dos meses y luego pasa un trimestre pagando la deuda que nunca vio acumularse.

El debate en tu reunión diaria no se trata realmente de si los agentes son buenos. Se trata de quién está dispuesto a firmar. Responde eso, y la política de revisión se escribe sola.

Preguntas frecuentes

¿Deberías seguir revisando el código generado por IA?

Sí, pero no línea por línea en todo. Revisa el plan antes de que el agente comience, luego revisa la diferencia en proporción a lo que el cambio puede romper. Los textos y el CSS reciben un vistazo. La autenticación, los pagos, los permisos, los datos personales y las migraciones se leen línea por línea por un humano, cada vez.

¿Puede un agente de IA revisar el código de otro agente de IA?

Ayuda, pero no es un sustituto de un humano en código arriesgado. Dos agentes de la misma familia de modelos, dados el mismo contexto, tienden a fallar en la misma dirección. Sus errores están correlacionados, así que un segundo agente captura errores tipográficos y pruebas faltantes pero comparte los puntos ciegos que produjeron el error. Si usas un revisor agente, ejecútalo en un modelo diferente al del autor.

¿Cómo sabes si un agente de IA cometió un error?

Busca señales objetivas en la diferencia en lugar de leer por estilo. La más fuerte: las pruebas cambiaron en el mismo commit que el código que cubren, lo que significa que el verde fue construido y no observado. Otras incluyen expansión del alcance, una afirmación deshabilitada o debilitada, una API inventada, una ruta local codificada y un resumen que no coincide con la diferencia.

¿Los agentes de IA reemplazarán a los revisores de código humanos?

Ya reemplazaron la mayor parte de la lectura de líneas. No pueden reemplazar la firma. La responsabilidad no se transfiere a un modelo, así que un humano aún posee la decisión de fusionar cualquier cosa que sea difícil de revertir.

¿Necesitas revisar el código de IA línea por línea?

Solo donde el radio de explosión lo justifique. La revisión línea por línea no escala más allá de unos pocos agentes funcionando en paralelo, y un humano hojeando una diferencia de 900 líneas a las 6 p.m. produce una firma sin producir conocimiento. Dedica esa atención a los cambios que son costosos de deshacer.

¿Qué nunca debería fusionarse sin revisión humana?

Cualquier cosa que toque autenticación, pagos, permisos, datos personales, migraciones de bases de datos, rutas de eliminación e infraestructura. Estas comparten una propiedad: el costo de estar equivocado no es proporcional al tamaño de la diferencia.