Nota editorial: A medida que los agentes de IA se vuelven más baratos y fáciles de invocar, el desarrollo de software está entrando en una nueva etapa: la pregunta ya no es si podemos lanzar más agentes, sino si los humanos tenemos suficiente capacidad de atención para gestionar, juzgar y fusionar su producción.
Este artículo introduce un concepto muy inspirador: el «impuesto de orquestación». El coste de lanzar un agente es bajo, basta con un prompt o un clic; pero lo realmente caro son los pasos posteriores: verificar que el resultado es correcto, comprender su impacto en la arquitectura del sistema, resolver conflictos entre diferentes agentes y, finalmente, decidir qué código puede integrarse en la rama principal. Este trabajo no se puede paralelizar fácilmente; siempre regresa al mismo recurso en serie: el juicio humano.
El autor compara al desarrollador con el «GIL» (Global Interpreter Lock) dentro del sistema de agentes de IA, es decir, ese candado de un solo hilo que limita el rendimiento final de un sistema concurrente. Muchos agentes pueden ejecutarse simultáneamente, pero en cuanto se llega a las fases de juicio arquitectónico, revisión de código y fusión de conflictos, es necesario volver a pasar por el cerebro del desarrollador. Así, más agentes no significan necesariamente más producción, sino que pueden simplemente alargar la cola de tareas pendientes de revisión, sumergiendo al desarrollador en cambios de contexto más frecuentes y fatiga cognitiva.
Este es un aspecto a menudo pasado por alto en el auge actual de las herramientas de programación con IA: la sensación de eficiencia y la productividad real no siempre son lo mismo. Un panel de control lleno de agentes en ejecución crea la ilusión de «alta producción»; pero si el desarrollador no comprende, revisa e integra realmente esos cambios, lo que el sistema acumula al final puede no ser productividad, sino deuda técnica y deuda cognitiva.
Por lo tanto, lo que este artículo discute realmente no es «cómo usar más agentes», sino «cómo rediseñar el flujo de trabajo en torno a la atención humana». En la era de los agentes, la habilidad clave no es solo saber hacer preguntas o delegar tareas, sino saber qué tareas se pueden delegar a la máquina para procesamiento paralelo y cuáles deben reservarse para el juicio humano; cuándo se debe revisar por lotes y cuándo se debe detener la orquestación para volver a centrarse en un problema central.
La IA está ampliando la capacidad concurrente de producción de software, pero la atención humana sigue siendo el recurso más escaso y menos replicable del sistema. Un flujo de trabajo de agentes verdaderamente maduro no consiste en lanzar todas las tareas a la máquina, sino en diseñar seriamente la arquitectura de la propia atención, como se diseña un sistema de producción.
Lo siguiente es el texto original:
Ahora es muy fácil lanzar más agentes de IA. Pero que más agentes se ejecuten simultáneamente no significa que «tú» también seas más. Tu ancho de banda cognitivo no se puede paralelizar. Todo el juicio necesario para guiarlos, evaluar resultados y fusionar modificaciones debe, en última instancia, pasar por el mismo procesador en serie: tú mismo.
El llamado «impuesto de orquestación» es esencialmente el precio que pagas por olvidar esto. Y la única solución real es empezar a diseñar tu propia atención, como lo harías con cualquier sistema concurrente.
Hace poco participé en una mesa redonda en Google I/O con Richard Seroter, Aja Hammerly y Ciera Jaspan, hablando sobre cómo es hoy la ingeniería de software y cómo podría evolucionar. Al final, Richard nos preguntó: ¿cuál es la única cosa que los desarrolladores deberían llevarse de esta conversación y cambiar?
Expresé algo en lo que he estado pensando repetidamente estos meses: sentirse muy ocupado no equivale necesariamente a ser productivo. Puedes ejecutar 20 agentes simultáneamente y sentirte abrumado de trabajo. Pero eso no significa que hayas entregado el trabajo equivalente a 20 agentes.
Un poco antes en esa conversación, Richard le puso un nombre a este problema. Dijo: «Lo que acabas de describir es básicamente el impuesto de orquestación. No puedes gestionar 20 agentes con éxito dentro de tu propia cabeza».
Tenía toda la razón. Quiero desglosar este concepto más completamente, porque no es un problema de disciplina, sino de arquitectura.
Hubo una frase que casi dije al azar en esa mesa redonda y que ha estado rondando en mi mente desde entonces: ejecutar múltiples agentes no significa que haya más de ti en el mundo.
La asimetría que la gente no tiene en cuenta
Existe una asimetría oculta en el flujo de trabajo con agentes.
Iniciar un agente es muy barato. Solo necesitas pulsar una tecla o escribir un prompt. Pero cerrar el ciclo de un agente no es nada barato. Alguien tiene que comprobar si el resultado que devuelve es correcto y reconciliarlo con los cambios realizados por otros agentes.
Esa persona eres tú. Y solo hay uno de ti.
El mes pasado escribí sobre una parte de este problema en «Tu límite de agentes paralelos», centrándome principalmente en esa ansiedad ambiental: no saber qué hilo paralelo está fallando silenciosamente. Este artículo quiere hablar sobre la estructura detrás de ese coste.
Cuando empiezas a ver el desarrollo con agentes como un sistema concurrente, te das cuenta de que el humano es solo un componente dentro de ese sistema. Un componente lento y en serie.
Tú eres ese recurso de un solo hilo
Si has escrito código concurrente, ya tienes la intuición para entender este problema. Simplemente la has aplicado en el lugar equivocado hasta ahora.
Python tiene el Global Interpreter Lock, o GIL. Puedes crear tantos hilos como quieras, pero solo uno puede ejecutar bytecode de Python a la vez, porque todos deben adquirir ese candado primero.
Tú eres el GIL de tus agentes de IA.
Todos pueden ejecutarse al mismo tiempo. Pero tan pronto como su trabajo requiera una comprensión real de la arquitectura del sistema o necesite resolver conflictos de fusión, deben adquirir primero ese candado. Y solo hay uno de esos candados, y lo tienes tú.
La ley de Amdahl lo expresa con precisión: el límite superior de la aceleración obtenida por la paralelización depende de la parte del trabajo que aún debe realizarse en serie. Si una parte significativa de tu flujo no se puede paralelizar, sin importar cuántos núcleos añadas, eventualmente chocarás contra un límite duro.
En el desarrollo con agentes, esa parte en serie es el juicio.
Lanzar 8 agentes no acelera tu tiempo de juicio. Solo hace que la cola de tareas esperando a que las proceses sea más larga.
Es un hecho muy antiguo en la ingeniería de rendimiento, pero aún sorprende a mucha gente: optimizar la parte que no es el cuello de botella no aumenta el rendimiento general. Solo estás acumulando más trabajo inacabado delante del cuello de botella.
Añadir agentes optimiza la parte que de por sí no era la limitación. La limitación real es la fase de revisión, y el rendimiento total del sistema es, precisamente, el rendimiento de esa fase.
El impuesto de orquestación es el desajuste estructural entre la capacidad de producción de los agentes y lo que realmente puedes fusionar. Ocurre cuando haces que un recurso de un solo hilo gestione un sistema concurrente.
Forzar la situación no resuelve un límite estructural
En esa mesa redonda, dije algo: nunca me había sentido con herramientas tan eficientes como ahora, pero tampoco me había sentido nunca tan agotado.
Ambas sensaciones son completamente reales, y provienen de la misma causa.
Este agotamiento tiene una fuente muy concreta: es la sensación de llevar un procesador en serie continuamente al 100% de carga, sin dejar ningún margen.
Cada vez que vuelves a consultar a un agente que ha salido de tu foco de atención, pagas un coste de cambio de contexto. Debes vaciar tu mente y luego recargar otro contexto desde cero.
Una CPU puede hacer esto en microsegundos, y aún así, los arquitectos intentan evitar cambios frecuentes. A ti te lleva minutos, y nunca puedes restaurar el contexto perfectamente.
5 agentes no son 1 unidad de trabajo repetida 5 veces. Son 5 recargas de contexto desde cero (cold starts), más un proceso mental ejecutándose en segundo plano, preocupándose constantemente por qué agente deberías revisar ahora.
No puedes resolver un límite estructural «esforzándote más». Este impuesto siempre se paga.
Si intentas forzarlo, eventualmente aparecerá de otra forma: o las revisiones de código se vuelven cada vez más superficiales, o entras en un estado de «rendición cognitiva»: como formar tu propio juicio consume demasiada atención, simplemente aceptas el código que escribe el agente.
O pagas este impuesto de forma activa, o permites que destruya silenciosamente tu comprensión del propio sistema.
Diseña tu atención como diseñarías un sistema
Por lo tanto, debes tratar tu atención como un recurso escaso y en serie.
No diseñarías un sistema distribuido sin considerar los cuellos de botella. Entonces, por favor, respeta a tu cerebro de la misma manera.
Estos son algunos métodos que realmente me han funcionado:
Expande tu equipo de agentes según tu capacidad de revisión, no según las capacidades de la interfaz.
Un buen sistema concurrente utiliza mecanismos de backpressure para evitar que la cola crezca indefinidamente. El productor debe ralentizarse para coincidir con la capacidad de procesamiento del consumidor.
Tu número de agentes es el productor. Tu capacidad de revisión es el consumidor. La cantidad correcta de agentes en paralelo debería ser la cantidad que puedas revisar seriamente. Para la mayoría, esto suele ser un número bajo, de un solo dígito.
Las herramientas de IA estarán encantadas de dejarte lanzar 20 agentes, pero eso es solo una función de la interfaz, no significa que realmente tengas la capacidad de gestionarlos.
Clasifica las tareas.
Cuando Richard me preguntó cómo manejo esto, mencioné este método. Divido las tareas en dos pilas.
La primera pila es de trabajo relativamente independiente, que estoy dispuesto a delegar a agentes que se ejecutan en la nube en segundo plano. Estas tareas pueden ejecutarse de forma asíncrona y normalmente solo requieren una verificación final por mi parte.
La segunda pila son tareas complejas, donde el trabajo real en sí es el juicio. Como un bug muy extraño o un diseño de arquitectura.
El mayor error es intentar paralelizar también este segundo tipo de tareas. Procesar múltiples tareas complejas en paralelo no amplía tu producción, solo hace que ese candado sea disputado repetidamente, y al final todos los resultados empeoran.
Revisión por lotes.
Cada cambio de contexto te cuesta caro. Sentarte una vez y revisar los resultados de 4 agentes es mucho más barato que revisar uno, hacer otra cosa, y luego tener que arrancar en frío para revisar otro.
Dale una «correa» más larga a los agentes. Deja que el trabajo se acumule un poco y luego procésalo como un lote.
Usa ese candado solo para el juicio.
No desperdicies tu cerebro en cosas que la máquina puede verificar por sí misma. Haz que los agentes escriban pruebas que pasen o generen capturas de pantalla.
Que demuestren ellos mismos esa parte aburrida pero verificable que es el 80%. Así, tu atención escasa solo necesita gastarse en el 20% que realmente requiere juicio humano.
Protege tu tiempo en serie.
El cuello de botella necesita tu mejor tiempo, no los fragmentos que te quedan entre revisiones de agentes.
A veces, la acción de mayor apalancamiento es detener completamente la orquestación: apagar la computadora llena de agentes, concentrarse solo en un problema y mantener firmemente ese candado durante todo el proceso.
La orquestación no es el trabajo real. Es solo la sobrecarga generada alrededor del trabajo.
Aja señaló que la capacidad arquitectónica se ha convertido ahora en la habilidad más urgente: necesitas saber qué tarea es adecuada para un agente y qué tarea es demasiado grande para él.
Me gustaría añadir: tú también eres un componente dentro de este sistema. Tu atención tiene un rendimiento en serie conocido y bastante bajo. El sistema o respeta ese número, o lo sorteará reduciendo silenciosamente tus estándares.
Estar ocupado no equivale a ser productivo
Esto es crucial, porque este modo de fracaso es casi invisible para ti mismo.
20 agentes en ejecución te dan una sensación de «productividad explosiva». El panel de control está lleno, todo se mueve. Pero esa sensación se ha desvinculado de la realidad de fusionar código de alta calidad en la rama principal.
Puedes estar ocupado al máximo y, sin embargo, no producir casi nada. Desde la experiencia interna, ambas cosas se sienten casi idénticas.
Ciera mencionó la investigación de Margaret-Anne Storey sobre la deuda. Hablamos sobre deuda técnica y también sobre deuda cognitiva.
El impuesto de orquestación no pagado te hará acumular ambos tipos de deuda.
Fusionas cosas que no has leído con atención. Tu modelo mental del código base queda completamente desactualizado. Estos problemas no aparecerán hoy en el panel de control. Aparecerán cuando algo falle en producción, y mires el sistema de repente dándote cuenta de que ya no sabes cómo funciona realmente.
Así que, la conclusión real es: lanzar agentes no es una habilidad. Cualquiera puede ejecutar 20.
La verdadera habilidad es diseñar el sistema en torno a ese recurso en serie que no se puede clonar ni paralelizar.
Ese recurso es tu atención.
Diséñala como lo harías con cualquier componente crítico del que dependa un entorno de producción.
