Meta-Trabalho Com Agentes: O Que Os Dados Internos Da Anthropic Dizem Sobre Gerir Quem Escreve O Código

Existe uma pergunta que todo tech lead acaba fazendo em algum domingo à noite, olhando a semana que passou: onde foi parar o meu tempo? Não o tempo do time, o meu. A resposta honesta costuma ser incômoda, porque pouca coisa do que ocupa a agenda de quem lidera é escrever código, e boa parte é decidir o que vale a pena escrever, explicar por que, e conferir se o que chegou bate com o que foi pedido. Essa é uma observação genérica sobre o ofício, não o relato de um caso específico, mas ela me ajuda a ler uma notícia recente com o olhar certo.

No dia 16 de outubro, a Anthropic publicou uma pesquisa sobre como o emprego está mudando dentro da própria empresa, assinada por Nathan Wilmers, Regina Catipon, Maxim Massenkoff e Peter McCrory. A maior parte da cobertura que vi foi atrás do número mais barulhento, a queda na proporção de juniores. Eu li o texto procurando outra coisa: o que acontece com a rotina de quem passa o dia dirigindo agentes em vez de digitar código. Foi nessa parte que encontrei os dados que mais me fizeram pensar, porque eles descrevem trabalho de gestão, não de programação.

Preciso dizer o que li. Li o texto da pesquisa publicada no site da Anthropic. Não tenho acesso aos dados brutos, não vi a metodologia além do que o texto descreve, e, no caso de um dos números que vou citar, a espera ociosa nas sessões, o que tenho vem do material de pesquisa que me passaram e que não consegui localizar com a mesma redação no texto que abri; por isso vou tratá-lo com cautela quando chegar a ele. Também não tenho dado do meu time: tudo o que for sobre adaptação a um time pequeno será hipótese, rotulada como tal.

Vou percorrer o desenho da pesquisa e as ressalvas dos próprios autores, depois o que o meta-trabalho significa nas sessões, as instruções permanentes e o registro de decisões, o peso da espera e das reuniões, e por fim o que um time pequeno poderia experimentar. O ângulo de contratação de juniores já tratei em outro post sobre o pipeline de talento, e o do desgaste de quem gere agentes em um texto sobre burnout de tech leads. Aqui o foco é o trabalho em si.

---

O Que A Pesquisa Mede E O Que Ela Não Prova

O desenho, pelo que o texto descreve, compara 192 engenheiros que adotaram agentes com 74 que não adotaram, usando efeitos fixos de pessoa e de mês. Isso quer dizer que cada engenheiro é comparado com ele mesmo em outros momentos, e cada mês é controlado, o que ajuda a separar o efeito da ferramenta de diferenças permanentes entre pessoas ou de fatores que mudam para todo mundo ao mesmo tempo. É um desenho cuidadoso, mas cuidadoso não é o mesmo que causal, e os próprios autores dizem isso.

Os números de volume são os que chamam atenção: os commits por engenheiro estão em torno de cinco vezes o nível de seis meses antes. A razão de horas interativas entre agente e funcionário chegou a 6 para 1 em agosto, e as horas de trabalho de agente passaram as humanas em março de 2026. Eu leio isso como descrição de uma empresa onde o agente já é o principal executor de tarefas de código. Não leio como previsão para o seu time, que provavelmente não tem a mesma infraestrutura, os mesmos modelos de acesso nem a mesma tolerância a erro.

As ressalvas importam tanto quanto os números, e o texto as lista com franqueza. A adoção não foi aleatória: quem começou projetos grandes pode ter adotado as ferramentas para eles, e engenheiros que adotaram agentes totalmente autônomos já estavam numa trajetória de produção mais inclinada do que os que não adotaram. Mais código não significa necessariamente mais impacto, e os autores observam que erros de IA podem ser mais difíceis de perceber que os humanos. Os dados vêm de uma empresa só, e eles mesmos escrevem que muitas práticas de emprego dali não são replicáveis na economia. As conclusões qualitativas se apoiam em 17 entrevistas.

Há ainda uma ressalva sobre a qualidade que eu quero registrar logo. Os proxies escolhidos pela própria empresa, como linhas apagadas depois de 90 dias e reverts, não mostraram diferença mensurável entre o código de agente e o de humano da mesma pessoa, no mesmo mês e diretório. A figura da pesquisa lista também supressões de lint e testes pulados, mas o texto só relata o resultado de remoção e revert. Ao mesmo tempo, proxies medem churn e atrito visíveis; não medem legibilidade, nem o custo de quem terá de entender aquilo daqui a um ano.

Por tudo isso, eu uso a pesquisa como um retrato detalhado de como uma organização muito inclinada a agentes organiza seu trabalho, e não como prova de que o método funciona em qualquer lugar. Serve para formular perguntas melhores sobre o nosso trabalho de gestão.

---

De Digitar Para Dirigir: O Que É Meta-Trabalho Nas Sessões

O dado central para esta discussão é o do meta-trabalho. A pesquisa relata que a parcela das sessões interativas dos funcionários dedicada a gerir ou direcionar agentes passou de cerca de 10% no outono de 2025 para 22% na primavera de 2026. Pelo texto, a maior parte desse trabalho envolve escrever especificações para execuções com vários agentes, fazer um agente revisar a saída de outro e monitorar pipelines. Ou seja, é trabalho que existe em torno do código, e não a escrita do código em si.

Vale pensar no que cada uma dessas três atividades exige. Escrever uma especificação para uma execução com vários agentes é um trabalho de decomposição: quebrar um objetivo em partes que possam andar em paralelo sem se atrapalhar, definir o que é pronto para cada parte e prever onde os resultados vão se encontrar. Mandar um agente revisar outro é um trabalho de desenho de verificação, porque alguém precisa decidir o que o revisor deve procurar e o que ele não precisa repetir. Monitorar pipelines é supervisão: perceber que algo saiu do trilho antes que a saída inteira esteja pronta.

Quem já liderou gente reconhece essas funções: decomposição, critérios de aceite e acompanhamento, o que uma pessoa sênior faz com uma equipe, só que agora com executores que não se cansam. É por isso que acho útil o termo meta-trabalho, apesar de ser um rótulo dos autores e de eu não ter visto a definição operacional completa: ele nomeia a camada acima da execução, que sempre existiu e que passa a ocupar uma fatia mensurável do dia.

A leitura que faço, e é opinião, é que o gargalo de um time com agentes tende a se deslocar do digitar para o dirigir. Quando a execução fica barata, o que escasseia é a clareza sobre o que pedir. Já tratei de uma face desse tema ao escrever sobre mise en place e preparação deliberada no trabalho com agentes: a qualidade do que sai depende muito do que foi arrumado antes de apertar o botão. A pesquisa da Anthropic dá números a essa intuição, embora num ambiente muito particular.

Um cuidado de interpretação: 22% das sessões interativas não é 22% do tempo de trabalho. O texto fala de sessões interativas com o Claude, e boa parte do dia de qualquer pessoa acontece fora delas, em reuniões, leitura, conversas. Também não sei como cada sessão foi classificada como meta-trabalho. Tomo a direção, de 10% para 22%, como sólida o bastante para pensar, e o valor exato como aproximado.

---

Instruções Permanentes E Decisões Em Canais Que Os Agentes Leem

O segundo dado que me prendeu foi o das instruções permanentes. Segundo a pesquisa, o número de instruções escritas para agentes cresceu de algumas centenas em julho de 2025 para cerca de 8.500 um ano depois. Instrução permanente é aquilo que fica registrado uma vez e vale para as sessões seguintes: convenções de código, comandos do projeto, restrições de arquitetura, preferências de revisão. Em ferramentas como o Claude Code, o mecanismo mais conhecido é o arquivo de memória do projeto, descrito na documentação oficial.

O que esse crescimento sugere, e aqui é inferência minha, é que a organização está transformando conhecimento tácito em texto operacional. Em um time só de pessoas, muita coisa vive na cabeça de quem está há mais tempo: por que aquele módulo é assim, qual cliente exige aquele comportamento, o que nunca se deve fazer no banco em produção. Uma pessoa nova absorve isso por convivência, com alguma lentidão. Um agente não convive, ele só lê. Se a regra não está escrita onde ele consegue ler, para ele a regra não existe.

A pesquisa acrescenta uma prática organizacional que me parece o ponto mais transferível de todo o texto: decisões devem ser registradas em canais visíveis aos agentes. Isso muda o critério de onde se decide. Uma decisão tomada numa conversa de corredor, numa chamada sem ata ou numa mensagem privada é invisível para qualquer agente que depois vá trabalhar naquele código. Registrar a decisão em um lugar acessível deixa de ser higiene documental e passa a ser pré-condição para que o trabalho dos agentes siga a direção combinada.

Essa ideia tem um antecessor conhecido no mundo humano, os registros de decisão de arquitetura, descritos em adr.github.io, que existem para que a razão de uma escolha sobreviva à saída de quem a tomou. A diferença que a pesquisa sugere é de público: o registro precisa servir a leitores que consultam tudo, sempre, sem esquecer, e que não perguntam quando algo está ambíguo. Isso favorece textos curtos, específicos e atualizados.

Há um risco que a pesquisa, pelo que li, não discute e que eu levantaria: 8.500 instruções é muita coisa para manter. Instrução permanente envelhece, se contradiz, e uma contradição entre duas delas faz o agente escolher uma sem avisar. Não sei como a Anthropic cuida disso, se há donos, revisão periódica ou limpeza. Em um time pequeno, o equivalente seria tratar cada instrução como código: com responsável, com revisão e com data para ser reavaliada. Sem isso, o conjunto tende a virar um passivo.

---

Oitenta Por Cento De Espera E O Custo Das Reuniões

O terceiro bloco de dados trata de tempo, e aqui preciso ser mais cuidadoso. O material de pesquisa que recebi indica que cerca de 80% do tempo de uma sessão interativa é espera ociosa, o agente aguardando input humano. Não consegui confirmar essa cifra na redação do texto publicado que abri, que resume outros achados. Por isso a trato como informação a verificar na fonte, e não como fato estabelecido; se estiver correta, ela diz algo importante, e vou raciocinar a partir dela de forma condicional.

Se de fato a maior parte do tempo da sessão é o agente esperando, então o limite de produtividade não está na velocidade do agente, mas na disponibilidade de quem decide. O agente fica parado porque precisa de uma resposta, uma aprovação, um esclarecimento. Isso reforça a leitura do gargalo deslocado: o recurso escasso é a atenção de quem pode dizer sim, não ou "é assim". Quem lidera um time com agentes tem, portanto, um problema de fila, e problemas de fila se resolvem por duas vias: reduzir o que chega à fila ou aumentar a capacidade de atendimento.

Reduzir o que chega à fila é o papel das instruções permanentes e das decisões registradas, que vimos na seção anterior. Cada pergunta que o agente consegue responder lendo um documento é uma pergunta que não ocupa um humano. Aumentar a capacidade de atendimento é mais difícil, e envolve ter mais gente com autoridade para decidir sobre cada tipo de coisa, o que é uma questão de desenho de responsabilidades. A pesquisa, nesse ponto, descreve que as avaliações de desempenho na Anthropic passaram a enfatizar autonomia e julgamento, o que é coerente com a necessidade de ter pessoas que decidem sem escalar tudo.

O outro dado de tempo é sobre reuniões. A pesquisa relata que o funcionário mediano gasta cerca de 20% mais tempo em reuniões do que um ano antes, e entre os contribuidores individuais técnicos o aumento é de cerca de 16%. Os autores atribuem isso em parte ao crescimento da empresa e em parte à coordenação presencial que o trabalho conduzido por agentes ainda exige. Não dá para separar quanto vem de cada fator com o que está publicado, e eu evitaria tirar uma conclusão forte daqui.

Mas o sentido da observação é interessante mesmo com essa ressalva. Parece contraintuitivo que o trabalho de agentes aumente a coordenação entre pessoas, já que a expectativa popular é a de times menores e mais silenciosos. Meu palpite, e é só palpite, é que quando a execução acelera, os desencontros de direção também aceleram: dois engenheiros dirigindo agentes em frentes que colidem produzem o conflito mais rápido do que produziriam digitando. Alinhar direção antes passa a custar menos do que desfazer depois, e alinhar direção costuma acontecer em conversa.

Isso conversa com o que escrevi sobre revisão por intenção no caso do Scion: quando o volume de código passa do que cabe em leitura linha a linha, o ponto de controle sobe de nível, da linha para a intenção. A diferença é que o Scion trata a verificação do que foi produzido, e os dados desta pesquisa tratam do alinhamento do que será produzido. Os dois movimentos apontam para o mesmo lugar: mais atenção humana na entrada e na saída, menos no miolo.

---

O Que Um Time Pequeno Poderia Adaptar

Esta seção é hipótese. Não apliquei nada disso, não sei o que um time encontraria, e a pesquisa descreve uma empresa de porte e infraestrutura muito diferentes dos de um time de seis ou oito pessoas. Dito isso, os mecanismos descritos são portáveis, e dá para imaginar experimentos baratos. O ponto de partida seria medir o meta-trabalho do próprio time antes de mudar qualquer coisa, porque sem linha de base não há como saber se a mudança ajudou.

A primeira hipótese diz respeito às instruções permanentes. Imagine um time que, durante um mês, registra toda vez que precisa repetir uma explicação a um agente que já deu a mesma explicação antes. Cada repetição é candidata a virar uma instrução escrita no repositório. O ganho esperado é reduzir perguntas e correções recorrentes; o custo é manter o texto. Um critério simples de poda seria revisar o conjunto a cada trimestre e remover o que ninguém consultou ou o que o código já deixou óbvio.

A segunda hipótese é sobre onde decisões são registradas. Um cenário comum seria o time decidir algo numa chamada e a decisão existir apenas na memória de quem estava lá. Uma regra de trabalho possível é que nenhuma decisão que afete código valha até estar escrita num lugar que os agentes leiam, por exemplo num documento curto de decisão no repositório. A parte difícil não é a ferramenta, é o hábito, e o hábito se constrói quando quem lidera cobra e dá o exemplo. O que a gente pode medir é quantas vezes um agente tomou uma direção contrária a uma decisão que existia só de forma oral.

A terceira hipótese trata da fila. Se a maior parte do tempo de uma sessão for espera por humano, vale mapear quais perguntas os agentes mais fazem e quem as responde. Pode haver perguntas que só uma pessoa do time consegue responder, e esse é um gargalo de pessoa, não de ferramenta. Distribuir autoridade de decisão por área, com limites claros do que cada pessoa pode aprovar sozinha, é uma resposta organizacional. Aqui os dados da Anthropic sobre autonomia e julgamento nas avaliações sugerem que a empresa pensou nisso, embora eu não saiba os detalhes.

A quarta hipótese é cuidar da atenção de quem dirige. O meta-trabalho é cognitivamente caro, porque exige alternar entre contextos e decidir com pouco tempo, tema próximo ao do estudo de 1.222 participantes sobre uso de IA em times de desenvolvimento. Se o dia de uma pessoa virar uma sequência de aprovações curtas, a qualidade das decisões tende a cair no fim do dia. Uma proteção possível seria reservar blocos para escrever especificações com calma e agrupar as aprovações em horários fixos, em vez de interromper o fluxo a cada pergunta do agente.

Por fim, uma ressalva sobre como não usar nada disso. Evitaria transformar o percentual de meta-trabalho em meta ou em medida de desempenho de pessoas, pelo mesmo motivo de sempre: o número deixa de informar quando vira alvo. Tampouco trataria os resultados da Anthropic como meta para um time: ela fabrica os modelos, e os próprios autores avisam que suas práticas não são replicáveis em geral.

---

Conclusão

O que mais me chamou a atenção na pesquisa não foi o multiplicador de commits, que é o número que todo mundo cita, e sim o que ele revela sobre o trabalho de quem fica. Mais de um quinto das sessões interativas dedicado a especificar, revisar agentes com agentes e acompanhar pipelines descreve uma função que se parece muito com a de quem lidera, só que exercida por quase todo mundo. Se isso se confirmar fora da Anthropic, a habilidade que mais pesa deixa de ser escrever rápido e passa a ser pedir bem, decidir bem e registrar bem.

Ao mesmo tempo, sou cético quanto a generalizar. A adoção não foi aleatória, o que se mede é produção e não impacto, o padrão de juniores é descritivo, os proxies de qualidade foram escolhidos pela empresa e as conclusões qualitativas vêm de 17 entrevistas. E o dado de espera ociosa, que seria o mais útil para pensar em gestão, eu não consegui conferir na redação do texto publicado. Se você for citá-lo, vá à fonte antes. A direção geral me parece plausível; o detalhe, ainda não está confirmado por mim.

Fico com uma pergunta que não sei fechar. Se o gargalo é mesmo a atenção de quem decide, qual é o limite de quantos agentes uma pessoa consegue dirigir sem que a qualidade das decisões caia? A pesquisa não responde, e a literatura de gestão de pessoas, que fala em limites de abrangência de controle, pode não se aplicar a executores que nunca se cansam mas que dependem inteiramente do que está escrito. Acho que só times reais, medindo com honestidade por tempo suficiente, vão dizer. Até lá, o mais barato que consigo propor é olhar para a própria semana e perguntar quanto dela foi dirigir e quanto foi esperar ser perguntado.

Fontes:

• Anthropic — How employment is changing at Anthropic
• Anthropic — Building effective agents
• Claude Code — Memory (documentação oficial)
• Architectural Decision Records (adr.github.io)
• DORA — pesquisa e métricas de entrega de software