Si tu equipo ya trabaja con agentes de código, quizá te suene la queja: el día se va en revisar lo que escribe el agente. Anthropic acaba de ponerle cifras en su propia empresa, y la conclusión no es que el agente sea lento. Es que espera a una persona.
La idea que defiende este insight: el metatrabajo (preparar lo que se le pide al agente, revisar lo que devuelve y decidir qué entra) no es una distracción del trabajo de verdad. Es el trabajo. Un equipo que lo hace a ratos y sin método convierte el agente en una cola de cosas por revisar. Lo que reduce esa espera es decidir antes, no revisar más deprisa.
Lo que ha medido Anthropic en su propia empresa
El 16 de octubre de 2026, el equipo de economía de Anthropic (Wilmers, Catipon, Massenkoff y McCrory) publicó cómo ha cambiado el trabajo dentro de la compañía desde que sus empleados usan agentes. Tres cifras explican el problema:
El 80 % se calcula restando el tiempo activo del agente al tiempo total de cada sesión interactiva. Por metatrabajo entienden el trabajo que no es la tarea en sí: escribir especificaciones para que trabajen varios agentes, poner a un agente a revisar lo que hace otro, montar herramientas para ver qué pasa y vigilar los flujos. Y su conclusión, traducida: esta aceleración convierte la atención humana en el cuello de botella de lo que producen los agentes.
Riesgo Es una sola empresa, la que fabrica el modelo, estudiando su propio despliegue. El 80 % es tiempo de reloj de la sesión e incluye esperas cortas: no quiere decir que el agente esté parado el 80 % de la jornada. El metatrabajo se clasificó de forma automática sobre una muestra de 2.000 resúmenes de una línea. Las seis horas de agente por cada hora de persona no son productividad: los propios autores avisan de que más código no significa necesariamente mejor código ni más impacto en el negocio.
Por qué el agente espera
No es un dato aislado. En diciembre de 2025, otro estudio de Anthropic sobre sus ingenieros (Huang y otros; 132 encuestados y 53 entrevistas) ya apuntaba la causa. Los ingenieros delegaban sobre todo lo que se comprueba fácil: decían que Claude era muy útil donde el esfuerzo de validar no es grande comparado con el de crear. Y más de la mitad decía que podía delegar del todo solo entre el 0 % y el 20 % de su trabajo. Lo llamaban la «paradoja de la supervisión»: para supervisar al agente hacen falta precisamente las habilidades que se pueden perder por usarlo demasiado.
DORA lo pone en términos de coste. Su informe sobre el retorno de la IA en el desarrollo de software, según lo resume InfoQ (mayo de 2026), habla del «impuesto de verificación» que supone revisar el código generado por IA, y avisa de que más código, más rápido, puede desbordar los pipelines de despliegue y las revisiones manuales. Y su informe de 2025 lo resume en una frase: la IA amplifica lo que ya tiene la organización, lo bueno y lo malo.
Juntándolo, nuestra lectura: el agente espera porque lo que devuelve no se puede dar por bueno sin que alguien lo mire, y la persona que lo mira llega tarde porque no sabía qué tenía que comprobar. Ya contamos dónde se atasca la ganancia en más código, la misma entrega; aquí el atasco es más amplio: no solo en la revisión, en todo el flujo.
El metatrabajo es el trabajo
Si la atención de una persona es el recurso escaso, lo razonable es gastarla donde más rinde: antes de lanzar al agente, no después. La tabla compara las tres partes del metatrabajo hechas a ratos y hechas con método. Es nuestra propuesta, no un resultado del estudio.
| Parte | Hecha a ratos | Hecha con método |
|---|---|---|
| Preparar | Una frase en la issue y el agente rellena lo que falta | Una especificación con alcance, límites y criterios de aceptación que se puedan comprobar |
| Revisar | Quien esté libre lee el diff entero, línea a línea | Una máquina comprueba lo comprobable (tests, análisis, criterios ejecutables) y la persona mira lo que no |
| Decidir | Se decide cuando el agente pregunta o cuando algo falla | Los puntos donde decide una persona, porque hay riesgo, están fijados antes de empezar |
Elaboración de onext
Las tres casillas de la derecha son lo que en el Spec-Driven Development (SDD), el desarrollo guiado por especificaciones, se hace antes de que el agente escriba una línea. Preparar es convertir la tarea en especificación, como explicamos en una issue no es una especificación. Revisar empieza por convertir los criterios de aceptación en la comprobación del merge. Y decidir es saber de antemano dónde se firma y cómo se deshace lo que haga el agente.
Cada decisión que se toma antes de lanzar al agente es una espera menos después. Una persona decide donde hay riesgo; en lo demás, decide lo que ya está escrito.
Qué cambia en la planificación del equipo
Dos cambios concretos, que proponemos nosotros:
- El metatrabajo se planifica. Escribir especificaciones, criterios de aceptación y las reglas del equipo para los agentes cuenta en el sprint como trabajo, con su tiempo. Si se hace en los huecos que deja la entrega, se hace mal o no se hace, y el agente vuelve a esperar.
- La revisión se diseña según el riesgo. No se reparte a quien esté libre. Un cambio de texto en una pantalla y un cambio en el cálculo de una factura no merecen la misma persona ni el mismo tiempo. Eso se decide antes y queda escrito.
Un ejemplo, inventado y de ningún cliente: un equipo pide al agente «exportar los pedidos a CSV». Sin preparar, el agente pregunta qué columnas, qué formato de fecha y qué pasa con los pedidos cancelados, y espera; o no pregunta y lo decide él, y la persona que revisa se lo encuentra en el diff. Con media hora de preparación, la especificación ya dice las columnas, el formato, que los cancelados no salen y que hay un test que lo comprueba. La persona que revisa solo tiene que mirar lo que el test no cubre.
Este tiempo de preparar y revisar es justo el que hay que enseñar a los perfiles nuevos, como contamos en desarrolladores junior: aprender a revisar: si supervisar exige las habilidades que el agente puede hacer perder, hay que practicarlas a propósito.
Lo que este dato no te dice
No te dice cuánto espera el agente en tu equipo. Anthropic es la empresa que fabrica el modelo, con un equipo que trabaja con él a diario y unas condiciones que no son las tuyas. Tampoco dice que más horas de agente signifiquen más entrega: lo que se mide para saber si funciona es la entrega y su calidad, no cuánto código sale ni cuántas horas trabaja el agente.
Lo que sí dice, y es lo que nos quedamos, es la dirección: cuando el agente hace más, el límite pasa a ser la atención de quien prepara, revisa y decide. Y eso se puede organizar.
Si quieres ver con alguien de fuera dónde espera hoy el agente en tu equipo, el diagnóstico es gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Antes, puedes ver en qué punto estás con el autodiagnóstico de SDD. Cómo es el resto del camino está en AI-Accelerated Development. El método completo está en Spec-Driven Development con IA.
Preguntas frecuentes
¿Qué es el metatrabajo cuando un equipo trabaja con agentes de IA?
Es el trabajo que no es la tarea en sí, sino lo que la prepara y la vigila: escribir especificaciones para que trabajen los agentes, poner a un agente a revisar lo que hace otro, montar herramientas para ver qué está pasando y vigilar los flujos. Anthropic lo mide en su propia empresa y ha visto que pasa del 10 % de las sesiones interactivas con Claude en otoño de 2025 al 22 % en primavera de 2026.
¿De verdad un agente de código pasa el 80 % del tiempo esperando?
En las sesiones interactivas que mide Anthropic en su propia empresa, sí: alrededor del 80 % del tiempo de reloj de la sesión el agente está esperando que una persona responda. Se calcula restando el tiempo activo del agente al tiempo total de la sesión, así que incluye esperas cortas. No significa que el agente esté parado el 80 % de la jornada ni que sea el dato de tu equipo.
¿Por qué la atención de una persona es el cuello de botella?
Porque el agente produce más rápido de lo que alguien puede leer, comprobar y decidir. Anthropic lo resume así: la aceleración convierte la atención humana en el cuello de botella de lo que producen los agentes. DORA lo llama el «impuesto de verificación»: el coste de revisar el código generado por IA.
¿Cómo se reduce el tiempo que el agente espera a una persona?
Decidiendo antes, no revisando más deprisa. Antes de lanzar al agente: qué se pide y con qué criterios de aceptación, qué comprueba una máquina sin que mire nadie (tests, análisis, criterios ejecutables) y en qué puntos decide una persona porque hay riesgo. Lo que queda abierto vuelve en forma de pregunta o de diff dudoso.
¿El metatrabajo es tiempo perdido que hay que recortar?
No. Es la parte del trabajo que decide si lo que hace el agente sirve. Lo que sí es un problema es hacerlo a ratos, sin método y robándole tiempo a la entrega. La propuesta de este insight es planificarlo como trabajo: escribir especificaciones y reglas del equipo cuenta en el sprint igual que escribir código.
¿Qué limitaciones tiene el estudio de Anthropic?
Es una sola empresa, la que fabrica el modelo, estudiando su propio despliegue. El metatrabajo se clasificó de forma automática sobre una muestra de 2.000 resúmenes de una línea, la adopción de herramientas no es aleatoria y hay 17 entrevistas. Los propios autores avisan de que más código no significa necesariamente mejor código ni más impacto en el negocio.
Fuentes
- Nathan Wilmers, Regina Catipon, Maxim Massenkoff y Peter McCrory (Anthropic), «How employment is changing at Anthropic», 16 de octubre de 2026.
- Saffron Huang y otros (Anthropic), «How AI is transforming work at Anthropic», 2 de diciembre de 2025.
- Matt Saunders, «New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment», InfoQ, 11 de mayo de 2026 (sobre el informe de DORA «ROI of AI-Assisted Software Development»).
- DORA, «State of AI-assisted Software Development 2025», 2025.
- Las cifras y citas de fuentes en inglés están traducidas por onext. La tabla, los dos cambios de planificación, el ejemplo y la lectura de por qué espera el agente son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →