Editor’s note: As AI agents become cheaper and easier to invoke, software development is entering a new phase: the question is no longer whether we can launch more agents, but whether humans still have enough attention to manage, evaluate, and consolidate their outputs.
Este artigo apresenta um conceito muito inspirador: o "imposto de orquestração". O custo para iniciar um Agente é baixo, exigindo apenas um Prompt ou um clique; mas o verdadeiramente caro são as etapas subsequentes: verificar se os resultados estão corretos, compreender seu impacto na arquitetura do sistema, resolver conflitos entre diferentes Agentes e, finalmente, decidir quais códigos podem ser integrados à ramificação principal. Essas tarefas não podem ser facilmente paralelizadas e ainda dependem do mesmo recurso sequencial: o julgamento humano.
O autor compara os desenvolvedores ao «GIL» no sistema de Agentes de IA, ou seja, o bloqueio de única thread que limita o throughput final de sistemas concorrentes. Múltiplos Agentes podem operar simultaneamente, mas sempre que entrarem nas fases de julgamento arquitetural, revisão de código e fusão de conflitos, precisam passar novamente pelo cérebro do desenvolvedor. Assim, mais Agentes não significam necessariamente maior produtividade; podem apenas alongar a fila de tarefas pendentes de revisão e levar o desenvolvedor a mudanças de contexto mais frequentes e fadiga cognitiva.
Também é um ponto frequentemente ignorado na atual onda de ferramentas de programação baseadas em IA: a sensação de eficiência nem sempre é sinônimo de produtividade real. Um painel de agentes em execução preenchendo toda a tela pode criar a ilusão de alta produtividade; mas, se os desenvolvedores não compreenderem, revisarem e integrarem verdadeiramente essas alterações, o sistema pode acabar acumulando não produtividade, mas dívida técnica e dívida cognitiva.
Portanto, o que este artigo realmente discute não é "como usar mais Agentes", mas "como redesenhar fluxos de trabalho em torno da atenção humana". Na era dos Agentes, a habilidade-chave não é apenas fazer perguntas ou atribuir tarefas, mas saber quais tarefas podem ser delegadas à máquina para processamento paralelo e quais devem ser mantidas sob julgamento humano; quando deve-se fazer revisões em lote e quando deve-se parar de orquestrar e retomar o foco em uma questão central.
A IA está ampliando a capacidade concorrente de produção de software, mas a atenção humana continua sendo o recurso mais escasso e irreplicável do sistema. Fluxos de trabalho de Agentes verdadeiramente maduros não consistem em delegar todas as tarefas à máquina, mas em projetar cuidadosamente a própria arquitetura de atenção, como se projetasse um sistema de produção.
A seguir está o texto original:
Agora, iniciar mais Agentes de IA tornou-se muito mais fácil. Mas ter mais Agentes rodando simultaneamente não significa que você também se multiplique. Sua largura de banda cognitiva não pode ser paralelizada. Todo o julgamento necessário para orientá-los, avaliar os resultados e combinar ou modificar suas saídas ainda deve passar pelo mesmo processador serial — você mesmo.
O que se chama de "imposto de agendamento" é, na essência, o custo que você paga por esquecer este ponto. E a única solução real é começar a projetar sua própria atenção, como se projetasse qualquer sistema concorrente.
Anteriormente, participei de uma mesa-redonda no Google I/O, discutindo com Richard Seroter, Aja Hammerly e Ciera Jaspan sobre como é a engenharia de software hoje e como ela pode evoluir a seguir. Próximo ao final, Richard nos perguntou: qual é a única coisa que os desenvolvedores devem levar consigo e mudar após ouvir esta discussão?

Eu disse algo que venho refletindo nos últimos meses: sentir-se ocupado não é o mesmo que realmente produzir. Você pode estar executando 20 Agentes ao mesmo tempo e se sentir sobrecarregado, mas isso não significa que entregou o volume de trabalho correspondente a 20 Agentes.
Mais cedo nessa conversa, Richard deu um nome a essa questão. Ele disse: “O que você acabou de descrever é, na verdade, planejamento tributário. Você não consegue gerenciar 20 Agentes com sucesso na sua cabeça.”
Ele está totalmente correto. Quero desmembrar esse conceito de forma mais completa, porque não se trata de um problema de autodisciplina, mas sim de um problema de arquitetura.
Em uma dessas mesas-redondas, disse algo quase por impulso, e isso permaneceu gravado na minha mente: executar vários Agentes não significa que há mais um você no mundo.
Assimetria não contabilizada pelas pessoas
Existe uma assimetria oculta nos fluxos de trabalho do agente.
Iniciar um agente é muito barato. Você só precisa digitar uma tecla ou escrever um prompt. Mas fechar o ciclo do agente não é nada barato. Alguém precisa sempre verificar se os resultados retornados estão corretos e recoordená-los com as alterações feitas por outros agentes.
Essa pessoa é você. E você é apenas um.
No mês passado, eu abordei parte dessa questão em “O Limite do Seu Agente Paralelo”, discutindo principalmente essa ansiedade ambiental: você não sabe qual linha paralela está falhando silenciosamente. Este artigo pretende explorar a estrutura por trás desse custo.
Quando você começa a ver o desenvolvimento de Agentes como um sistema concorrente, percebe que os seres humanos são apenas um componente desse sistema. Um componente serial muito lento.
Você é aquele recurso single-threaded
Se você já escreveu código concorrente, já possui a intuição para entender esse problema. Apenas você usou essa intuição no lugar errado no passado.
Python possui uma Global Interpreter Lock, ou GIL. Você pode criar quantas threads desejar, mas apenas uma thread pode executar bytecode Python por vez, pois todas devem adquirir essa trava primeiro.
Você é o GIL do seu agente de IA.
Eles podem todos ser executados ao mesmo tempo. Mas sempre que seu trabalho exigir compreensão real da arquitetura do sistema ou a resolução de conflitos de merge, será necessário obter essa chave primeiro. E há apenas uma chave, que está em sua posse.
A Lei de Amdahl expressa isso com precisão: o limite de aceleração trazido pela paralelização depende da parte do trabalho que ainda precisa ser executada sequencialmente. Se uma grande fração do seu processo não puder ser paralelizada, independentemente de quantos núcleos você investir, acabará atingindo um limite rígido.
No desenvolvimento de Agentes, essa parte serial é o julgamento.
Iniciar 8 Agentes não acelerará seu tempo de julgamento. Isso apenas tornará a fila de tarefas pendentes de processamento mais longa.
É um fato antigo na engenharia de desempenho, mas muitas pessoas ainda se surpreendem com ele: otimizar partes que não são gargalos não aumenta o throughput geral. Você simplesmente está acumulando mais trabalho pendente antes do gargalo.
O agente otimizado melhora a parte que, na verdade, não era uma restrição. A verdadeira restrição é a etapa de revisão, e o throughput de todo o sistema é exatamente igual ao throughput dessa etapa.
A tributação de organização é a lacuna estrutural entre a capacidade de produção do agente e o que você realmente consegue consolidar. Ela ocorre quando você permite que um recurso single-threaded gerencie um sistema concorrente.
A resistência não resolve limites estruturais
Naquela mesa redonda, eu disse uma frase: nunca me senti tão eficiente com minhas ferramentas quanto agora, mas também nunca estive tão cansado quanto agora.
Ambos os sentimentos são totalmente reais e vêm da mesma causa.
Essa fadiga tem uma fonte muito específica: é a sensação de manter um processador serial operando continuamente em 100% sem qualquer margem de folga.
Cada vez que você olha para trás para um agente que saiu do seu foco, você paga um custo de troca de contexto. Você precisa esvaziar sua mente e recarregar completamente um novo contexto do zero.
A CPU pode realizar isso em microssegundos, mas mesmo assim, os arquitetos evitam alternâncias frequentes. Você leva minutos para fazer isso e nunca consegue recuperar perfeitamente o contexto.
Cinco Agentes não são o mesmo trabalho repetido 5 vezes. São cinco reinicializações em modo de contexto frio, mais um processo cerebral em segundo plano que não para de se preocupar sobre qual Agente você deveria verificar agora.
Você não pode resolver uma limitação estrutural apenas "trabalhando mais". Este imposto sempre terá que ser pago.
Se você tentar resistir, ele acabará aparecendo de outra forma: ou as revisões de código se tornam cada vez mais superficiais, ou você entra em um estado de "rendição cognitiva" — porque formar seu próprio julgamento consome muita atenção, você simplesmente aceita o código escrito pelo Agente.
Ou você paga esse imposto ativamente, ou permite que ele destrua lentamente, nas sombras, sua compreensão do seu próprio sistema.
Projete sua atenção como um sistema de design
Portanto, você deve tratar sua atenção como um recurso escasso e serial.
Você não projetaria um sistema distribuído ignorando completamente gargalos. Então, dê ao seu cérebro o mesmo respeito.
Aqui estão alguns métodos que realmente funcionaram para mim:
Expandir a equipe de Agentes com base na capacidade de revisão, e não com base na capacidade de UI.
Um bom sistema concorrente utiliza mecanismos de backpressure para evitar o crescimento infinito da fila. O produtor deve reduzir a velocidade para corresponder à capacidade de processamento do consumidor.
O número de seus Agentes é o produtor; sua capacidade de revisão é o consumidor. O número correto de Agentes em paralelo deve ser igual ao número de revisões de código que você consegue realizar com atenção. Para a maioria das pessoas, isso geralmente é apenas um pequeno número único.
As ferramentas de IA certamente ficarão felizes em permitir que você inicie 20 agents, mas isso é apenas uma função da interface do usuário e não significa que você realmente tenha capacidade para gerenciá-los.
Classificar tarefas.
Quando Richard me perguntou como lidar com isso, mencionei esse método. Vou dividir a tarefa em duas pilhas.
O primeiro conjunto é um trabalho relativamente independente, que estou disposto a entregar a um Agente que opera em segundo plano na nuvem. Essas tarefas podem ser executadas assincronamente e geralmente exigem apenas minha revisão final.
O segundo grupo são tarefas complexas, cujo trabalho real é justamente julgar. Por exemplo, um bug muito estranho ou um projeto de arquitetura.
O maior erro é tentar paralelizar também as tarefas de segunda categoria. Processar múltiplas tarefas complexas em paralelo não aumenta sua produtividade, mas apenas faz com que o bloqueio seja disputado repetidamente, resultando em piores resultados para todos.
Revisão em massa.
Cada mudança de contexto lhe custa um preço elevado. Sentar-se para revisar os resultados de 4 agents de uma vez é muito mais econômico do que olhar um, fazer outra coisa e depois reiniciar para olhar outro.
Dê ao agente uma coleira mais longa. Deixe o trabalho acumular um pouco, depois processe-os em lotes.
Use esta chave apenas para julgamento.
Não gaste seu cérebro em coisas que a máquina pode verificar sozinha. Deixe o Agente escrever testes que passem ou gerar capturas de tela.
Deixe que eles provem sozinhos aquela parte chata, mas verificável, de 80%. Assim, sua atenção escassa poderá ser dedicada apenas aos 20% que realmente exigem julgamento humano.
Proteja seu tempo de série.
O gargalo exige o seu melhor tempo, não os fragmentos restantes entre as verificações do Agente.
Às vezes, o movimento de alavancagem máxima é simplesmente parar completamente a coreografia: desligue o computador cheio de Agentes, concentre-se apenas em uma única pergunta e mantenha firmemente aquela chave durante todo o processo.
Agendar não é um trabalho real. É apenas o overhead gerado em torno do trabalho.
Aja apontou que a capacidade de arquitetura já se tornou a habilidade mais urgente: você precisa saber quais tarefas são adequadas para serem colocadas em um Agente e quais são muito grandes para ele.
Gostaria de acrescentar um ponto: você também é um componente desse sistema. Sua atenção possui uma capacidade serial conhecida e muito baixa. O sistema ou respeita esse número ou contorna-o reduzindo silenciosamente seus padrões.
Estar ocupado não é o mesmo que ser produtivo
This is very important because this failure mode is nearly invisible to you personally.
Vinte agents em execução dão a sensação de “produtividade em alta”. O painel está cheio, tudo está em movimento. Mas essa sensação já se desconectou da verdadeira integração de código de alta qualidade no branch principal.
Você pode estar extremamente ocupado, mas produzir quase nada. Do ponto de vista interno, os dois são quase idênticos.
Ciera mencionou a pesquisa de Margaret-Anne Storey sobre dívida. Conversamos sobre dívida técnica e também sobre dívida cognitiva.
Sem pagamento da taxa de organização, você acumulará simultaneamente essas duas dívidas.
Você combinou coisas que não leu cuidadosamente. Seu modelo mental do repositório de código está completamente desatualizado. Esses problemas não aparecerão no painel hoje. Eles surgirão quando o sistema falhar em produção — nesse momento, você olha para o sistema e percebe de repente que já não sabe como ele realmente funciona.
Então, a verdadeira conclusão é: iniciar um Agente não é uma habilidade. Qualquer pessoa pode executar 20.
A verdadeira capacidade é projetar sistemas em torno de um recurso serial que não pode ser clonado nem paralelizado.
Este recurso é a sua atenção.
Projete-o como se fosse um componente crítico dependente em um ambiente de produção.
