Tiempo de lectura: 11 minutos
Cuando un equipo empieza a trabajar con agentes de IA, la primera sensación es de abundancia. Lo que costaba un día sale en una hora, y la tentación es inmediata: si un agente puede con una funcionalidad, cinco agentes pueden con cinco. Se abren hilos en paralelo —una funcionalidad nueva, dos correcciones, una migración, un informe— y durante un par de semanas parece que el equipo vuela.
Luego llega el cansancio. No el de programar, que ya casi nadie programa a mano, sino otro más difícil de nombrar: el de estar siempre validando, integrando y cambiando de tema. Este artículo va de ese cansancio, de por qué aparece y de cómo organizar el trabajo para que un equipo de personas con agentes sea sostenible, no solo rápido durante un mes.
Lo que ha cambiado: el humano ya no hace, valida
Con agentes, el trabajo de una persona del equipo cambia de forma. Antes escribía el código y lo revisaba otra persona. Ahora escribe poco y revisa mucho: lee lo que ha generado un agente, decide si sirve, lo integra con lo que ya había, lo prueba, lo corrige o lo tira. El agente produce; la persona valida, integra y responde.
Esto tiene una consecuencia que conté en Generar código sin revisar no escala: el cuello de botella no desaparece, se mueve. Lo lento ya no es escribir, es leer, decidir y entender. Y eso lo siguen haciendo personas, con las mismas horas y la misma cabeza que tenían antes.
La diferencia con aquel artículo es el foco. Allí hablaba de lo que se rompe en el producto —la deuda técnica y la deuda cognitiva— cuando nadie lee lo que se genera. Aquí hablo de lo que se rompe en las personas cuando sí leen, pero lo hacen repartidas entre demasiados frentes a la vez.
El coste que no sale en el tablero: cambiar de contexto
Cambiar de tarea no es gratis, y hace tiempo que se sabe. Gerald Weinberg lo estimó en su libro Quality Software Management (1992): con dos proyectos a la vez, una persona pierde en torno al 20 % de su tiempo en cambiar de uno a otro; con tres, cerca del 40 % (tabla reproducida aquí). Son estimaciones de experiencia, no un experimento, pero la forma de la curva se ha confirmado muchas veces: cada hilo nuevo cuesta más que el anterior.
La psicología explica por qué. Sophie Leroy llamó residuo de atención a lo que queda de la tarea anterior cuando pasas a otra: si la dejaste a medias, una parte de tu cabeza sigue en ella, y rindes peor en la nueva (Leroy, 2009). Y Gloria Mark y su equipo midieron qué hacemos cuando nos interrumpen: trabajamos más rápido para compensar, pero con más estrés, más frustración y más sensación de presión (Mark, Gudith y Klocke, 2008). Es decir, la interrupción no siempre se nota en el resultado del día. Se nota en cómo acaba la persona.
Los agentes multiplican las dos cosas. Cada hilo abierto deja un residuo, y cada agente que termina es una interrupción: un aviso, una PR, un resultado que espera. Con cinco agentes trabajando en cinco hilos, la persona ya no decide cuándo cambiar de tema: lo deciden los agentes, cada vez que acaban.
Hay además un efecto engañoso. En un estudio controlado de 2025, desarrolladores experimentados en proyectos que conocían bien tardaron un 19 % más en terminar sus tareas cuando usaban herramientas de IA… mientras creían que habían ido un 20 % más rápido (METR, 2025). Las herramientas han mejorado desde entonces y el propio METR ha anunciado que cambia el diseño de sus experimentos, así que el número hay que leerlo como una señal y no como una ley. La señal es esta: la sensación de ir rápido no es una medida.
El mismo día, en dos modelos
Para verlo en concreto, uso el caso que usamos en formación. Marc es el tech lead del equipo de GymApp, la aplicación de la cadena de gimnasios GymTonic. El equipo trabaja con agentes desde hace unos meses. Esta semana tiene cinco cosas encima: la nueva pantalla de reservas, un fallo en los pagos, la migración del sistema de avisos, un informe que le ha pedido Nuria (la product owner) y un bug de login que ha aparecido en producción.
Modelo A: cinco hilos a la vez. Marc lanza un agente para cada frente el lunes por la tarde. El martes, cada agente va terminando a su ritmo y le avisa. A las 9:40 llega el primer resultado de pagos, a las 10:05 una propuesta para la migración, a las 10:40 un borrador del informe. Marc va de uno a otro: revisa un poco, corrige una instrucción, vuelve a lanzar, abre el siguiente. A media mañana ya no recuerda qué había decidido sobre la pantalla de reservas a primera hora. El bug de login, que es lo único urgente, lo toca cuatro veces en trozos de quince minutos.
Modelo B: una spec y un hueco para urgencias. Marc empieza el día escribiendo la spec de la pantalla de reservas: qué tiene que pasar, qué no, cómo se comprueba. Lanza el agente con esa spec. Deja un solo hueco para lo urgente, y el bug de login entra ahí. Pagos, migración e informe esperan en la cola: no se lanzan hasta que haya sitio. Los avisos de los agentes no le interrumpen: se acumulan y los mira en dos franjas fijas, a las 11 y a las 14.
Al final del martes, el modelo A tiene veinticuatro cambios de contexto, un hilo terminado y cuatro a medias. El modelo B tiene nueve cambios y dos cosas terminadas: la urgencia cerrada y la pantalla de reservas lista para la revisión final. Son números de un ejemplo, no de un estudio, pero cualquiera que haya trabajado así reconoce los dos días.
Lo importante no es cuántas cosas ha "tocado" Marc, sino dos detalles. En el modelo A, la urgencia tardó todo el día en cerrarse, porque competía con otros cuatro hilos por su atención. Y en el modelo A, a las seis de la tarde, Marc tiene cuatro cosas a medias que mañana tendrá que volver a entender desde cero. Ese es el residuo de atención, acumulado.
Por qué el modelo de pocos hilos gana: la cola, no la velocidad
La explicación de fondo es vieja y no tiene nada que ver con la IA. La Ley de Little dice que el tiempo que tarda en salir un trabajo es igual al trabajo en curso dividido por el ritmo al que se termina. Si el ritmo lo marca la capacidad de revisión de una persona —y con agentes, lo marca—, abrir más hilos no saca más trabajo por el otro lado: alarga todos los que ya estaban abiertos. Es el mismo argumento de por qué limitar el trabajo en curso en Kanban, aplicado a un equipo en el que parte del trabajo lo hacen máquinas.
Hay un dato que apunta en la misma dirección. El informe DORA de 2024 encontró que, en los equipos que más habían aumentado el uso de IA, la estabilidad de las entregas empeoraba (el informe estima un 7,2 % menos por cada 25 % más de adopción), y sus autores apuntan como posible causa lotes de cambios más grandes en lugar de cambios pequeños y frecuentes (DORA, 2024). Muchos hilos a la vez producen exactamente eso: integraciones grandes, tardías y difíciles de revisar.
El modelo B no funciona porque Marc sea más disciplinado. Funciona porque cambia dónde pone la atención. Con Spec-Driven Development, el criterio humano se concentra en dos momentos: antes, al escribir la spec, y después, al revisar contra ella. En medio, el agente trabaja sin que nadie lo vigile. Es lo que desarrollo en specs que la IA convierte en código sin retrabajo: la spec no sustituye al criterio, lo concentra. Y concentrar es justo lo contrario de dispersar.
Cuándo el paralelo sí funciona
Sería falso decir que muchos hilos a la vez nunca tienen sentido. Los tiene, en condiciones concretas.
| Situación | Modelo | Por qué |
|---|---|---|
| Correcciones pequeñas e independientes, con tests que las cubren | Paralelo | Cada una se valida en minutos y no toca a las demás; el coste de cambiar de una a otra es bajo |
| Exploración: varios prototipos que se van a tirar casi todos | Paralelo | Es divergencia, no entrega. Se revisan juntos al final, no uno a uno según llegan |
| Producto joven con mucho backlog independiente y equipo con experiencia en agentes | Paralelo con límite | Hay trabajo que no se pisa; aun así, un límite de hilos por persona evita el desgaste |
| Funcionalidad nueva que toca varias partes del sistema | Pocos hilos + spec | La integración es donde está el riesgo; en paralelo, se descubre tarde |
| Urgencias de producción | Hueco reservado | Una urgencia que compite con cuatro hilos más tarda todo el día |
| Equipo que empieza con agentes o producto maduro con clientes exigentes | Pocos hilos + spec | Todavía no hay evals ni criterio compartido que permitan revisar rápido y bien |
La regla de fondo: el paralelo funciona cuando revisar es barato. Si cada resultado se valida en minutos porque hay tests, evals y una spec clara, el coste de cambiar de hilo es pequeño. Si cada resultado exige leerlo entero, entenderlo e integrarlo a mano, el paralelo solo traslada el trabajo a la cabeza de alguien.
Esta web la hago así, y aprendí lo mismo por las malas
Esta web —el blog, el campus de cursos, el panel de administración— la desarrollo yo solo, con agentes, desde varias máquinas y muchas veces con varias sesiones abiertas a la vez. Durante un tiempo trabajé exactamente en el modelo A: una sesión con una funcionalidad, otra con un arreglo, otra con contenido, todas avanzando en paralelo.
Funcionó hasta que dejó de hacerlo. Un día, una sesión que partía de una versión desfasada del código integró sus cambios y se llevó por delante una pestaña entera del panel de administración. Otro día, otra hizo lo mismo con 260 líneas del manual del sistema. Ningún agente se equivocó en lo que le pedí. El problema era que yo tenía demasiados hilos abiertos para saber qué estaba pasando en cada uno.
Lo que cambié no fue la velocidad de los agentes. Fue la forma de trabajar: hoy hay una comprobación automática que frena cualquier subida que borre una pestaña o una parte grande de la documentación, y un registro compartido —una bitácora y una lista de pendientes— que cada sesión lee al empezar y actualiza al terminar, para que ninguna trabaje a ciegas sobre lo que hizo otra. Y sobre todo, trabajo con menos hilos a la vez. El resultado no es que haga menos: es que termino más y rehago menos.
Cinco cambios para pasar al modelo de pocos hilos
Ninguno exige frenar al equipo ni dejar de usar agentes. Los cinco se pueden probar en un mes.
| Cambio | Qué se decide y quién | Qué queda por escrito | De dónde sale el tiempo |
|---|---|---|---|
| 1. Límite de hilos por persona | El equipo, en la retrospectiva: dos por persona, uno planificado y un hueco para urgencias | El límite, visible en el tablero | De no abrir hilos que antes se quedaban a medias |
| 2. Ningún agente sin spec | El equipo: nada se lanza sin qué tiene que pasar, qué no y cómo se comprueba | La spec, en el repositorio, junto al código (cómo escribirla) | Del retrabajo de corregir resultados de instrucciones vagas |
| 3. Franjas de revisión, avisos agrupados | Cada persona: dos o tres franjas al día; fuera de ellas, los avisos de los agentes esperan | Las franjas, en el calendario del equipo | Del tiempo perdido en cada interrupción |
| 4. "Hecho" incluye "integrado y entendido" | El equipo: nada se da por terminado hasta que está integrado y alguien distinto de quien lo lanzó puede explicarlo | La Definición de Done, con la frase literal | De los fallos de integración que hoy aparecen al final |
| 5. Medir la cola, no la actividad | El tech lead y el equipo: tiempo de ciclo, trabajo esperando revisión y retrabajo | Un panel con tres números, revisado en cada retro | Sustituye a contar PRs o tareas cerradas |
Dos avisos. El primero: el cambio 1 es el que más cuesta, porque durante los primeros días parece que el equipo hace menos. Lo que hace es terminar antes lo que empieza, y eso se ve a las dos semanas en el tiempo de ciclo. El segundo: el cambio 3 no funciona si es individual. Si la mitad del equipo tiene franjas y la otra mitad espera respuesta inmediata, las franjas duran un día. Es un acuerdo de equipo, no una técnica de productividad personal.
Qué medir para saber si funciona
Tres señales, y ninguna es "cuánto se ha generado":
Tiempo de ciclo. Desde que un trabajo empieza hasta que está integrado y en uso. Si baja al limitar los hilos, el límite está funcionando. Es la misma métrica de flujo que ya usan muchos equipos, y la chuleta de métricas DORA y de flujo tiene cómo calcularla.
Trabajo esperando revisión. Cuántos resultados de agentes hay en la cola sin revisar, y cuánto llevan ahí. Si crece semana a semana, el equipo está produciendo más de lo que puede validar, y abrir más hilos solo lo empeorará.
Retrabajo. Qué parte de lo integrado hay que corregir o rehacer en las dos semanas siguientes. Es la señal más fiable de que se está revisando con prisa.
Y una cuarta que no es un número: en la retrospectiva, una pregunta a cada persona sobre cómo ha terminado la semana. El estudio de Gloria Mark lo explica: la interrupción se paga en estrés antes que en resultados. Si solo miras los resultados, te enterarás tarde.
Qué le toca a producto y a dirección
Nada de esto lo arregla el tech lead solo.
Al product owner le toca ordenar la cola. Con agentes, la tentación es pedir cinco cosas a la vez "porque ahora se puede". El trabajo del PO es decidir cuál va primero y aceptar que las otras esperen, que es exactamente lo que siempre fue ordenar un backlog. También le toca escribir, o ayudar a escribir, la parte de la spec que dice qué problema resuelve cada cosa.
A dirección le toca dejar de medir volumen. Mientras el panel de dirección cuente funcionalidades lanzadas o PRs cerradas, el equipo abrirá más hilos para que los números suban. Lo que se mide es lo que se hace. Y le toca también una decisión de estructura: el límite ya no es cuánta gente hay en el equipo, sino cuántos hilos puede validar cada persona. Equipos más pequeños, con menos hilos por persona, sostienen más trabajo terminado que equipos grandes con todo abierto a la vez.
Preguntas frecuentes
¿Es sostenible trabajar con muchos agentes de IA en paralelo? Solo si revisar cada resultado es barato: tareas pequeñas, independientes y cubiertas por tests o evals. Cuando cada resultado exige leerlo, entenderlo e integrarlo a mano, muchos hilos a la vez convierten a la persona en el cuello de botella y en el receptor de interrupciones constantes. El coste aparece como cansancio y retrabajo antes que en los resultados del día.
¿Qué es el residuo de atención y por qué importa al trabajar con agentes? Es la parte de la atención que sigue en una tarea anterior cuando se pasa a otra, sobre todo si la primera quedó a medias; la describió Sophie Leroy en 2009 y reduce el rendimiento en la tarea nueva. Con agentes importa porque cada hilo abierto deja un residuo y cada agente que termina provoca un cambio de tarea que no decide la persona.
¿Cuántas tareas en paralelo debería tener una persona que trabaja con agentes? Como punto de partida, dos: un trabajo planificado y un hueco reservado para urgencias. Es un límite para probar y ajustar en la retrospectiva, no una ley. Lo que indica si es el adecuado es el tiempo de ciclo y la cola de trabajo esperando revisión: si bajan, el límite funciona.
¿Qué tiene que ver Spec-Driven Development con la carga de trabajo del equipo? SDD concentra el criterio humano en dos momentos: al escribir la spec y al revisar el resultado contra ella. En medio, el agente trabaja sin supervisión constante. Eso reduce los cambios de contexto y hace que revisar sea más rápido, porque hay un criterio escrito contra el que comparar en lugar de juzgar cada resultado desde cero.
¿Cómo se evitan las interrupciones de los agentes sin perder velocidad? Agrupando: los resultados de los agentes se acumulan en una cola de revisión y la persona los mira en dos o tres franjas fijas al día, en lugar de cada vez que llega un aviso. Para que funcione tiene que ser un acuerdo de todo el equipo, y necesita un hueco reservado para urgencias reales que no espere a la siguiente franja.
¿Los equipos con agentes tienen que ser más pequeños? El límite deja de ser cuántas personas hay y pasa a ser cuántos hilos puede validar bien cada una. En la práctica eso suele llevar a equipos más pequeños y con menos trabajo abierto a la vez, porque cada persona coordina ya con sus propios agentes además de con sus compañeros.
Por dónde seguir
Si quieres ver dónde está tu equipo antes de cambiar nada, el diagnóstico de velocidad de entrega tarda cinco minutos y mide justo el flujo, no la actividad. Si el problema es que las specs no aguantan a un agente, empieza por Vibe coding vs Spec-Driven Development. Y si quieres entender qué pasa dentro de un sistema de varios agentes y cómo se vigila, está en la dinámica de los agentes de IA.
Recursos relacionados
- Generar código sin revisar no escala: por qué tu equipo va más rápido y entiende menos
- Specs que la IA convierte en código sin retrabajo
- Cómo y por qué limitar el WIP
- El círculo vicioso del exceso de trabajo en curso
- Cómo atacar con Kanban los 7 desperdicios en el desarrollo de software
- Acuerdos de equipo para usar IA
- La dinámica de los agentes de IA: orquestación, fallos y producción