Claude Code em produção: o guia de trabalho real

O que separa o agente que impressiona na demo do agente que aguenta seu projeto é a infraestrutura de contexto que você monta em volta dele: cinco camadas que quase ninguém monta, porque nenhum tutorial de instalação menciona.

Sabemos disso porque os dois estudos mais sérios já feitos sobre agentes de código chegaram a conclusões opostas. Um ensaio controlado randomizado da METR mediu desenvolvedores experientes 19% mais lentos com assistente de IA. Um estudo da Microsoft com dezenas de milhares de engenheiros mediu adotantes de CLI agêntica com 24% mais pull requests aprovados. Os dois estão certos. O que muda entre eles é o ano, a ferramenta e, principalmente, o que existia em volta do agente.

Este guia é o mapa dessas cinco camadas, com os números oficiais de custo e as armadilhas que aparecem quando você sai do exemplo e entra no repositório de verdade.

Porque a demo tem contexto pequeno, verificável e recém-criado. Seu projeto tem oito anos de decisões acumuladas, três convenções conflitantes e um arquivo de 4.000 linhas que ninguém entende inteiro.

O agente não fica pior. O contexto fica.

Vale olhar os dois estudos com atenção, porque a leitura preguiçosa deles produz as duas narrativas erradas que circulam por aí — a de que agente é milagre e a de que agente é ilusão.

O que a METR realmente mediu

Em julho de 2025, a METR publicou um ensaio controlado randomizado com 16 desenvolvedores experientes de projetos open source, cobrindo 246 tarefas reais de cerca de duas horas cada. O resultado: quando podiam usar IA, os desenvolvedores levavam 19% mais tempo para concluir as tarefas.

O dado mais desconfortável é o da percepção. Os participantes esperavam ganhar 24% de velocidade. Depois de terem sido medidos mais lentos, ainda acreditavam ter ganhado 20% (METR, julho de 2025, acesso em 19/08/2026).

Antes de usar esse número como argumento contra agentes, leia a letra miúda: os participantes usaram principalmente Cursor Pro com Claude 3.5 e 3.7 Sonnet. Não era Claude Code, não era 2026, não havia skills, MCP ou subagentes na configuração testada. Os próprios autores classificam o achado como "um retrato das capacidades de IA no início de 2025, em um cenário relevante".

Se a comparação entre as ferramentas em si é o que interessa, Claude Code, Codex e Cursor lado a lado trata o modelo de permissão de cada uma, que é onde elas de fato divergem.

Citar a METR como prova de que agentes de código não funcionam hoje é citar mal. O que o estudo prova, e isso continua valendo, é que sua percepção de velocidade não é instrumento de medida.

O que a Microsoft mediu um ano depois

Em julho de 2026, pesquisadores da Microsoft publicaram um estudo do rollout interno de Claude Code e GitHub Copilot CLI, acompanhando dezenas de milhares de engenheiros ao longo de uma janela de quatro meses.

Os adotantes aprovaram cerca de 24% mais pull requests do que teriam aprovado sem as ferramentas, e o efeito se manteve durante toda a janela — ou seja, não foi efeito novidade. O estudo também achou que o primeiro uso se espalhou principalmente por redes sociais internas, e que a retenção teve mais relação com a atividade de código do engenheiro do que com dados demográficos (Murphy-Hill, Butler e Savelieva, arXiv:2607.01418, julho de 2026, acesso em 19/08/2026).

Os autores colocam a ressalva que interessa: "um PR aprovado não é a mesma coisa que o valor que ele entrega". Eles usam PR aprovado como proxy de produção, e dizem isso na cara.

A leitura honesta dos dois

Um ano separa os dois. Uma geração de ferramentas separa os dois. E a métrica não é a mesma: tempo por tarefa individual e volume de PR aprovado medem coisas diferentes.

O que nenhum dos dois prova é que o seu setup funciona. Um ensaio controlado tem validade interna alta e amostra minúscula; um estudo observacional em escala tem o problema oposto. A pergunta que sobra para você é a única que este guia tenta responder: o que precisa existir em volta do agente para que ele ajude em vez de atrapalhar.

Contexto, capacidade, conexão, delegação e verificação. Nessa ordem, porque cada uma depende da anterior.

A ordem importa mais do que parece. Instalar dez MCP servers antes de escrever um CLAUDE.md decente é o erro mais comum que vejo — e ele piora o resultado, porque enche o contexto sem dar ao agente a informação que faria as ferramentas serem usadas na hora certa.

O CLAUDE.md é carregado no contexto no início de toda sessão. Isso significa que cada linha dele é cobrada em toda tarefa que você faz, inclusive nas que não têm nada a ver com o que está escrito ali.

A documentação oficial é direta sobre o limite prático: manter o CLAUDE.md abaixo de 200 linhas, incluindo apenas o essencial, e mover instruções especializadas (revisão de PR, migração de banco, convenção de commit) para skills, que carregam sob demanda apenas quando invocadas (Claude Code Docs — Manage costs, acesso em 19/08/2026).

Esse é o trade-off central da camada 1. Tudo que está no CLAUDE.md é conhecimento garantido e custo garantido. Tudo que está em skill é custo zero até ser preciso, com o risco de não ser invocado na hora certa.

Duas práticas de higiene que fazem mais diferença que qualquer prompt engineering:

• /clear ao trocar de assunto. Contexto velho é desperdício em toda mensagem seguinte. Use /rename antes de limpar para achar a sessão depois, e /resume para voltar.
• /compact com instrução. /compact Foque nos exemplos de código e no uso da API diz ao agente o que preservar na sumarização. Sem instrução, ele escolhe sozinho — e às vezes escolhe errado.

Existe um detalhe de custo que quase ninguém sabe: uma sessão aberta há horas manda a conversa inteira em toda requisição. Com prompt caching, esse histórico é relido na tarifa de cache, mas a vida útil do cache é de uma hora numa assinatura e cai para cinco minutos quando você passa a consumir usage credits ou usa chave de API. Uma pergunta de uma linha numa sessão aberta o dia todo ainda consome pelo histórico completo.

Isso explica um fenômeno que parece bug e não é: a primeira mensagem depois de um intervalo maior que a vida do cache erra o cache e reprocessa seu contexto inteiro. Você voltou do almoço, mandou "e agora?", e pagou pela conversa completa de novo. Vale saber também que /compact é ele próprio uma requisição grande, porque precisa ler a conversa que vai resumir — quando você quer começar do zero em vez de manter continuidade, /clear não custa nada.

O critério que uso para decidir se algo entra no CLAUDE.md ou vira skill é uma pergunta só: isso é verdade em toda tarefa deste projeto? Convenção de nomenclatura, sim. Procedimento de migração de banco, não — isso é skill.

Se quiser ir fundo nessa camada, escrevi a anatomia de um CLAUDE.md que funciona, com os quatro escopos, o limite de 200 linhas e o que fazer com o excedente.

Skills dão conhecimento de domínio. Hooks tiram trabalho do agente antes que ele gaste contexto com isso.

A distinção é útil. Uma skill de "visão geral da arquitetura" descreve diretórios, convenções e decisões do projeto — quando invocada, o agente recebe isso pronto em vez de gastar dezenas de leituras de arquivo para inferir a mesma coisa.

Hooks resolvem outro problema. Em vez de o agente ler um log de 10.000 linhas para achar os erros, um hook faz o grep e devolve só as linhas que importam, reduzindo o contexto de dezenas de milhares de tokens para centenas.

O exemplo da documentação oficial vale copiar inteiro — um PreToolUse que filtra saída de teste para mostrar apenas falhas:

#!/bin/bash
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command')

# Se estiver rodando testes, filtra para mostrar so as falhas
if [[ "$cmd" =~ ^(npm test|pytest|go test) ]]; then
  filtered_cmd="$cmd 2>&1 | grep -A 5 -E '(FAIL|ERROR|error:)' | head -100"
  echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"allow\",\"updatedInput\":{\"command\":\"$filtered_cmd\"}}}"
else
  echo "{}"
fi

A referência completa dos comandos do Claude Code cobre os 294 que existem hoje, com o que cada um entrega. Para verificar se o hook está ativo, /hooks mostra se ele aparece sob PreToolUse. Rodando com claude --debug, o log mostra modified tool input keys: [command] quando o hook reescreve o comando.

Para quem trabalha com linguagem tipada, há um ganho fácil que muita gente deixa na mesa: plugins de code intelligence. Eles dão navegação precisa por símbolo em vez de busca por texto — um "ir para definição" substitui um grep seguido da leitura de vários arquivos candidatos. E o language server instalado reporta erro de tipo automaticamente depois das edições, então o agente pega o problema sem precisar rodar compilador.

A diferença entre as três ferramentas desta camada, resumida:

Quem só usa CLAUDE.md paga contexto em toda tarefa. Quem só usa skill corre o risco de ela não ser invocada. Quem usa hook resolve o problema antes que ele vire contexto — é a mais subutilizada das três, e a que mais reduz conta.

O passo a passo está em como escrever a sua primeira Agent Skill, incluindo por que o corpo precisa ser curto. O catálogo com as 44 skills avaliadas e 294 comandos documentados mostra quais passaram no filtro e quais foram reprovadas, com o motivo de cada uma.

O MCP conecta o agente a sistemas fora do repositório. E a decisão mais importante sobre MCP é quando não usar.

A orientação oficial é clara e vai contra a intuição de quem acabou de descobrir o protocolo: prefira CLIs quando existirem. Ferramentas como gh, aws, gcloud e sentry-cli são mais eficientes em contexto que servidores MCP, porque não adicionam nenhuma listagem por ferramenta — o agente roda o comando.

Isso melhorou bastante: as definições de ferramentas MCP agora são carregadas sob demanda por padrão, então só os nomes entram no contexto até o agente usar uma ferramenta específica. Ainda assim, /context mostra o que está ocupando espaço, e /mcp lista os servidores configurados para você desligar o que não está usando.

A regra prática que uso: MCP para o que não tem CLI decente (Figma, Notion, bancos de dados internos, APIs proprietárias). CLI para tudo que já tem.

O motivo é mecânico, não ideológico. Um servidor MCP precisa se anunciar ao agente — mesmo com carregamento sob demanda, existe um custo de descoberta. Um CLI não se anuncia: o agente já sabe rodar comando de terminal, então gh pr list custa exatamente o que a saída do comando custa, e nada além disso.

Há um efeito colateral raramente discutido: MCP server é superfície de ataque. Ele roda com as permissões que você deu ao agente e conversa com sistemas que têm seus dados. Instalar servidor de terceiro sem ler o que ele faz é equivalente a npm install de pacote desconhecido, com a diferença de que este tem acesso ao seu repositório e às suas credenciais. O /mcp lista o que está configurado — vale revisar essa lista de vez em quando com o mesmo olhar que você daria ao package.json.

Vale saber que o /usage mostra a atribuição de consumo por servidor MCP individualmente, contando apenas as requisições que efetivamente usaram um resultado de ferramenta daquele servidor. É o jeito de descobrir qual servidor está caro sem chutar.

A lista curada de ferramentas de IA reúne o que vale conectar por MCP e o que já tem CLI melhor.

O passo a passo está em MCP na prática, incluindo os três escopos e a precedência que não mescla campos.

São coisas arquitetonicamente diferentes, e confundir as duas custa dinheiro.

Subagentes são instâncias especializadas que rodam dentro da sua sessão. Cada um tem janela de contexto isolada, system prompt próprio definido no corpo do arquivo do agente, lista de ferramentas com escopo via tools ou disallowedTools, e permissões independentes via permissionMode. Dá para fixar o modelo por subagente — model: haiku para tarefa simples é a economia mais fácil que existe no Claude Code.

O melhor uso deles é isolamento. A documentação é explícita: um dos usos mais eficazes de subagente é isolar operações que produzem muita saída. Rodar testes, buscar documentação ou processar arquivos de log consome contexto significativo — delegando isso, a saída verbosa fica no contexto do subagente e só o resumo relevante volta para a conversa principal.

Agent teams são arquitetonicamente outra coisa. Uma sessão é o team lead: coordena o trabalho, atribui tarefas e sintetiza resultados. Os teammates trabalham de forma independente, cada um na sua janela de contexto, e essa é a diferença que importa: conversam diretamente entre si, sem passar pelo lead.

A estrutura tem quatro peças: um team lead, os teammates, uma task list compartilhada que eles reivindicam, e um mailbox para as mensagens entre agentes.

Quando cada um vence

A regra: use subagente quando precisa de trabalhador rápido e focado que reporta de volta. Use agent team quando os trabalhadores precisam compartilhar achados, se contestar e coordenar sozinhos.

O número que decide

Agent teams consomem aproximadamente 7x mais tokens que uma sessão padrão quando os teammates rodam em plan mode, porque cada teammate mantém a própria janela de contexto e roda como instância separada (Claude Code Docs, acesso em 19/08/2026).

Por isso eles são experimentais e vêm desligados por padrão, atrás de CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.

Há um efeito colateral que pega muita gente de surpresa: com agent teams ligados, um subagente que o Claude nomear por conta própria é lançado como teammate. Times podem se formar sem que você tenha pedido — e se o seu fluxo espera o resultado de um subagente, ele trava, porque teammate notifica que ficou ocioso sem devolver a saída.

Se for usar: Sonnet nos teammates, comece com 3 a 5, prompt de spawn com o contexto da tarefa (eles carregam CLAUDE.md, MCP e skills sozinhos, mas não herdam o histórico do lead), um dono por arquivo para evitar sobrescrita, e desligue quando terminar.

Quando compor vários agentes compensa, e quando não, está em orquestração multi-agente.

O critério completo está em subagentes: quando delegar e quando não.

Dando ao agente alvo de verificação antes dele começar, não depois.

Essa é a camada que separa quem usa agente de quem é usado por ele. Quatro hábitos, em ordem de impacto:

Plan mode antes de tarefa complexa. Shift+Tab cicla para o modo em que o agente explora o código e propõe uma abordagem para sua aprovação, antes de escrever qualquer coisa. Isso evita o retrabalho caro de quando a direção inicial está errada.

Corrigir cedo. Esc interrompe na hora. /rewind ou Esc duas vezes restaura conversa e código para um checkpoint anterior. Deixar o agente terminar uma abordagem que você já viu que está errada é o desperdício mais comum.

Dar alvo de verificação. Casos de teste, screenshot colado, saída esperada declarada no prompt. Quando o agente consegue verificar o próprio trabalho, ele pega o erro antes de você precisar pedir a correção.

Testar incrementalmente. Um arquivo, testa, continua. Pegar problema cedo é pegar problema barato.

Verificação que roda sozinha

Os quatro hábitos acima dependem de você estar presente. Hooks resolvem a parte que não deveria depender disso.

Se você usa agent teams, três hooks funcionam como portões de qualidade automáticos. TeammateIdle roda quando um teammate está prestes a ficar ocioso — saindo com código 2, você manda o retorno de volta e o mantém trabalhando. TaskCreated e TaskCompleted fazem o mesmo na criação e na conclusão de tarefa: código 2 impede a operação e devolve o motivo.

Isso muda a natureza da revisão. Em vez de você olhar o resultado depois, a regra fica codificada e o agente esbarra nela antes de declarar que terminou. É a diferença entre "revisei e estava errado" e "não passou".

O que não delegar

Uma linha que vale ter clara: decisão de arquitetura que você não sabe avaliar não deve ser delegada. Não porque o agente erra mais que você, mas porque você não vai conseguir detectar se errou. Delegar o que você não sabe revisar transfere o risco sem transferir a responsabilidade — e a responsabilidade continua sendo sua no code review, no incidente e na reunião.

O mesmo vale para permissão. Rodar com aprovação automática num repositório que você conhece bem é decisão razoável. Rodar assim em código que você viu pela primeira vez hoje é apostar que o agente entende o sistema melhor que você — o que pode até ser verdade, e continua sendo uma aposta.

O que liberar e o que travar está em permissões e auto mode. A lista do que nunca deve entrar no conjunto de ferramentas de um agente merece decisão explícita, e não o padrão da ferramenta.

Em implantações corporativas, a média é de cerca de US$ 13 por desenvolvedor por dia ativo e US$ 150 a 250 por desenvolvedor por mês, com o custo permanecendo abaixo de US$ 30 por dia ativo para 90% dos usuários (Claude Code Docs, acesso em 19/08/2026).

Esses números são de implantação corporativa cobrada por token. Em assinatura Pro ou Max o uso está incluído no plano, e o valor em dólar que aparece no /usage não serve para faturamento — é calculado localmente a partir da contagem de tokens em tarifa de tabela.

Duas fontes de custo inesperado dominam as surpresas de fatura: sessões longas que nunca foram limpas e Opus deixado como modelo padrão. Os dois hábitos que mais reduzem conta são os mais chatos de manter: limpar entre tarefas não relacionadas e escolher o modelo adequado ao trabalho.

Vale saber também que o agente consome uma pequena quantidade de tokens em segundo plano mesmo ocioso — sumarização de conversa para o --resume e processamento de alguns comandos. Tipicamente abaixo de US$ 0,04 por sessão.

Um detalhe do extended thinking que pesa mais do que parece: ele vem ligado por padrão, os tokens de raciocínio são cobrados como tokens de saída, e o orçamento padrão pode chegar a dezenas de milhares de tokens por requisição. Para tarefa simples, /effort num nível mais baixo é economia direta sem perda perceptível.

Se você vai estimar orçamento para um time, o conselho mais útil é este: orçe mais para um assento de código do que para um de chat. Cada turno do Claude Code carrega conteúdo de arquivo, chamadas de ferramenta e raciocínio de vários passos — uma sessão de depuração pode consumir mais que um dia inteiro de chat.

A medição de custo por padrão de uso está em quanto custa cada padrão de uso.

Não perguntando a si mesmo. Esse é o achado da METR que sobrevive a qualquer mudança de ferramenta: os participantes foram medidos 19% mais lentos e continuaram acreditando que estavam 20% mais rápidos. A sensação de velocidade e a velocidade são variáveis independentes.

Isso te deixa com um problema prático. Você não pode montar um ensaio controlado randomizado no seu trabalho, e sua percepção não serve. Sobram três instrumentos, em ordem de esforço.

O barato: /insights. Diferente do /usage, que mostra quantos tokens você gastou, o /insights gera um relatório de como você trabalha. Ele analisa suas sessões recentes e escreve um HTML cobrindo no que você trabalha, pontos de atrito (pedidos mal interpretados, código com defeito) e sugestões de uso. Uma execução analisa até 200 sessões que ainda não viu. O relatório fica em ~/.claude/usage-data/report.html, e cada execução guarda uma cópia com data.

O valor dele está na seção de atrito. Quando o mesmo tipo de pedido aparece repetidamente como mal interpretado, isso não é falha do modelo — é lacuna no seu CLAUDE.md. O relatório vira lista de tarefas para a camada 1.

O honesto: uma métrica de saída que você já coleta. O estudo da Microsoft usou PR aprovado como proxy, com a ressalva explícita de que PR aprovado não é o valor que ele entrega. É um proxy ruim, e mesmo assim é melhor que sensação. Se você já tem contagem de PR, de issue fechada ou de release, compare janelas de tempo comparáveis. Não precisa ser rigoroso; precisa ser um número que exista fora da sua cabeça.

O que não funciona: contar linhas de código gerado. É a métrica mais fácil de coletar e a mais fácil de enganar — o agente é ótimo em produzir volume, e volume não é entrega.

Um alerta metodológico que vale para qualquer medição que você fizer: cuidado com o efeito novidade. O estudo da Microsoft se preocupou explicitamente com isso e verificou que o ganho persistia ao longo de quatro meses. Duas semanas de entusiasmo não são dado. Se for medir, meça por pelo menos um trimestre.

E aceite a possibilidade de que o resultado seja "não mudou nada". Nesse caso a resposta não é abandonar a ferramenta nem insistir por fé — é olhar quais das cinco camadas você nunca montou. Na maioria dos casos que vi, a resposta é a primeira.

Na ordem em que aparecem, na minha experiência montando isso em projeto de cliente.

O CLAUDE.md incha e ninguém percebe. Começa com 40 linhas úteis, chega a 400 em três meses, e a partir daí toda tarefa carrega instrução de migração de banco mesmo quando você está mexendo em CSS. Sintoma: o agente começa a "esquecer" o pedido no meio de tarefas longas.

MCP servers acumulam. Cada um pareceu boa ideia no dia. Sintoma: /context mostra que metade do espaço foi antes da primeira mensagem.

Sessão eterna. Você abre de manhã e usa até a noite. Sintoma: a conta triplica sem que o volume de trabalho tenha mudado.

Opus por padrão em tudo. Sintoma: custo por tarefa que não faz sentido diante da complexidade da tarefa.

Agent teams ligados sem necessidade. Sintoma: consumo que dispara sem explicação — cerca de 7x quando os teammates rodam em plan mode.

Um padrão atravessa todos esses: eles pioram devagar. Nenhum quebra de uma vez. O setup vai degradando ao longo de semanas até você concluir que "o Claude Code piorou". Ele não piorou — o seu contexto engordou.

O diagnóstico é sempre o mesmo comando. /usage mostra a atribuição de uso recente por skill, subagente, plugin e servidor MCP, cada um como porcentagem do total, e sinaliza comportamentos que respondem por 10% ou mais do consumo. É o exame de sangue do setup. Vale marcar vinte minutos por mês para rodar ele e o /context, e desligar o que não usa.

Catalogei as 18 armadilhas do Claude Code em projeto real, cada uma com o sintoma que a revela.

Cinco passos, na ordem das camadas. Cada um leva menos de uma hora.

1. Corte seu CLAUDE.md para menos de 200 linhas. O que sobrar vira skill.
2. Rode /context e desligue os MCP servers que não usa. Troque por CLI onde existir CLI.
3. Escreva um hook para o comando cuja saída você mais filtra na mão.
4. Adote /clear entre tarefas não relacionadas. É o hábito de maior retorno da lista.
5. Rode /usage no fim da semana e olhe a atribuição por skill e por servidor MCP.

Só depois disso vale mexer em subagente ou agent team. Delegação sobre contexto ruim multiplica o contexto ruim.

Se o seu caso de uso for produção de conteúdo em vez de código, o mesmo raciocínio de camadas aparece nas stacks de skills para artigos de blog, montadas com a mesma lógica de contexto antes de capacidade.

Claude Code funciona bem em projeto legado grande?

Funciona, mas depende inteiramente da camada 1. Em base de código grande, o gargalo não é a capacidade do modelo e sim quanto contexto relevante ele consegue reunir antes de agir. Plugins de code intelligence ajudam bastante em linguagem tipada, porque substituem busca por texto por navegação precisa de símbolo.

Preciso ligar agent teams para trabalhar sério?

Não. Eles vêm desligados por padrão e consomem cerca de 7x mais tokens em plan mode. Subagente resolve a maioria dos casos de isolamento de contexto (rodar teste, buscar documentação, processar log) a uma fração do custo. Ligue agent teams quando tiver trabalho genuinamente paralelo e independente, não para acelerar tarefa sequencial.

Como sei se estou gastando demais?

/usage mostra a atribuição por skill, subagente, plugin e servidor MCP, e sinaliza comportamentos que respondem por 10% ou mais do consumo. Se o número não bate com a sensação de trabalho feito, os suspeitos habituais são sessão nunca limpa e Opus como padrão.

Skill ou CLAUDE.md: onde coloco a instrução?

A pergunta que resolve: isso é verdade em toda tarefa deste projeto? Se sim, vai para o CLAUDE.md: convenção de nomenclatura, stack, decisões de arquitetura que valem sempre. Se é procedimento específico, que aparece de vez em quando, vira skill. Revisão de PR, migração de banco, publicação de release. O CLAUDE.md é carregado em toda sessão e cobra por isso; skill carrega sob demanda. O limite oficial recomendado é 200 linhas.

Vale a pena rodar tudo no Opus?

Raramente. Sonnet dá conta da maior parte das tarefas de código e custa menos. A recomendação oficial é reservar Opus para decisão de arquitetura complexa ou raciocínio de vários passos, trocando com /model no meio da sessão. Opus deixado como padrão é uma das duas causas mais comuns de fatura inesperada — a outra é sessão longa nunca limpa. Para subagente de tarefa simples, model: haiku na configuração corta ainda mais.

Aquele estudo que diz que IA deixa dev mais lento invalida tudo isso?

Não, mas merece ser levado a sério. O ensaio da METR mediu 19% de lentidão em early-2025, com Cursor Pro e Sonnet 3.5/3.7, com 16 desenvolvedores. O estudo da Microsoft mediu +24% de PRs aprovados em early-2026, com Claude Code e Copilot CLI, com dezenas de milhares de engenheiros. São ferramentas, épocas, escalas e métricas diferentes. O achado da METR que sobrevive a tudo isso é o da percepção: você não é instrumento confiável para medir a própria velocidade.

• METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Publicado em 10/07/2025. Acesso em 19/08/2026.
• Murphy-Hill, E.; Butler, J.; Savelieva, A. — Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft's Early 2026 Rollout of Claude Code and GitHub Copilot CLI. arXiv:2607.01418, julho de 2026. Acesso em 19/08/2026.
• Anthropic — Claude Code Docs: Manage costs effectively. Acesso em 19/08/2026.
• Anthropic — Claude Code Docs: Agent teams. Acesso em 19/08/2026.
• Anthropic — Claude Code Docs: Sub-agents. Acesso em 19/08/2026.
• Anthropic — Claude Code Docs: Hooks reference. Acesso em 20/08/2026.

Verificado em 19 de agosto de 2026.

Gatilho de reavaliação: este post precisa de revisão quando (a) a METR publicar o redesenho do estudo que anunciou em 2026, (b) agent teams deixarem de ser experimentais ou mudarem o multiplicador de 7x, (c) os valores de custo por desenvolvedor da documentação oficial forem atualizados, ou (d) o limite recomendado de 200 linhas do CLAUDE.md mudar.