Revisión de código agéntica

• Con la mejora drástica del rendimiento de los agentes de programación, el punto difícil de la ingeniería se desplazó de escribir código a decidir si ese código es confiable, y la revisión se volvió la tarea con mayor apalancamiento
• La IA aumenta enormemente la producción, pero reduce la calidad y la posibilidad de revisar, y se ha medido una brecha donde frente a 4 veces más código, el valor real solo aumenta alrededor de 10%
• La intensidad de revisión necesaria cambia según el blast radius (alcance del impacto) del cambio, y un desarrollador en solitario y un equipo que mantiene un sistema grande de 10 años tienen restricciones completamente distintas
• Los agentes razonan, pero ese razonamiento no se adjunta al PR y se descarta, lo que obliga al revisor a reconstruir desde cero la intención que desapareció
• Escribir se abarató, pero entender sigue siendo caro, así que los equipos que construyan sistemas de revisión confiables tendrán ventaja en adelante

---

Lo que realmente muestran los datos de 2026

• Lo que durante años fueron anécdotas y debates ahora fue medido a gran escala por organizaciones con intereses distintos —algunas incluso compiten entre sí—, y todas llegaron a la misma conclusión: la IA dispara la producción, pero reduce la calidad y la capacidad de revisión

• Medición de Faros AI (datos de marzo de 2026)

  • Seguimiento de la transición de baja adopción de IA a alta adopción de IA en 4,000 equipos y 22,000 desarrolladores
  • Lado positivo: los desarrolladores fusionan más PR y completan más trabajo, con mayor rendimiento por ingeniero
  • Cifras del lado negativo
    • El churn de código aumentó 861%
    • La proporción de incidentes por PR aumentó 242.7%
    • La tasa de defectos por desarrollador pasó de 9% → 54%
    • El tiempo mediano de revisión aumentó 441.5% (tanto el tiempo hasta la primera revisión como el tiempo promedio de revisión casi se duplicaron)
    • Los PR fusionados sin revisión aumentaron 31.3%
  • Las fusiones sin revisión no fueron una elección consciente de nadie, sino el resultado de que los revisores ya no pueden seguir el volumen y fusionar código que nadie leyó se vuelve algo cotidiano
  • Incluso los equipos con prácticas de ingeniería maduras y disciplinadas reciben el mismo golpe; los buenos procesos no protegen (el volumen llega más rápido de lo que se puede diseñar el proceso)

• Investigación de CodeRabbit (diciembre de 2025)

  • Análisis de 470 PR de código abierto (320 coescritos con IA, 150 solo humanos), donde los cambios con IA trajeron cerca de 1.7 veces más issues
    • Problemas de lógica y corrección: alrededor de 75% más
    • Issues de seguridad: entre 1.5 y 2 veces más
    • Problemas de legibilidad: más de 3 veces más
  • El director de IA, David Loker: "Es una debilidad predecible y medible que las organizaciones deben mitigar activamente" — como es una debilidad conocida y localizable, se puede apuntar el proceso de revisión directamente hacia ella

• Datos de productividad de GitClear (hasta 2025)

  • Los usuarios que usan IA todos los días tienen cerca de 4 veces la producción bruta frente a quienes no la usan, pero la mejora real de productividad frente a sí mismos un año antes es de apenas 12%
  • La estructura implica que los humanos deben revisar 4 veces más código
  • Bill Harding aclara que incluso ese 12% puede explicarse en parte por sesgo de selección (los desarrolladores fuertes se concentran en el grupo que usa IA)

• Reporte de GitHub

  • Copilot review ya se ejecutó más de 60 millones de veces, con un aumento de 10x en un año, y más de 1 de cada 5 revisiones en la plataforma ya involucra un agente
  • Ya no es una práctica de nicho, sino la forma misma en que se produce el código
• Cuatro datasets y cuatro metodologías convergen en una sola conclusión: el cuello de botella no desapareció, sino que se movió a la etapa de verificación

Todos están resolviendo problemas distintos

• La mayoría de estos datos de advertencia provienen de telemetría empresarial y de maintainers de open source desbordados; mucho de eso no aplica a un desarrollador individual que crea algo que usan muy pocas personas

• Tres variables que determinan tu posición

  • blast radius: qué pasa si se rompe — nada, o usuarios furiosos, dinero y exposición de PII
  • Vida útil del código: si es un prototipo desechable que se volverá a escribir la próxima semana o una base de código que se mantendrá durante años
  • Cuántas personas tienen que entenderlo: si solo tú lo llevas completo en la cabeza o si es un equipo que comparte ownership a lo largo del tiempo

• Solo, greenfield, sin usuarios

  • No existe el segundo rol de la revisión, que es distribuir conocimiento dentro del equipo (porque tú eres el equipo)
  • La decisión razonable: depender fuertemente de tests y automatización, revisar solo lo realmente importante y dar un toque ligero al resto
  • Pero eso solo funciona si los tests son reales; saltarte la revisión sin red de seguridad no hace que el trabajo desaparezca, solo lo difiere a un costo mayor
  • "Sin usuarios" es permiso para diferir la revisión, no para saltarse la verificación

• El punto medio peligroso

  • En el momento en que el proyecto empieza a tener usuarios, el rol de detectar bugs se vuelve importante de golpe (porque los bugs afectan personas) y también se activa el rol de compartir conocimiento
  • Si el equipo mantiene durante unos meses más los hábitos de cuando trabajaba en solitario y luego llega un postmortem, las cifras de Faros se convierten en su propio dashboard

• Organizaciones grandes, bases de código viejas, muchos usuarios

  • Todas las cifras de advertencia aplican con máxima intensidad; un cambio que nadie entiende se convierte en comprehension debt (deuda de comprensión) y termina transformándose en el incidente on-call de alguien
  • La clave no es que "las empresas deban ser cuidadosas y los solitarios puedan relajarse", sino que el propósito de la revisión cambia según la posición, así que las reglas también deben cambiar
  • Si le pones a un prototipo de dos personas un pipeline empresarial con múltiples agentes y exigencia de evidencia, generas fricción inútil; si aplicas "pasaron los tests, entonces despliega" a un sistema de pagos, creas un generador de incidentes con checks verdes

Lo que realmente hace hoy la revisión

• Cuando una persona escribe código, la intención viene gratis con él, y las alternativas sopesadas y descartadas siguen en la cabeza del autor, así que revisar era inspeccionar ese razonamiento
• Los agentes modernos también razonan y muchas veces muestran visiblemente su thinking trace, pero ese razonamiento se descarta en el momento en que se crea el diff y no se adjunta al PR
• Además, ese es el razonamiento del agente sobre "cómo implementarlo", no el juicio humano sobre "si esto era la tarea correcta desde el principio"
• Como resultado, la revisión deja de ser inspección del razonamiento visible y pasa a ser reconstrucción de una intención no registrada, lo que la vuelve más difícil y más lenta (de ahí el 441% más de tiempo)

• AI Slop and the Software Commons (paper de 2026)

  • Análisis de 1,154 publicaciones de 15 hilos en Reddit y Hacker News
  • En palabras de un desarrollador: revisar PR de agentes lo convierte en "el primer humano que ve este código"
  • Según el paper, la revisión "no fue diseñada para recuperar una intención desaparecida"

• La solución es un problema de herramientas

  • La intención perdida se puede recuperar —el razonamiento existió, solo fue descartado
  • Si se hace que el agente declare qué intentó hacer y qué descartó, y eso se captura como decision log (registro de decisiones) del PR, desaparece una buena parte del costo de reconstrucción
• El enfoque de "IA revisando IA" por sí solo no es una respuesta completa; un segundo modelo con conocimiento previo distinto detecta muchos bugs reales, pero no puede aportar el juicio humano de "¿vale la pena construir este cambio?"

Las herramientas son buenas, pero no por la razón que anuncian

• Las herramientas dedicadas de revisión con IA ya son lo bastante buenas, y se recomienda al menos ejecutar el agente principal de programación —y si es posible, un agente dedicado a revisión— en todo, incluso en side projects

• Características por herramienta principal

  • CodeRabbit: la más desplegada, primer lugar en F1 en el benchmark independiente Martian (enero-febrero de 2026), con precisión de alrededor de 49% y el mejor recall de la industria
  • Greptile: sacrifica precisión para ganar recall; en un benchmark logró cerca de 82% de detección de bugs (frente a 44% de CodeRabbit), aunque con más falsos positivos
  • Anthropic Code Review: menos de 1% de los resultados marcados como error por sus propios ingenieros, y elevó la proporción de PR que reciben revisión efectiva de 16% a 54%

• Experimento de 4 revisores en paralelo (resultado fuera de los vendors)

  • Un ingeniero aplicó en paralelo CodeRabbit, Sentry Seer, Greptile y Cursor BugBot durante tres semanas y media a 146 PR reales, con 679 hallazgos
  • De 617 ubicaciones únicas marcadas, 93.4% fueron detectadas por exactamente una sola herramienta; 6% por dos, casi ninguna por tres y ninguna por las cuatro
  • Nunca hubo una sola línea marcada por las cuatro herramientas al mismo tiempo
  • Cada herramienta tiene fortalezas distintas: Greptile casi no tiene falsos positivos en corrección y arquitectura, CodeRabbit lanza la red más amplia y ofrece fix con un clic, Seer destaca en severidad de fallas operativas
  • La heterogeneidad es la clave: cuatro copias del mismo modelo solo agrandan la factura y siguen siendo un solo revisor; cuatro revisores realmente distintos revelan bugs que ninguno detectaría por sí solo

• Guía práctica

  • No te obsesiones con encontrar una sola mejor herramienta (no existe)
  • En áreas de alto riesgo, usa deliberadamente dos herramientas de naturaleza distinta en paralelo (en el experimento anterior, Greptile para la corrección diaria y Seer para la severidad operativa)
  • Si trabajas solo, un buen revisor y tests reales bastan
  • Sin importar el marketing, mide siempre en tu propio código; todos los resultados están limitados a una base de código específica

¿Hay que dejarle más revisión a la IA?

• Hace un año esta habría sido una pregunta herética, pero hoy la plantean ingenieros con mucha experiencia: ¿debería la máquina encargarse de una parte mayor, quizá de la mayor parte, de la revisión?

• La verdad incómoda de que la revisión con IA sí funciona

  • Menos de 1% de los hallazgos de Anthropic se marcaron como error, la IA detecta bugs que los humanos pasaron por alto y no se cansa ni en el PR número 30 del día (justo cuando la confiabilidad humana es más baja)
  • En cambio, los humanos no pueden seguir el ritmo: 31% más fusiones sin revisión, y tiempos de revisión que crecieron en tres dígitos
  • El framing honesto no es "¿deberíamos dejarle más a la IA?", sino "la IA ya lo está haciendo, y la cuestión es si vamos a hacerlo de forma deliberada o vamos a fingir que los humanos leen todo mientras lo dejamos abandonado"

• La visión de loop engineering

  • La premisa del loop es dejar atrás al humano que le escribe prompts al agente y pasar a construir sistemas que le escriben prompts al agente, con un agente judge en el centro que decide si el trabajo quedó terminado o no
  • El revisor se convierte en el siguiente rol eliminado deliberadamente del loop interno por diseño; un año después de automatizar la escritura, también se automatiza la verificación y el humano es empujado hacia arriba

• El riesgo del loop cerrado

  • Si un agente escribe, otro revisa y un tercero juzga, se forma un loop cerrado de modelos con correlated blind spots (puntos ciegos correlacionados), especialmente si pertenecen a la misma familia y coinciden con seguridad en los mismos errores
  • Un "looks good" seguro de sí mismo sin humanos de por medio es borrowed confidence (confianza prestada): la confianza del sistema pasa a ser mi confianza, aunque en realidad nadie entendió nada

• El humano no desaparece, sube un nivel

  • En vez de leer cada diff, pasa a hacerse cargo de lo que no se puede transferir al modelo, y la responsabilidad importa
  • Áreas que debe resguardar la persona: decidir si este es el cambio correcto para construir, poner gates caros cuando el blast radius es alto, y vigilar comportamientos que nadie especificó (los modelos revisan el código que existe y casi nunca marcan requisitos que nadie escribió)
  • De human in the loop a human on the loop: en lugar de leer cada PR, se muestrea, se hace spot-check, se audita el sistema y se concentra la atención limitada donde equivocarse realmente duele

• Caso de Kun Chen (ex ingeniero L8 de Meta, builder solitario)

  • Entrega alrededor de 40 PR al día y prácticamente dejó de hacer code review, ejecutando entre 20 y 30 agentes en paralelo
  • Movió el esfuerzo al plan: redacta un plan detallado por adelantado y luego deja a los agentes correr durante horas; la calidad del plan determina cuánto tiempo pueden operar sin supervisión
  • No dejó de verificar, sino que escribió su intención de antemano y así resolvió a la mitad el problema del "primer humano que ve este código" (la persona entiende el porqué antes, no después)
  • No trabaja sin red de seguridad: un gate automático de revisión al que llama No Mistakes inspecciona el código antes del merge, y cuando los agentes se bloquean, esperan escalamiento
  • Pero sigue siendo un builder solitario, sin un equipo grande ni un sistema viejo lleno de minas, y sus condiciones no aplican a la mayoría de los lectores; si eso se copia en un equipo con muchos usuarios, las cifras de Faros aparecerán en su dashboard
• Conclusión a lo largo del espectro: para alguien solo y sin usuarios, dejarle casi todo a la IA es una postura defendible en 2026; para organizaciones grandes y con muchos usuarios, la primera y segunda pasada y el 90% aburrido pueden ser para máquinas, pero los caminos que sostienen carga real deben seguir teniendo humanos, y la cantidad de supervisión humana no se define por culpa, sino por blast radius

Qué hacer en la práctica

• Principio organizacional: alinear el esfuerzo de revisión con el costo de estar equivocados, adelantar todo lo barato y determinista que se pueda, y reservar la atención humana para lo que solo un humano puede hacer

• Clasificar por riesgo, no por autor (Tier by risk, not by author)

  • Un cambio de configuración puede pasar con un linter y una sola revisión rápida
  • Corregir una ruta de lógica central del negocio requiere el stack completo: tipos, tests, dos revisores de IA distintos, la persona dueña de ese sistema y una pasada de seguridad
  • No gastes revisión pesada en boilerplate, pero tampoco dejes pasar cambios grandes solo porque los tests están en verde

• Cortar rápido la cola cara (Fast-fail the expensive tail)

  • Early-Stage Prediction of Review Effort (enero de 2026), estudio sobre 33,707 PR escritos por agentes
  • Los agentes son fuertes en cambios pequeños y bien definidos, por eso alrededor de 28% se fusionan casi de inmediato, pero en cuanto reciben feedback subjetivo tienden a hacer "ghosting" y abandonan el ida y vuelta que está en el corazón de la revisión
  • En un paper complementario de 2026, el abandono del revisor representa 38% de los PR de agentes rechazados
  • Los investigadores construyeron un "circuit breaker" que predice PR de alto costo de mantenimiento antes de que los vea un humano usando señales baratas como tipo de archivo y tamaño del parche, y funcionó bien

• Elevar el estándar de lo que merece revisión

  • La solución no es cerrar el repositorio, sino rechazar revisión a cambios que llegan sin evidencia
  • Exigir antes de revisar: una declaración del propósito del cambio, un diff en lugar de 3,500 líneas sin comentarios, salida de tests, evidencia de que realmente se ejecutó
  • En vez de absorber tú el costo de reconstruir intención, devuelve esa carga a quien envía el cambio, que puede resolverla más barato

• Mantener los PR deliberadamente pequeños

  • Los PR de agentes salen grandes (en los datos de Faros, en promedio 51% más grandes), y la participación del revisor es una de las variables que mejor predicen si un PR se fusionará o no
  • Un PR grande e imposible de revisar se rechaza de inmediato o, peor todavía, recibe rubber stamp
  • Indícale al agente que genere commits pequeños; un diff que una persona realmente pueda leer ya no es cortesía, sino una restricción de diseño

• Leer con más cuidado los cambios en tests que el código

  • Un modo de fallo típico de los agentes: cambian el comportamiento y luego "arreglan" los tests reescribiendo assertions para adaptarlas al nuevo comportamiento roto
  • Un check verde sobre 200 tests editados no significa nada hasta comprobar que las ediciones eran correctas; un diff que reescribe muchos tests debe tratarse como una señal de alerta y revisarse primero
  • El valor de mutation testing: la cobertura dice si una línea se ejecutó; las pruebas de mutación dicen si los tests detectarían que esa línea está mal

• Tratar el CI como un muro que no se mueve

  • Vigilar los patrones sobre los que GitHub advierte a los revisores: tests eliminados, lint omitido, umbrales de cobertura rebajados, helpers duplicados que ya existían, y entradas no confiables que llegan al prompt
  • Especial énfasis en lo último: las funciones creadas por agentes son una nueva fuente de prompt injection; si texto controlado por usuarios se pasa directo a una llamada a LLM, la vulnerabilidad no aparece en el diff sino que queda latente en datos que llegarán después
  • Los agentes debilitan CI sin mala intención para poder pasar (el descenso de gradiente encuentra la ruta más barata hacia el verde), y los gates deterministas son la única parte cuyo veredicto no puede revertirse con un párrafo seguro de sí mismo, así que deben mantenerse estrictos

• El merge lo posee una persona

  • Un modelo no puede recibir un page ni rendir cuentas, así que quien aprieta el botón de merge es quien se hace cargo
  • Cuando una revisión de IA dice "looks good" con voz tranquila y segura, lo que hace es transferir una confianza que no se ganó
  • Trata toda revisión de IA como un sensor, no como un veredicto — datos, no decisión

Lo que esto significa si diriges un equipo

• La restricción que limita la entrega ya no es qué tan rápido se puede escribir código, sino qué tan rápido una persona de confianza puede convencerse de que un cambio es correcto
• Cualquier planificación que vea la generación como cuello de botella y trate la revisión como si fuera gratis se va a estancar silenciosamente mientras mantiene el dashboard de velocidad en verde
• El reporte de Faros dice explícitamente que, aunque aumente la producción, también aumenta el trabajo de QA y revisión; reducir headcount de ingeniería diciendo "somos más rápidos gracias a la IA" antes de cerrar la brecha de revisión es peligroso
• El impuesto a los ingenieros senior de tiempos de revisión que crecieron en tres dígitos cae con más fuerza sobre las personas que menos pueden convertirse en cuello de botella, y no aparece en métricas que solo cuentan PR fusionados
• Los maintainers de open source chocan contra este muro antes y con más fuerza que nadie — un flujo constante de contribuciones plausibles pero vacías consume tiempo real de triage incluso cuando vienen con buena intención, y eso es el canario en la mina; la empresa será la siguiente
• Los equipos que responden bien no tratan la capacidad de revisión como una holgura que la IA les regaló, sino como un recurso real que hay que medir, proteger y consumir deliberadamente

Escribir se abarató, pero entender no

• No aceptes respuestas uniformes de extremos opuestos — para quien trabaja solo y no tiene usuarios, las historias de terror empresariales sobre churn y duplicación no son el incendio de hoy, sino un riesgo futuro; apóyate en tests y revisa solo lo importante, pero admite honestamente que el trabajo diferido sigue siendo deuda
• Si estás en una organización grande con muchos usuarios, todas las cifras de advertencia aquí hablan de ti, y lo único que sirve es clasificar por niveles, exigir evidencia, diseñar un proceso de revisión deliberadamente heterogéneo y hacer que una persona sea dueña del merge
• En todo el espectro hay algo que no cambia: la economía fundamental — escribir se volvió barato y entender sigue siendo tan caro como siempre
• Los equipos que lo harán mejor no serán los que generen más código, sino los que construyan un sistema de revisión realmente confiable, y los que nunca confundan "los tests pasaron" con "una persona entiende qué hace esto y por qué"
• Como dijo Simon Willison, la esencia del trabajo es entregar código cuyo funcionamiento se ha demostrado — los agentes no cambiaron eso, sino que hicieron de la demostración el centro del trabajo en vez de una tarea secundaria
• La capacidad de entender un sistema lo suficiente como para respaldarlo sigue siendo la habilidad más duradera e interesante del software, y este es un gran momento para volverse extremadamente bueno en eso