Según un estudio del MIT, los devs que usan agentes generan 180% más código, sin embargo, la cantidad de código que llevan a producción sólo aumentó un 30%, ¿por qué?
En la actualidad, el debate central en la industria del software es ¿qué hacer con la revisión de código?
Hay 3 escenarios posibles, que ya están sucediendo en la industria.
Escenario 1: El clásico, un desarrollador revisa el código.
Según un estudio de Cisco, una sesión de revisión de código se degrada después de 400 líneas de código, pasada esa referencia, la sesión se vuelve menos efectiva. Si los agentes pueden generar miles de líneas de código, el proceso de revisión se vuelve ineficiente.
El problema, es que exactitud no es igual que calidad, un agente puede generar código que pase el 100% de pruebas, y sin embargo, no tenga la calidad requerida para integrarse.
Una forma de medir esto es el benchmark desarrollado por Cognition: FrontierCode. A diferencia de otros benchmarks, este evalúa si el código generado por un agente sería integrado o no, según el criterio de 20 ingenieros con experiencia manteniendo grandes proyectos open source. El resultado es que los modelos frontera aprueban alrededor del 50% de los casos, si comparamos los resultados de estos modelos en benchmarks que miden exactitud como SWEBench podemos observar diferencia de hasta 30 puntos porcentuales por debajo.
Esto deja entrever que, en muchos escenarios, la revisión de código es necesaria para validar que el código generado por un agente es de calidad.
Escenario 2: El humano revisando al revisor.
En marzo de 2026, GitHub reportó que GitHub Copilot ha realizado 60 millones de revisiones de código, esto es 1 de cada 5 revisiones de código en la plataforma son realizadas por su agente.
Además de GitHub, CodeRabbit, Cursor, son otros ejemplos de agentes que realizan revisiones de código cada día.
Colocar un agente frente a otro es parte de un proceso moderno conocido como Loop Engineering. En este proceso, el ingeniero de software se encarga de diseñar el ciclo, uno en el que los agentes pueden comunicarse entre sí para retroalimentarse y mejorar la calidad del código.
Aunque los agentes revisores de código han mejorado mucho, medir calidad es una tarea subjetiva y de gusto, no hay una referencia numérica que permita a los agentes usar para repetir una tarea hasta que sea correcta.
Esto significa que muchos equipos deciden revisar el trabajo que resulta del loop, moviendo el trabajo humano una capa más arriba de la revisión de código. El ingeniero de software sigue dando la confirmación final, pero antes de esta, ya hubo una iteración que, en teoría, debería resultar en un entregable de mayor calidad.
El trabajo de los equipos de ingeniería en este escenario es el de diseñar el harness, los guardrails que permitan a los agentes realizar su trabajo de manera correcta.
Escenario 3: Automatización total.
Patrones como el Ralph Loop, /goals o el loop engineering son ejemplos de como los equipos de ingeniería están diseñando el harness para permitir a los agentes realizar su trabajo de manera automatizada.
Un ejemplo de este escenario es el experimento que realizó Anthropic en febrero de 2026. 16 agentes fueron ejecutados en paralelo para desarrollar un compilador de C que “puede construir Linux 6.9 en x86, ARM, and RISC-V”, uno de los puntos clave del experimento es que, si bien la ejecución fue automatizada, el trabajo humano fue necesario para diseñar el harness, todo el trabajo de preparación antes de dejar que los agentes trabajen fue realizado por profesionales. Otros puntos a considerar del experimento es que para resolver el problema, los agentes usaron un compilador escrito por humanos (gcc) para probar su solución.
Este escenario es el más ambicioso, pero requiere un expertise de equipos de ingeniería en tópicos asociados al rol de Ingeniero de IA, diseñar el harness, establecer los guardrails, criterios de éxito, suite de pruebas, etc.
En este punto, la revisión de código se elimina completamente y la calidad está respaldada por la precisión del harness implementado.
Conclusión.
La respuesta histórica a cualquier pregunta sobre buenas prácticas y toma de decisiones sigue siendo “depende”.
A lo largo de la evolución de la industria del software, nuevas tecnologías y nuevos patrones han surgido para responder a las distintas necesidades que enfrenta cada equipo.
Como en cada una de las anteriores, el contexto de cada equipo es clave para tomar la decisión correcta, y no anticipo que exista una decisión definitiva y correcta que pueda aplicarse para cada escenario posible.
El compilador de C funciona como ejemplo precisamente porque es un dominio con una referencia verificable, un compilador escrito por humanos, no todos los problemas de software tienen una referencia verificable con esa precisión, por lo tanto, en muchos casos, la revisión de código es necesaria para validar que el código generado cumpla, no sólo con la calidad, si no que haga lo que se espera de él.
En ese sentido, lo importante es que todos los equipos de ingeniería se estén capacitando para entender los distintos escenarios y tomar la decisión correcta para su equipo. Deben establecerse discusiones sobre la integración de agentes de IA que vayan más allá de entregar licencias de uso a los desarrolladores.
Los equipos de ingeniería que únicamente centran sus esfuerzos en la generación de código, sin considerar otras partes del ciclo de desarrollo, están creando presión en el flujo de trabajo, incrementando el output de de código, sin tener un plan de trabajo para ese incremento de código.