Los Agentes de IA Están Matando la Revisión de Código — El Problema Principal-Agente Explicado

El proceso estándar de revisión de código en la industria —revisar y luego confirmar, popularizado por los PRs de GitHub— fue diseñado para la colaboración de baja confianza. Un humano hace un cambio, otro humano lo revisa, ocurren iteraciones y el cambio se implementa. Esto funcionaba porque los revisores podían deducir fácilmente el esfuerzo y la comprensión al leer el código. Los agentes de IA rompen eso por completo.

El desastre del agente intermediario

El mejor caso con agentes de IA: un humano le indica a una máquina que escriba código, el humano lo revisa y luego lo envía a un segundo humano para una revisión tradicional. Eso duplica la carga de revisión. Peor aún, los agentes aumentan el volumen total de cambios. El resultado: el ancho de banda de revisión se agota antes de que se materialice siquiera una fracción de las ganancias de productividad de los agentes.

Pero la realidad es peor. El patrón real es: un humano escribe un prompt corto, hace una QA ligera de la salida, lo empaqueta como un PR y luego canaliza los comentarios del revisor de vuelta al agente para correcciones. Esto es un claro problema principal-agente: el revisor (principal) ya no puede inferir el esfuerzo o la comprensión a partir del código, porque el código fue generado por una máquina. El humano que maneja el agente no tiene incentivos para leer realmente el código o pensar críticamente en los comentarios del revisor. Dedican 5 minutos y generan una carga de revisión significativa para otro ingeniero.

Esto es lo que está matando el código abierto: los "slop PRs" de personas que no tienen comprensión del proyecto, sus restricciones o sus herramientas.

Un camino a seguir para equipos pequeños

Para equipos pequeños de alta confianza, existe un proceso más simple: humano indica al agente → humano revisa el código → humano despliega directamente (sin un segundo revisor). El humano que maneja la máquina asume toda la responsabilidad al ser propietario del despliegue. El problema principal-agente desaparece porque el humano es tanto el conductor como el desplegador.

En exe.dev, un equipo de nueve personas utiliza este enfoque con éxito. Prácticas clave: escribir muchas más pruebas de integración y e2e, construir flujos de trabajo basados en agentes para analizar confirmaciones en busca de errores de seguridad, rendimiento y usabilidad, y asegurar que siempre haya un humano responsable del despliegue final.

El modelo tradicional de revisión de código no es recuperable con agentes. Los equipos pequeños pueden adaptarse; las grandes organizaciones y los proyectos de código abierto enfrentan un problema estructural más difícil.