Um agente trabalhou sozinho por 40 minutos. Quando terminou, a revisão e as correções consumiram outros 20. Em outra tentativa, dez minutos de interação, com duas mudanças de rumo durante a execução, produziram um resultado aceitável. O primeiro agente exibiu mais autonomia. O segundo colocou a entrega pronta na mão de alguém cinquenta minutos antes.
Essa diferença parece óbvia quando os dois tempos estão na mesma frase. Ela desaparece com facilidade em dashboards que registram duração da sessão, número de tool calls, linhas alteradas ou minutos sem intervenção humana. Essas medidas descrevem o comportamento do sistema. Nenhuma garante que o trabalho foi aceito.
Para gerir coding agents, eu usaria uma medida mais simples: tempo entre o início da tarefa e a aceitação de um resultado correto. Revisão, espera, retrabalho e tempo gasto para entender a mudança entram na conta.
Autonomia é uma propriedade do processo
Autonomia responde por quanto tempo o agente consegue escolher ações sem pedir ajuda. Produtividade responde por quanto esforço foi necessário para atingir um resultado útil. Uma execução longa pode ser produtiva quando resolve uma tarefa ampla e verificável. Também pode apenas acumular decisões erradas antes de alguém olhar.
O custo cresce de forma assimétrica. Uma correção de rumo no quinto minuto pode exigir uma frase. A mesma correção depois de 40 minutos pode envolver desfazer arquivos, reconstruir contexto, descobrir suposições espalhadas e separar código aproveitável de código convincente.
Isso muda o papel da interação. Interromper cedo deixa de ser sinal de incapacidade quando o checkpoint está colocado numa decisão cara de reverter. A pergunta útil passa a ser onde a supervisão reduz mais retrabalho do que acrescenta espera.
Um fluxo pode liberar leitura, pesquisa, testes e alterações reversíveis, mas parar antes de escolher uma arquitetura, apagar dados ou publicar. Outro pode exigir aprovação depois de cada comando e perder todo o ganho. O nível certo depende do custo do erro e da força da verificação disponível.
O harness de seis horas mostra uma troca, não um vencedor
Em um experimento publicado pela Anthropic, um agente solo levou 20 minutos e custou US$ 9 para construir um editor de jogos. O harness com planner, generator e evaluator consumiu seis horas e US$ 200. A versão mais cara tinha mais recursos, melhor interface e um jogo funcional; a versão solo parecia adequada à primeira vista, mas quebrou durante o uso.
Comparar só duração e custo favoreceria o agente solo. Comparar só qualidade favoreceria o harness. Há ainda uma diferença de escopo: o planner transformou o mesmo pedido curto em uma especificação de 16 funcionalidades distribuídas por dez sprints. O experimento não isola uma disputa limpa entre duas maneiras de entregar o mesmo produto.
Essa ressalva é útil para quem mede times. Se um agente expande a tarefa e recebe nota por quantidade de artefatos, o indicador pode premiar trabalho que ninguém solicitou. Se a avaliação ignora comportamento real, pode aceitar uma interface bonita com a função principal quebrada.
A própria Anthropic descreve agentes como uma troca de latência e custo por desempenho e recomenda começar pela solução mais simples, aumentando a complexidade quando ela demonstra ganho. O conselho vale para o harness e para a tarefa individual: acrescente autonomia onde ela supera uma alternativa mais curta sob a mesma barra de aceite.
O cronômetro precisa incluir quem revisa
Eu registraria quatro intervalos, mesmo que a ferramenta exponha apenas um deles:
- tempo de execução do agente;
- tempo de interação humana durante a execução;
- tempo de revisão e correção depois da entrega;
- espera até a validação poder começar.
Somados, eles formam o tempo até o aceite. Separados, explicam onde mexer. Revisão longa pode indicar diff grande demais, contexto insuficiente ou testes fracos. Muita interação pode revelar uma tarefa mal delimitada ou um ambiente que não oferece feedback ao agente. Espera pode ser simples disputa por CI.
O aceite também precisa ser observável. "Parece bom" não serve para uma migração, uma regra de preço ou um fluxo acessível. O critério pode combinar testes automatizados, navegação real, comparação de saída e revisão de uma pessoa responsável pelo domínio. Quanto mais caro o erro, mais forte deve ser a evidência.
Esse desenho evita outra armadilha: usar confiança percebida como medida de velocidade. Em um estudo controlado da METR, 16 desenvolvedores experientes concluíram 246 tarefas em projetos open source que conheciam havia anos. Com ferramentas de IA do início de 2025, levaram 19% mais tempo, embora acreditassem ter acelerado o trabalho. É um resultado restrito àquela amostra, àquelas tarefas e àquela geração de ferramentas.
A METR tentou atualizar o estudo com ferramentas posteriores, mas informou em fevereiro de 2026 que seleção de participantes e problemas de medição enfraqueciam as conclusões. Os dados sugeriam melhora, sem sustentar uma estimativa confiável do tamanho do ganho. A limitação reforça o ponto operacional: percepção, benchmark e produção medem coisas diferentes.
Autonomia cresce depois da verificação
Um caminho prático é ampliar o raio do agente por classe de tarefa. Primeiro vêm mudanças pequenas, reversíveis e cobertas por testes. Depois, tarefas maiores com checkpoints automáticos confiáveis. Execuções longas entram quando o ambiente consegue detectar desvio sem depender de uma revisão arqueológica no fim.
Não vejo valor em impor uma duração máxima universal. Dez minutos podem ser excessivos para renomear uma variável e insuficientes para investigar uma regressão. Eu colocaria limites em tamanho do diff, áreas sensíveis, custo acumulado e falta de evidência. O cronômetro continua importante, só não trabalha sozinho.
Se uma sessão de 40 minutos pede mais 20 para ficar correta, o dado interessante está nos 60. A próxima melhoria pode ser um teste melhor, um checkpoint antecipado ou uma tarefa menor. Aumentar o tempo sem intervenção só repetiria o trecho que já saiu caro.
