Usuários do Claude Code aprovam 93% das solicitações — a supervisão está virando uma formalidade

O agente já está na segunda hora de alterações no projeto e pede regularmente permissão para executar mais um comando. Você lê as primeiras solicitações com atenção, depois reconhece formulações familiares e clica no botão quase automaticamente. Em algum momento, entre as operações de rotina, aparece a exclusão de uma branch remota ou uma migração do banco de dados de produção. A autorização foi concedida, mas talvez não tenha havido uma revisão de fato.

Um artigo do Habr sobre fadiga de supervisão cita um indicador da Anthropic: usuários do Claude Code aprovam 93% das solicitações de confirmação. Esse percentual, por si só, não comprova desatenção: a maioria das ações pode realmente ser segura. Mas ele levanta uma pergunta útil para o produto: que erro sua interface consegue impedir se o uso habitual consiste em concordar e seguir em frente?

Por que o botão deixa de proteger

Quem executa uma tarefa constrói aos poucos uma compreensão do que está acontecendo. Quem revisa o agente precisa reconstruir essa compreensão a partir das ações de outro: quais arquivos foram lidos, por que uma ferramenta foi escolhida, o que já foi alterado e quais serão as consequências do próximo comando. Uma janela isolada de confirmação raramente comporta todo esse contexto.

Imagine um agente encarregado de remover uma funcionalidade obsoleta. Ele excluiu o código, ajustou os testes e propõe limpar as branches relacionadas. Para avaliar essa última etapa, não basta ver um comando Git correto. É preciso saber quais branches ainda estão em uso, se há trabalho inacabado de colegas e se a limpeza do repositório remoto fazia parte da tarefa original. A sintaxe do comando resolve muito pouco nesse caso.

O problema de supervisionar a automação é muito anterior aos LLMs. O artigo original recorre à aviação e aos carros autônomos: a observação prolongada reduz a atenção, enquanto intervenções raras exigem uma habilidade difícil de manter sem prática. Esses exemplos ajudam a entender o mecanismo. Eles não permitem transferir taxas de acidentes ou a eficácia de medidas específicas de um setor para outro.

O que mudar no produto e no processo

O primeiro passo é definir os limites de atuação antes de iniciar o agente. Se ele precisa preparar uma correção, o acesso à publicação de versões, aos segredos e ao banco de dados de produção exige uma justificativa separada. Quanto menos consequências ele puder provocar por conta própria, menos será preciso depender da atenção de uma pessoa ao fim de uma sessão longa.

O segundo passo é organizar a revisão em torno de um resultado completo. Para uma alteração de código, isso pode ser um conjunto de mudanças acompanhado dos resultados dos testes, de uma lista dos componentes afetados e de uma indicação explícita das ações fora da cópia local. Assim, quem revisa consegue enxergar a relação entre as etapas. A aprovação em lote, porém, não deve incluir uma operação perigosa sem que isso fique claro: uma migração ou exclusão de dados deve ser apresentada separadamente, com o alvo específico e as consequências esperadas.

O terceiro passo é verificar o resultado com os recursos técnicos disponíveis. O arquivo prometido existe? Ele abre? O conteúdo corresponde à tarefa? As verificações passam? Essas perguntas são especialmente importantes quando uma ferramenta termina com erro, mas o agente, mesmo assim, anuncia o sucesso com confiança. Um resumo bem escrito não comprova que o trabalho foi realizado.

Um classificador automático de ações também pode ajudar. Segundo o relato do Habr, a Anthropic informa que seu classificador deixou passar 17% de 52 casos analisados em que o agente tomou iniciativa excessiva. É uma amostra pequena e específica, não uma estimativa universal de risco. Para a equipe, a implicação é simples: um modelo adicional ainda deixa erros passarem, portanto as restrições de acesso e a verificação das consequências continuam sendo importantes.

Quem deve revisar o agente

Designar o funcionário menos experiente para a supervisão parece uma economia até ficar claro que a avaliação exige entender o próprio trabalho. Para identificar uma migração incorreta, é preciso compreender os dados. Para detectar um resultado fictício, é preciso saber como seria um resultado real.

Por isso, tarefas realizadas sem assistente têm valor prático: ajudam os funcionários a desenvolver e preservar a capacidade de revisar. Também é útil analisar falhas e correções reais: quais erros uma pessoa impediu, de quais informações ela precisava e quais solicitações podem ser retiradas do fluxo de confirmações.

Para os responsáveis pelo produto, a conclusão é concreta: a taxa de aprovação, por si só, diz pouco sobre a qualidade do controle. Para os desenvolvedores, cada solicitação de permissão deve trazer contexto suficiente para uma decisão. Para os fundadores, o tempo de revisão qualificada precisa entrar no custo do trabalho do agente. Caso contrário, é fácil confundir uma execução mais rápida com a obtenção mais rápida de um resultado confiável.