Gerenciar Agentes De IA Também Cansa: O Burnout Que Ninguém Está Medindo

Essa semana esbarrei num texto de Brian Fox, CTO da Sonatype, publicado na Fast Company, com um argumento que não larguei a cabeça por dois dias: gerenciar agentes de IA também cansa, e ninguém está medindo isso direito. A tese dele é simples de enunciar e incômoda de aceitar — revisar trabalho, corrigir direção, manter contexto e absorver ambiguidade continuam sendo tarefas de gestão, mesmo quando o "time" que você supervisiona é feito de software rodando em paralelo, sem intervalo de almoço e sem fim de expediente.

Nos últimos meses, boa parte da conversa sobre produtividade em times de engenharia migrou de "quanto código o agente gera" para "quantos agentes um humano consegue supervisionar ao mesmo tempo". É uma pergunta que parece de capacidade técnica — quantos processos cabem na tela, quantos terminais abertos, quantas branches em paralelo — mas na prática é uma pergunta de gestão disfarçada de engenharia. E gestão, historicamente, é uma das atividades que mais desgasta quem a exerce. Só que agora esse desgaste vem embrulhado num discurso de eficiência que dificulta até nomear o problema em voz alta, porque parece ingratidão reclamar de cansaço numa configuração que, no papel, entrega mais.

Um cenário que tenho ouvido descrito por mais de um tech lead nas últimas semanas ilustra bem a mecânica — e deixo claro que é cenário hipotético, não relato de caso específico que eu tenha acompanhado de perto. Imagine alguém que mantém quatro ou cinco agentes rodando ao mesmo tempo: um revisando pull requests, outro escrevendo testes, outro investigando um bug antigo, outro rascunhando documentação de uma API nova. Cada um interrompe o fluxo de trabalho dessa pessoa em momentos diferentes, com perguntas diferentes, numa urgência que parece sempre alta porque o agente acabou de produzir algo e está, tecnicamente, esperando resposta. No fim do dia, essa pessoa não escreveu uma linha de código — mas está tão exausta quanto se tivesse escrito o dobro do que escrevia sozinha há um ano.

Neste post eu quero puxar esse fio: por que a supervisão de agentes em paralelo é, estruturalmente, trabalho de gestão; por que ela cansa de um jeito diferente da gestão de pessoas; o que os números que já existem sobre fadiga de IA no trabalho sugerem sobre a escala do problema; e que ajustes práticos já aparecem na literatura para lidar com isso, antes que o time inteiro naturalize esse tipo de exaustão como o preço normal de trabalhar com IA.

---

Gerenciar Agentes Ainda É Gerenciar

O ponto de partida do argumento de Fox é quase óbvio quando dito em voz alta, e talvez seja exatamente por isso que ele passou despercebido por tanto tempo: "managing agents is still management". Trocar pessoas por agentes de IA na ponta de execução não elimina o trabalho de gestão — só troca quem está do outro lado dele. Alguém ainda precisa definir o escopo da tarefa, decidir se o resultado está bom o suficiente para seguir adiante, identificar quando o agente saiu dos trilhos e corrigir a rota, e manter na cabeça o contexto de tudo que está em andamento para que as peças se encaixem no fim.

O que muda, e muda bastante, é o ritmo dessa gestão. Gerenciar uma pessoa tem uma cadência natural: reunião de alinhamento, tempo de execução, checkpoint, revisão. Existem pausas embutidas no processo porque a pessoa do outro lado também precisa de tempo para pensar, testar, tomar café, dormir. Gerenciar um agente de IA remove boa parte dessas pausas — o agente entrega rápido, às vezes rápido demais para o julgamento humano acompanhar no mesmo ritmo, e a expectativa implícita da ferramenta é que você também responda rápido, porque manter o agente esperando é visto como desperdício da velocidade que você pagou para ter.

Isso cria uma assimetria interessante. Numa equipe de pessoas, o gestor absorve ambiguidade, mas num ritmo que o cérebro humano tolera razoavelmente bem, porque a interação é bidirecional — você espera resposta, mas também é esperado. Numa equipe de agentes, o humano é o único ponto do sistema que ainda opera em tempo humano. Tudo ao redor dele acelerou; o julgamento que decide se o output serve não acelerou junto. É esse descompasso, mais do que o volume de trabalho em si, que ajuda a explicar por que o cansaço aparece mesmo quando a métrica de produtividade sobe.

Vale registrar que essa forma de trabalho tem paralelo direto com o que já discuti em squads de agentes com humano no loop: o desenho técnico dessas squads geralmente assume que o humano intervém em pontos específicos, previsíveis, e não em qualquer momento aleatório do processo. Na prática, quando vários agentes rodam soltos sem esse desenho deliberado, o humano vira o ponto de intervenção constante — e é exatamente aí que a gestão informal, não planejada, começa a cobrar seu preço em forma de fadiga.

---

O Mecanismo: Fragmentação De Atenção E Ausência De Latência

Se gerenciar agentes ainda é gestão, por que cansa mais do que gerenciar pessoas? A resposta de Fox passa por dois mecanismos que vale separar, porque cada um pede uma solução diferente. O primeiro é a fragmentação de atenção. Um agente que acabou de gerar um patch, terminar uma investigação ou levantar uma dúvida é, segundo o argumento, mais difícil de ignorar do que uma notificação do Slack. A notificação do Slack pode esperar porque a pessoa do outro lado sabe que você está ocupado. O output do agente não espera — ele fica ali, pronto, como uma tarefa concluída que só precisa da sua aprovação para seguir adiante, e cada minuto que ele fica parado parece desperdício direto de throughput.

Com múltiplos agentes rodando em paralelo, essa pressão se multiplica. Não é uma notificação por vez — são três, quatro, cinco fluxos concorrentes, cada um pedindo uma microdecisão: aprovar, corrigir, descartar, aprofundar. Cada microdecisão sozinha é trivial. A soma delas ao longo de um dia é uma carga cognitiva de trocar de contexto continuamente, e trocar de contexto tem custo mensurável — o cérebro não retoma o fio de onde parou, precisa reconstruir parte do raciocínio a cada troca. É o mesmo problema de fadiga de ferramentas que aparece em levantamentos recentes sobre uso de IA no trabalho, só que aplicado ao ato de supervisionar, não ao de operar uma ferramenta isolada.

O segundo mecanismo é a ausência de latência natural. Numa relação de trabalho entre humanos, o tempo de resposta do outro lado impõe um ritmo de recuperação, mesmo que ninguém o planeje conscientemente. Você delega uma tarefa, a pessoa leva um dia para entregar, esse dia é, para você, tempo livre daquele item específico. Com agentes, essa latência desaparece ou encolhe para minutos. O resultado é que o cérebro nunca sai do estado de "isso pode estar pronto agora", porque tecnicamente pode. Fox usa uma metáfora direta para isso: rodar agentes de IA seria como ouvir podcast a 2x — o conteúdo continua inteligível, o processo é mais rápido, mas o cérebro esquenta. Na tradução dele para o vocabulário de burnout, "a velha metáfora era queimar a vela nos dois lados; o trabalho agêntico acende os dois lados e alguns pontos do meio".

O que essa combinação produz, na prática, é um tipo de exaustão que não aparece nos sinais tradicionais de sobrecarga. Ninguém está trabalhando até meia-noite, nem tem a agenda lotada de reunião atrás de reunião. O cansaço vem de outro lugar: da quantidade de fluxos automatizados que uma única pessoa segura na cabeça ao mesmo tempo, cada um pedindo um pedaço de atenção que nunca chega a zero. De fora, o sistema parece mais saudável — mais código gerado, mais tickets fechados. De perto, o dia de quem está no meio disso é uma sala cheia de pensamentos inacabados, nenhum urgente sozinho, todos juntos pesados. É um dos motivos pelos quais escrevi sobre a diferença entre orquestrar poucos subagentes especializados com modelos mais leves e simplesmente multiplicar fluxos paralelos até o limite técnico da ferramenta: o limite técnico e o limite humano de supervisão raramente coincidem, e o segundo costuma ser bem mais baixo.

---

O Que Os Números Já Mostram

A parte frustrante desse tema é que ele ainda não tem uma métrica própria e consolidada — não existe, até onde encontrei, um "índice de fadiga de supervisão de agentes" com metodologia madura. O que existe é um conjunto mais amplo de dados sobre fadiga de IA no trabalho, que dá pistas fortes mesmo sem medir o fenômeno específico de gerenciar vários agentes em paralelo. Um levantamento da Shibumi, publicado em março de 2026, reúne números de McKinsey, Harvard Business Review e Gallup que desenham um quadro pouco animador.

O dado que mais chama atenção é que 88% dos usuários pesados de IA relatam aumento na sensação de burnout, segundo pesquisa citada da Harvard Business Review de 2026. Isso sugere que o problema não é hipotético nem restrito a quem supervisiona múltiplos agentes — é mais amplo, atinge quem usa IA intensamente sob qualquer formato. Ao mesmo tempo, 95% das empresas não conseguem enxergar retorno mensurável sobre o investimento em IA, segundo dados agregados de McKinsey e Harvard Business Review — o que a própria Shibumi chama de "paradoxo da produtividade": gasto recorde, resultado que não aparece na métrica que deveria justificá-lo.

Alguns números específicos de desenvolvimento de software reforçam esse paradoxo. Em determinados papéis, trabalhadores levaram 19% mais tempo para completar tarefas usando assistentes de código de IA, segundo reportagem da Business Insider de 2025 citada no levantamento. E 77% dos funcionários, segundo a Inc. Magazine, acham que a IA prejudicou sua própria produtividade — um número que contradiz frontalmente a narrativa de ganho de eficiência que justifica boa parte dos investimentos em ferramentas agênticas. Some a isso a fadiga de ferramentas em geral: trabalhadores perdem em média 51 minutos por semana trocando de aplicativo até cem vezes por dia, o que soma 44 horas por ano — e é fácil imaginar como supervisionar vários agentes simultâneos, cada um numa interface ou aba diferente, alimenta exatamente esse tipo de perda.

Há ainda um ângulo organizacional que merece registro. Só 9% dos funcionários se sentem "muito confortáveis" usando IA no trabalho, segundo a Gallup de 2026, e apenas 26% acham que a própria empresa tem um plano claro de implementação de IA. Três em cada dez trabalhadores dizem que a IA aumentou sua carga de trabalho, segundo a Yahoo Finance. E a Gartner, citada via Forbes, projeta que mais de 40% dos projetos de IA agêntica serão cancelados até 2027 — número que sugere que parte desses projetos é abandonada não por falha técnica do modelo, mas por um custo humano de operação que ninguém precificou na hora de aprovar o investimento. É um cenário que se conecta com o que já escrevi sobre a lacuna de governança que cerca agentes rodando em produção sem supervisão formal: falta de medição de carga cognitiva é mais uma faceta da mesma lacuna, só que voltada para dentro do time, não para auditoria externa.

Há também um dado mais recente e mais específico sobre a própria função de gestão técnica. O Engineering Leadership Report 2026, da LeadDev, encontrou que 37% dos líderes de engenharia fazem hoje mais trabalho técnico hands-on do que em 2025 — entre engineering managers especificamente, a fatia subiu de 20% para 35% no mesmo período. Isso não é sobre agentes diretamente, mas ajuda a montar o quadro completo: o cargo de gestão técnica já estava absorvendo mais trabalho de execução antes mesmo de somar a carga de supervisionar agentes rodando em paralelo. Um artigo publicado na Harvard Business Review em fevereiro de 2026 resume esse acúmulo numa frase direta — a IA não reduz o trabalho, ela intensifica — argumentando que a tecnologia expandiu o escopo de tarefas e esticou a jornada para mais horas do dia, em vez de liberar tempo como prometido.

---

Um Dia Na Vida De Quem Opera Vários Agentes

Vale montar um exemplo hipotético mais detalhado para tornar esse mecanismo palpável, porque em abstrato ele soa menos grave do que é na prática. Imagine um tech lead que começa o dia com três agentes já em execução de tarefas deixadas rodando durante a madrugada: um terminou de migrar um módulo de autenticação e está esperando revisão, outro travou numa dependência que não conseguiu resolver sozinho e precisa de uma decisão, o terceiro gerou um conjunto de testes que parecem corretos mas cobrem menos casos do que deveriam. Antes mesmo do primeiro café, essa pessoa já tomou três decisões de escopo diferente, cada uma exigindo reconstruir mentalmente o contexto de um projeto distinto.

Ao longo da manhã, ela abre mais dois agentes — um para investigar uma regressão de performance reportada por um cliente, outro para atualizar a documentação de um endpoint que mudou na semana anterior. Agora são cinco fluxos concorrentes. Nenhum, isoladamente, exige mais do que quinze minutos de atenção real. Mas os cinco juntos disputam a mesma janela de atenção o dia inteiro, entrando e saindo de prioridade conforme cada agente termina uma etapa e sinaliza que está esperando. Não existe, nesse dia, o equivalente a "a pessoa está em reunião, não pode responder agora" — o agente não tem essa noção social, e o hábito de responder rápido para não deixá-lo parado se instala sem que ninguém decida conscientemente adotá-lo.

No fim da tarde, essa pessoa provavelmente vai concluir, olhando para os números, que foi um dia produtivo: cinco tarefas avançaram, uma migração foi concluída, um bug foi identificado. O que não aparece em nenhum desses números é que ela passou o dia inteiro em modo de interrupção constante, sem um bloco sequer de trabalho profundo, tomando dezenas de microdecisões de baixo risco individual e alto custo acumulado. É esse descompasso entre o que a métrica de output mostra e a experiência subjetiva de quem operou aquele dia que Fox chama, no fundo, de burnout que ninguém está medindo — porque as métricas que a empresa acompanha não foram desenhadas para capturar esse tipo de custo.

Esse exemplo também ajuda a entender por que times que adotam planejamento hierárquico com agentes profundos relatam, informalmente, menos desse tipo de fadiga do que times que apenas multiplicam agentes independentes sem hierarquia entre eles. Quando existe uma camada de planejamento que agrupa subtarefas antes de chegar ao humano, o número de interrupções que de fato exigem julgamento humano cai — não porque o trabalho subjacente diminua, mas porque parte da fragmentação é absorvida antes de chegar à pessoa no topo da cadeia.

---

O Que Fazer Diferente: Limites, Lotes E Papéis Separados

A parte mais útil do texto de Fox, para quem lidera time técnico, não é o diagnóstico — é o conjunto de ajustes práticos que ele sugere para reduzir esse custo sem abrir mão do ganho real que agentes de IA trazem. Nenhum deles é revolucionário isoladamente, mas juntos formam um desenho de trabalho bem diferente do "deixa quantos agentes rodando quiser e responde conforme aparece", que é o padrão default de quem começa a usar essas ferramentas sem pensar no processo ao redor.

O primeiro ajuste é limitar a concorrência de agentes deliberadamente, em vez de deixar o limite ser puramente técnico — quantos a ferramenta permite rodar ao mesmo tempo. Definir, como política de time, um número máximo de fluxos simultâneos por pessoa transforma uma decisão hoje implícita e individual numa decisão explícita e coletiva, o que já ajuda a nomear o problema antes que ele vire hábito naturalizado. O segundo é criar ciclos de revisão em lote: em vez de responder a cada agente no momento em que termina, definir janelas específicas do dia para revisar output acumulado. Isso recupera parte da latência natural que desapareceu, e devolve blocos de tempo protegidos entre uma revisão e outra.

O terceiro ajuste, mais estrutural, é separar criação, revisão e integração entre pessoas diferentes quando o tamanho do time permite. Concentrar as três funções numa única pessoa multiplica a carga cognitiva por três a cada ciclo; distribuí-las também distribui o desgaste, e cria pontos de verificação independentes que tendem a pegar erro que uma pessoa sobrecarregada deixaria passar. O quarto é proteger tempo de trabalho profundo — blocos sem nenhum agente rodando, dedicados a arquitetura, decisão de produto ou qualquer trabalho que exija concentração contínua.

O quinto ajuste, talvez o mais difícil porque exige mudar o que a empresa mede, é acompanhar carga cognitiva junto com velocidade de entrega. Já escrevi sobre como as métricas DORA continuam sendo uma âncora honesta para medir produtividade real em times que usam IA, justamente porque olham para retrabalho e estabilidade, não só volume de output. O mesmo raciocínio se aplica aqui: uma organização que só acompanha código gerado ou tickets fechados está cega para o custo humano que sustenta esses números, e vai continuar tratando o cansaço de quem supervisiona agentes como reclamação individual, não sinal de processo mal desenhado.

Nenhum desses cinco ajustes elimina o trabalho de gestão que a supervisão de agentes exige — e não deveria, porque parte desse trabalho é o que garante que o output do agente não vá para produção sem julgamento humano de fato aplicado. O que eles fazem é redistribuir esse trabalho no tempo e entre pessoas, aproximando-o da cadência sustentável que a gestão de pessoas desenvolveu ao longo de décadas, em vez de deixar cada tech lead reinventar sozinho, sob pressão, um modelo de sustentabilidade que a área ainda não formalizou.

---

Conclusão

Não tenho uma resposta fechada para quanto desse burnout é passageiro — o preço de uma fase de adaptação que se resolve conforme times amadurecem processo ao redor de agentes — e quanto é estrutural, um custo permanente de um jeito de trabalhar que cresce em adoção mais rápido do que em compreensão dos efeitos colaterais. A honestidade que cabe aqui é admitir que os números disponíveis, por mais reveladores que sejam, ainda não medem exatamente o fenômeno que Fox descreve. Medem fadiga de IA em geral, produtividade que não aparece, desconforto declarado. Não medem o custo específico de segurar cinco fluxos automatizados na cabeça o dia inteiro.

O que dá para afirmar com mais segurança é que o vocabulário de gestão que times de engenharia desenvolveram ao longo de anos — cadência de revisão, limite de work in progress, separação de papéis, proteção de tempo de foco — não desapareceu quando o "time" passou a incluir agentes de IA. Ele só ficou temporariamente invisível, porque a narrativa dominante trata velocidade como único eixo que importa, e cansaço de quem supervisiona como detalhe que a métrica não precisa carregar. Recuperar esse vocabulário e aplicá-lo deliberadamente à supervisão de agentes parece o passo mais concreto disponível agora, mesmo sem métrica madura para validar o quanto ele ajuda.

Fica, para quem lidera time técnico hoje, uma pergunta mais incômoda do que confortável: se a produtividade do dashboard depende de alguém segurar, sozinho, a fragmentação de atenção de vários fluxos automatizados ao mesmo tempo, essa produtividade é sustentável ou é só um custo que ainda não apareceu na conta certa? Não tenho como responder isso de forma definitiva. Mas acho que é a pergunta que qualquer time expandindo o uso de agentes em paralelo deveria estar fazendo agora, antes que o cansaço vire estatística de rotatividade em vez de ajuste de processo.

Fontes:

• Fast Company — The coming burnout from managing AI agents
• Shibumi — AI Fatigue Statistics 2026
• LeadDev — Engineering managers are back in the codebase
• Harvard Business Review — AI Doesn't Reduce Work—It Intensifies It