Um agente pode escrever, testar e alterar código em uma velocidade que muda a escala do trabalho de uma equipe. Essa velocidade não elimina a necessidade de decisão. Ela desloca a decisão para antes da execução e para depois do resultado produzido.
Esse deslocamento aparece na pesquisa da Anthropic sobre cerca de 400 mil sessões do Claude Code, analisadas entre outubro de 2025 e abril de 2026. Em uma sessão típica, as pessoas tomam a maior parte das decisões de planejamento, enquanto o agente toma a maior parte das decisões de execução. A pesquisa também relaciona maior experiência no domínio com maior volume de trabalho realizado por instrução.
A consequência para uma equipe não é simplesmente comprar uma ferramenta e medir quantas linhas ela produz. É revisar onde o conhecimento humano entra no ciclo de entrega e quais evidências permitem aceitar o que foi executado.
A velocidade aumenta o custo de uma instrução ruim
Quando uma pessoa implementa uma mudança manualmente, o tempo de execução limita o raio de uma interpretação equivocada. O erro ainda pode ser grande, mas a própria lentidão cria momentos para descobrir que o pedido estava incompleto.
Um agente reduz esse intervalo. Uma instrução vaga pode gerar mudanças em banco, API, interface e testes antes de alguém perceber que a regra de negócio foi entendida de forma errada. A equipe ganha capacidade de execução e perde parte do freio acidental que existia no processo manual.
Por isso, o primeiro trabalho da pessoa que usa o agente é tornar o objetivo verificável. “Atualize o fluxo de cadastro” não informa quais usuários são afetados, que estados são válidos, quais integrações não podem mudar ou como o resultado será aceito. O agente pode preencher as lacunas com uma solução coerente e ainda assim produzir a solução errada.
Uma instrução útil delimita pelo menos quatro coisas:
- o comportamento que deve mudar;
- o comportamento que precisa permanecer;
- os caminhos do sistema que estão autorizados;
- a evidência que demonstra que a mudança funciona.
Essa preparação parece planejamento convencional. A diferença é que agora ela controla uma capacidade de execução muito maior.
Conhecimento de domínio continua sendo multiplicador
A pesquisa da Anthropic encontrou uma relação entre experiência no domínio e sucesso das sessões. O agente preenche lacunas de implementação, mas não substitui o entendimento sobre clientes, contratos, dados históricos e consequências operacionais.
Esse ponto muda a conversa sobre equipes generalistas. Uma pessoa pode atravessar frontend, backend, banco e infraestrutura com auxílio do agente. Isso amplia o alcance de sua atuação, mas não transforma automaticamente conhecimento superficial em julgamento confiável.
O risco aparece quando a organização interpreta a fluência da ferramenta como competência no domínio. Código que compila não prova que uma política foi aplicada corretamente. Um teste verde não prova que a alteração respeita um acordo com outro sistema. Uma interface visualmente correta não prova que um usuário consegue recuperar-se de um erro.
O agente aumenta a capacidade de quem sabe formular o problema e avaliar a resposta. A equipe precisa proteger esse trabalho de avaliação, em vez de tratá-lo como uma etapa menor porque o código foi produzido rapidamente.
O aceite precisa acompanhar a delegação
Delegar a execução não significa delegar o critério de aceite. Cada tipo de mudança precisa de uma evidência proporcional ao risco.
Para uma alteração localizada, testes existentes e uma revisão curta podem bastar. Para uma mudança que atravessa dados e permissões, a equipe precisa verificar migração, compatibilidade, logs, recuperação e acesso fora do cenário feliz. Para uma mudança de produto, o aceite deve incluir o comportamento esperado, a linguagem apresentada e os estados de erro.
Uma política simples ajuda a evitar que todo pull request receba o mesmo tratamento:
Tipo de mudança | Decisão humana indispensável | Evidência mínima |
|---|---|---|
Correção localizada | confirmar escopo e regressões | testes direcionados e diff pequeno |
Regra de negócio | confirmar interpretação do domínio | casos de aceite e testes de comportamento |
Dados ou permissões | confirmar impacto e reversibilidade | migração revisada, logs e plano de recuperação |
Interface crítica | confirmar compreensão e recuperação | estados completos, acessibilidade e teste do fluxo |
O objetivo não é criar uma burocracia para cada uso do agente. É impedir que a velocidade de execução esconda decisões que continuam sendo da equipe.
O que deve ficar no repositório
Se o agente precisa de contexto para decidir bem, esse contexto não pode depender apenas da memória de uma pessoa ou de uma conversa antiga. Convenções do projeto, comandos de validação, limites de acesso, decisões de arquitetura e exemplos de mudanças aceitas devem estar próximos do código que eles explicam.
Isso não significa transformar o repositório em um manual interminável. Registros curtos e atualizados são mais úteis: uma decisão, sua razão, o limite conhecido e a forma de verificar o efeito. Quando uma regra deixa de valer, o registro também precisa ser alterado.
O benefício aparece para humanos e agentes. Uma pessoa nova encontra menos conhecimento tribal. O agente recebe menos espaço para inventar convenções. A revisão pode discutir a decisão atual em vez de reconstruir sua história em cada pull request.
A pergunta para a equipe
Antes de ampliar o uso de agentes, a equipe deveria listar decisões que não podem ser inferidas apenas pelo código: regras comerciais, limites de autoridade, dados sensíveis, integrações frágeis e critérios de sucesso. Em seguida, pode separar execução delegável de julgamento que exige contexto.
Essa separação dá uma medida melhor de maturidade do que contar tarefas geradas por IA. A organização está pronta quando sabe o que pode acelerar, o que precisa observar e qual evidência interrompe a execução.
