Faros: en los equipos con agentes de IA, el tiempo mediano de revisión de código ha subido un 441%

La telemetría de Faros sobre 22 000 desarrolladores muestra que, en los equipos con alta adopción de IA, el tiempo mediano de revisión de código aumentó un 441%, y los pull requests sin ningún tipo de revisión se fusionan un 31% más a menudo. El tiempo que ahorran los agentes lo dedican las propias personas a nuevas tareas y a revisar código ajeno. En septiembre, un autor de Habr escribió a conocidos que unos dos meses antes habían empezado a trabajar con agentes de IA y les preguntó qué tal les iba.

Esperaba historias de aceleración, y las hubo: unos dejaron de analizar logs a mano, otros empezaron a asumir tareas de frontend, backend y DevOps. Pero con más frecuencia respondían otra cosa: el volumen de revisiones ha crecido mucho, por su cabeza pasa mucha más información y al final del día no les quedan fuerzas para su propio proyecto. De ahí la pregunta: ¿es un bache temporal o la nueva normalidad?

Los desarrolladores gastan por su cuenta el tiempo ahorrado

Investigadores de Berkeley Haas observaron durante ocho meses a una empresa tecnológica estadounidense de unas 200 personas (los resultados los publicó HBR). Con IA generativa, los empleados trabajan más rápido, asumen tareas más amplias y terminan más tarde, aunque nadie se lo exige. Los prompts se lanzan durante la comida, en mitad de las videollamadas y mientras carga un archivo. Con el tiempo, el aumento inicial de productividad da paso a una caída de la calidad y a la rotación de personal.

Los datos de Faros concuerdan con esta observación: la gente simplemente deja de llegar a revisar el flujo de cambios. El estudio de BCG precisa la causa del cansancio. Cuando la IA se lleva la rutina, el agotamiento disminuye. Cuando el trabajo se convierte en una supervisión constante del agente, aumentan la fatiga de decisión y las ganas de dejar el empleo. Hay que escribir menos código, pero más planteamiento de tareas, revisión y toma de decisiones, y la mayoría de los desarrolladores no se ha formado específicamente en esa habilidad.

Primero será peor: la curva de aprendizaje y las sensaciones engañosas

El estudio más citado sobre la ralentización es el de METR de julio (el laboratorio mide el efecto real de la IA en el trabajo). 16 desarrolladores open-source con experiencia resolvieron tareas en sus propios repositorios y, con IA, tardaron un 19% más. Antes del experimento esperaban una aceleración del 24% y, después, seguían creyendo que habían ido un 20% más rápido. Los participantes usaron Cursor solo unas decenas de horas, y los autores escriben explícitamente que no se puede descartar un efecto de aprendizaje pasadas las 50 horas.

Una segunda medición, seis meses después, dio en los diez participantes que volvieron una aceleración de en torno al 18%. El intervalo de confianza incluye el cero y los propios autores calificaron la señal de poco fiable: muchos se negaron a trabajar sin IA y la muestra quedó sesgada. En la encuesta de METR, la gente estima el beneficio aproximadamente en el doble, y según mediciones anteriores sobrestima el efecto en promedio 40 puntos porcentuales.

Conclusión del autor: sin habilidad y sin un proyecto preparado, la IA sí puede ralentizar, y las sensaciones engañan. Quien abandona en el fondo del bache concluye que «la IA no funciona». Quien lo atraviesa dice: «ya no puedo trabajar sin esto». El peligro está en el punto medio: la persona ve en su feed a diez agentes que cerraron el backlog en una noche, instala otro framework y cinco MCP, lanza agentes en paralelo y entra en un estado de ansiedad constante.

Confianza es verificabilidad: el orden de adopción

La encuesta de Stack Overflow 2026 marca el límite: en decisiones importantes confía en la IA el 6% de los desarrolladores, pero casi la mitad confía si puede verificar el resultado. Sin una comprobación automática rápida quedan dos extremos agotadores: leer cada línea o aceptar un «listo» sin más y lidiar con las consecuencias una semana después. Una postura razonable es la de un tech lead: controlar el «tronco y las ramas» (arquitectura, facturación, modelo de datos, tests críticos) y no tocar cada hoja.

En una encuesta en el canal de Telegram del autor, solo 2 de 32 encuestados señalaron la elección de herramienta como el problema principal, y 19, la sistematización del conocimiento. El orden al que llegó es este:

• base de ingeniería: sin ella no se distingue un cambio que funciona de uno verosímil;
• planteamiento de la tarea con criterios de aceptación antes de escribir código;
• feedback loop: tipos, linter, tests, navegador, logs, para que el agente se verifique a sí mismo;
• extensiones (skills, MCP, plugins) solo después de lo anterior;
• conocimiento del proyecto, plan para las tareas grandes y revisión según los requisitos;
• agentes en paralelo, al final de todo.

Saltarse una etapa sale más caro después. Un error típico es lanzarse directamente a Spec-Driven Development, orquestadores y cinco agentes. Los novatos acaban con specs de 3–5 veces más volumen que el código, que nadie lee, con los límites de uso agotados y con la sensación de una caja negra. Instalar extensiones a ciegas supone además un riesgo para la cadena de suministro: en febrero de 2026, Koi Security encontró 341 skills maliciosos de 2 857 en el marketplace ClawHub.

La forma de aprender también importa. En el experimento de Anthropic, los júniores que dominaban una biblioteca nueva con IA obtuvieron un 50% en el test frente al 67% de quienes no la usaron. Pero quienes hacían preguntas conceptuales al agente y resolvían los errores por sí mismos obtuvieron un 65% o más.

Conclusión del autor: el bache pasará, pero el volumen de trabajo de revisión no; es la nueva normalidad. Se puede reducir la carga si se delegan las comprobaciones rutinarias en herramientas y en un segundo agente con contexto limpio, si uno se queda solo con lo crítico y si no mantiene abiertos más agentes de los que le da tiempo a revisar. El autor presentará su charla sobre este tema en la conferencia online AI Dev Live el 12 de noviembre.