Nota del editor: A medida que los Agentes de IA se vuelven cada vez más baratos y fáciles de invocar, el desarrollo de software entra en una nueva fase: la pregunta ya no es si se pueden iniciar más Agentes, sino si los humanos aún tienen suficiente atención para gestionar, evaluar y fusionar sus resultados.

Este artículo presenta un concepto muy inspirador: el "impuesto de orquestación". El costo de iniciar un agente es bajo, requiriendo solo una prompt o un clic; pero lo verdaderamente costoso son las etapas posteriores: verificar si los resultados son correctos, comprender su impacto en la arquitectura del sistema, resolver conflictos entre diferentes agentes y, finalmente, decidir qué código puede ingresar a la rama principal. Estas tareas no se pueden paralelizar fácilmente y aún dependen del mismo recurso secuencial: el juicio humano.

El autor compara al desarrollador con el «GIL» en un sistema de Agentes de IA, es decir, el bloqueo de un solo hilo que limita el rendimiento final del sistema concurrente. Múltiples Agentes pueden ejecutarse simultáneamente, pero siempre que entren en las fases de evaluación de arquitectura, revisión de código y fusión de conflictos, deben volver a pasar por la mente del desarrollador. Por lo tanto, más Agentes no necesariamente significa mayor producción; podría simplemente alargar la cola de tareas pendientes de revisión y someter al desarrollador a cambios de contexto más frecuentes y fatiga cognitiva.

Esto también es un aspecto fácilmente pasado por alto en la actual ola de herramientas de programación con IA: la sensación de eficiencia no siempre es lo mismo que la productividad real. Un panel de agentes ejecutándose en toda la pantalla puede generar la ilusión de «alta productividad»; pero si los desarrolladores no comprenden, revisan e integran realmente estos cambios, el sistema finalmente podría acumular no productividad, sino deuda técnica y deuda cognitiva.

Por lo tanto, lo que realmente se discute en este artículo no es «cómo usar más agentes», sino «cómo rediseñar los flujos de trabajo en torno a la atención humana». En la era de los agentes, las habilidades clave no solo consisten en saber hacer preguntas o asignar tareas, sino en saber qué tareas se pueden delegar a la máquina para procesamiento paralelo y cuáles deben mantenerse bajo juicio humano; cuándo es adecuado revisar en lotes y cuándo detener la orquestación para volver a centrarse en un problema central.

La IA está ampliando la capacidad concurrente de la producción de software, pero la atención humana sigue siendo el recurso más escaso e irreproducible del sistema. Los flujos de trabajo de Agentes verdaderamente maduros no consisten en delegar todas las tareas a la máquina, sino en diseñar cuidadosamente la arquitectura de tu atención, como se haría con un sistema de producción.

A continuación se encuentra el texto original:

Ahora es mucho más fácil iniciar más agentes de IA. Pero tener más agentes funcionando simultáneamente no significa que tú también te multipliques. Tu ancho de banda cognitivo no se puede paralelizar. Todo el juicio realmente necesario para guiarlos, evaluar los resultados y combinar modificaciones debe pasar finalmente por el mismo procesador secuencial: tú mismo.

Lo que se llama «impuesto de programación» es, en esencia, el costo que pagas cuando olvidas este punto. La única solución real es comenzar a diseñar tu propia atención como si diseñaras cualquier sistema concurrente.

Anteriormente participé en una mesa redonda en Google I/O junto con Richard Seroter, Aja Hammerly y Ciera Jaspan, donde hablamos sobre cómo es la ingeniería de software hoy y cómo podría evolucionar en el futuro. Al final, Richard nos preguntó: ¿Cuál es la cosa más importante que los desarrolladores deberían llevarse y cambiar tras escuchar esta conversación?

Dije algo que he estado reflexionando durante estos meses: sentirse ocupado no equivale a tener realmente resultados. Puedes ejecutar simultáneamente 20 Agentes y sentir que estás extremadamente ocupado, pero eso no significa que hayas entregado la cantidad de trabajo correspondiente a 20 Agentes.

En un punto anterior de esa conversación, Richard le puso un nombre a esta pregunta. Dijo: «Lo que acabas de describir es realmente la planificación fiscal. No puedes gestionar exitosamente 20 agentes solo en tu cabeza».

Él tiene toda la razón. Quiero desglosar este concepto más completamente, porque no se trata de un problema de disciplina, sino de una problemática de arquitectura.

En esa mesa redonda, dije algo casi de pasada, que luego no dejó de rondarme en la mente: ejecutar múltiples Agentes no significa que haya un nuevo tú en el mundo.

La asimetría que las personas no han considerado

En el flujo de trabajo del agente existe una asimetría oculta.

Iniciar un agente es muy barato. Solo necesitas pulsar una tecla o escribir un prompt. Pero completar el ciclo cerrado del agente no es nada barato. Alguien tiene que verificar que los resultados que devuelve sean correctos y recoordinarlos con los cambios realizados por otros agentes.

Esta persona eres tú. Y solo tienes uno.

El mes pasado, escribí parte de este problema en "Tu límite de agentes paralelos", centrándome principalmente en esa ansiedad ambiental: no sabes qué hilo paralelo está fallando en silencio. Este artículo pretende explorar la estructura detrás de este costo.

Cuando comienzas a ver el desarrollo de Agentes como un sistema concurrente, te das cuenta de que los humanos son simplemente un componente dentro de este sistema: un componente serial muy lento.

Eres ese recurso de un solo hilo

Si has escrito código concurrente, ya posees la intuición para comprender este problema. Solo que antes aplicaste esta intuición en el lugar equivocado.

Python tiene un bloqueo global del intérprete, también conocido como GIL. Puedes crear cualquier cantidad de hilos, pero solo un hilo puede ejecutar bytecode de Python a la vez, ya que todos deben obtener primero este bloqueo.

You are the GIL of your AI Agent.

Todos pueden ejecutarse simultáneamente. Pero siempre que su trabajo requiera comprender realmente la arquitectura del sistema o resolver conflictos de fusión, deben obtener primero esta llave. Y solo hay una llave, que la tienes tú.

La ley de Amdahl lo explica con gran precisión: el límite superior de aceleración que ofrece la paralelización depende de la parte del trabajo que aún debe completarse de forma secuencial. Si gran parte de tu proceso no se puede paralelizar, entonces, sin importar cuántos núcleos inviertas, eventualmente te encontrarás con un límite rígido.

En el desarrollo de Agentes, esta parte serial es el juicio.

Iniciar 8 Agentes no acelerará tu tiempo de decisión. Solo hará que la cola de elementos pendientes de procesamiento sea más larga.

Es un hecho antiguo en ingeniería de rendimiento, pero muchas personas aún se sorprenden al respecto: optimizar partes que no son cuellos de botella no aumenta el throughput general. Solo estás acumulando más trabajo pendiente antes del cuello de botella.

El agente optimiza la parte que nunca fue una restricción. La verdadera restricción es la etapa de revisión, y el rendimiento total del sistema es exactamente igual al rendimiento de esta etapa.

La carga tributaria es la brecha estructural entre la capacidad de producción del agente y el contenido que realmente puedes consolidar. Ocurre cuando permites que un recurso de un solo hilo gestione un sistema concurrente.

No se puede resolver el límite estructural con resistencia ciega

En esa mesa redonda, dije una frase: nunca antes había sentido que mis herramientas fueran tan eficientes, pero tampoco había estado tan cansado como ahora.

Ambas sensaciones son completamente reales y provienen de la misma causa.

Este agotamiento tiene una fuente muy específica: es la sensación de mantener continuamente un procesador serial al 100% sin dejar ningún margen.

Cada vez que vuelves a revisar un agente que ha salido de tu campo de atención, debes pagar un costo de cambio de contexto. Debes vaciar tu mente y volver a cargar desde cero otro contexto.

La CPU puede completar esto en microsegundos, y aun así, los arquitectos evitan cambiar frecuentemente. Tú necesitas minutos para hacerlo, y nunca puedes recuperar perfectamente el contexto.

5 agentes no son repetir 1 vez de trabajo 5 veces. Son 5 reinicios en frío con recarga de contexto, más un proceso cerebral en segundo plano que continúa preocupándose por qué agente deberías revisar en este momento.

No puedes resolver una limitación estructural con «esfuerzo adicional». Este impuesto siempre debe pagarse.

Si intentas resistir, acabará apareciendo de otra forma: ya sea que las revisiones de código se vuelvan cada vez más superficiales, o que entres en un estado de «rendición cognitiva»—porque formar tus propios juicios consume demasiada atención, así que simplemente aceptas directamente el código escrito por el agente.

O pagas este impuesto activamente, o permites que destruya lentamente tu comprensión del sistema desde las sombras.

Diseña tu atención como un sistema de diseño

Por lo tanto, debes tratar tu atención como un recurso escaso y serial.

No ignorarías los cuellos de botella al diseñar un sistema distribuido. Por favor, brinda el mismo respeto a tu cerebro.

Aquí hay algunos métodos que realmente funcionan para mí:

Un buen sistema concurrente utiliza mecanismos de retroalimentación para evitar que las colas crezcan indefinidamente. El productor debe reducir su velocidad para adaptarse a la capacidad de procesamiento del consumidor.

Tu cantidad de Agentes es la de productores, y tu capacidad de revisión es la de consumidores. La cantidad correcta de Agentes en paralelo debería ser el número de revisiones de código que puedes realizar con atención. Para la mayoría de las personas, esto suele ser un número muy bajo, de un solo dígito.

Las herramientas de IA por supuesto estarán encantadas de permitirte iniciar 20 agentes, pero eso es solo una función de la interfaz de usuario y no significa que realmente tengas la capacidad de gestionarlos.

Cuando Richard me preguntó cómo manejar este asunto, mencioné este método. Dividiré la tarea en dos montones.

El primer conjunto de tareas es un trabajo relativamente independiente que estoy dispuesto a asignar a un agente que se ejecute en segundo plano en la nube. Estas tareas pueden ejecutarse de forma asíncrona y generalmente solo requieren que yo realice una revisión final al final.

El segundo grupo son tareas complejas, donde el trabajo real consiste en juzgar. Por ejemplo, un bug muy extraño o un diseño de arquitectura.

El mayor error es intentar paralelizar también las tareas de segunda categoría. Procesar múltiples tareas complejas en paralelo no aumentará tu productividad, sino que solo hará que se compita repetidamente por ese candado, terminando con una disminución en la calidad de todos los resultados.

Cada cambio de contexto te cuesta mucho. Sentarte una vez para revisar los resultados de 4 agentes es mucho más económico que mirar uno, hacer otra cosa y luego reiniciar para mirar otro.

Dale al agente una correa más larga. Deja que el trabajo se acumule un poco, luego procesa todo como un lote.

No desperdicies tu cerebro en cosas que la máquina puede verificar por sí misma. Deja que el agente escriba pruebas que pasen o genere capturas de pantalla.

Déjalos demostrar por sí mismos esas 80% partes aburridas pero verificables. Así, tu atención escasa solo se centrará en el 20% que realmente requiere juicio humano.

El cuello de botella necesita tu mejor tiempo, no los fragmentos de tiempo que te queden entre comprobaciones de Agent.

A veces, el movimiento de mayor apalancamiento es simplemente dejar de hacer coreografías: apaga la computadora llena de Agentes, concéntrate únicamente en una pregunta y mantén firmemente esa llave durante todo el proceso.

La programación no es un trabajo real. Solo es el gasto generado alrededor del trabajo.

Aja señala que la capacidad de arquitectura ya se ha convertido en la habilidad más urgente: necesitas saber qué tareas son adecuadas para incluirlas en un Agente y cuáles son demasiado grandes para él.

También quiero agregar un punto: tú mismo eres un componente de este sistema. Tu atención tiene un ancho de banda serial conocido y muy bajo. El sistema o respeta este número o lo elude reduciendo silenciosamente tus estándares.

Estar ocupado no equivale a ser productivo

This is very important because this failure mode is almost invisible to you personally.

20 agentes en ejecución te darán una sensación de “productividad desbordante”. El panel está lleno, todo está en movimiento. Pero esa sensación ya no tiene relación con la verdadera integración de código de alta calidad en la rama principal.

Puedes estar tan ocupado hasta el límite, pero tener casi ninguna producción real. Desde la experiencia interna, ambos son casi idénticos.

Ciera mencionó la investigación de Margaret-Anne Storey sobre la deuda. Hablamos sobre la deuda técnica y también sobre la deuda cognitiva.

No pagar la tasa de organización te hará acumular simultáneamente ambas deudas.

Has fusionado cosas que no leíste cuidadosamente. Tu modelo mental del repositorio de código está completamente obsoleto. Estos problemas no aparecerán en el panel hoy; se manifestarán cuando el sistema falle en producción, y entonces mirarás el sistema y de repente te darás cuenta de que ya no sabes cómo funciona realmente.

Entonces, la conclusión real es: iniciar un agente no es una habilidad. Cualquiera puede ejecutar 20.

La verdadera capacidad consiste en diseñar sistemas alrededor de un recurso serial que no puede ser clonado ni paralelizado.

Este recurso es tu atención.

Diseña como si fuera un componente crítico en un entorno de producción.