Como saber se o Claude Code está realmente acelerando o seu projeto?

Sentir que ficou mais rápido e provar que ficou mais rápido são duas coisas bem diferentes

E é bem aí que quase todo mundo se perde quando começa a usar agente de código no dia a dia

O ganho existe, isso é fato, só que ele aparece em alguns contextos e simplesmente evapora em outros

A única forma de saber qual é o SEU caso é olhar número do seu próprio projeto, ao longo de algumas semanas, em vez de confiar na euforia da primeira sessão que deu certo 🙂

Bora separar sensação de ganho real?

Sensação de ganho x ganho medido: o que os estudos mostram

Antes de instrumentar qualquer coisa, vale ver o tamanho do buraco entre o que as pessoas sentem e o que a régua mostra

Os números abaixo são todos de medição publicada, nada de achismo:

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Repara numa coisa: a coluna da direita não é toda negativa

O ensaio antigo da METR virou histórico, o novo achou ganho, e a telemetria da Microsoft mostra saída maior de verdade

O problema não é o ganho não existir, é ele ser MUITO menor do que a sensação de 2x que a gente carrega na cabeça

E por que as duas colunas divergem tanto? Porque a sensação mede o tempo em que você estava travado e destravou, enquanto a medição mede o ciclo inteiro, incluindo a parte chata de ler, revisar e consertar o que veio pronto

Como medir o efeito do Claude Code no seu projeto em 4 passos

A boa notícia: tu não precisa de estudo acadêmico, precisa de quatro números e de paciência de duas ou três semanas

1. Fixe a linha de base ANTES de julgar

Anota como está hoje: quantos pull requests você mescla por semana, quanto tempo em média um PR fica esperando revisão, quantos bugs voltaram do que foi entregue no último mês

Sem esse retrato, qualquer comparação depois vira memória seletiva

O erro comum deste passo: comparar semanas com carga diferente

Semana de sprint calma contra semana de incidente não compara nada, o certo é juntar várias semanas de cada lado

2. Meça saída real, não linha escrita

O que conta é pull request mesclado e commit que sobreviveu, porque foi exatamente esse recorte que a telemetria da Microsoft usou pra achar os 24% a mais

O erro comum deste passo: medir linhas de código

Agente gera linha com uma facilidade absurda, e volume de linha não é entrega, é só volume 😀

3. Meça o custo do outro lado

Aqui mora o ganho que some: tempo de revisão do código gerado, tempo de depuração e quantidade de bug que voltou pro seu colo

Marca isso separado do resto, senão o custo se dissolve no dia e você nunca enxerga

O erro comum deste passo: contar só o tempo até o código aparecer na tela e considerar a tarefa fechada

E se a impressão for de que tudo está arrastado, vale descobrir se o Claude Code está lento antes de acusar o fluxo inteiro

4. Puxe os números da própria ferramenta

A Anthropic oferece uma Analytics API do Claude Code, que faz parte da Admin API, com métricas diárias agregadas

Ela entrega sessões, linhas de código adicionadas e removidas, commits, pull requests, taxas de aceitação e rejeição por ferramenta (Edit, MultiEdit, Write, NotebookEdit) e custo estimado por modelo

O endpoint é este:

https://api.anthropic.com/v1/organizations/usage_report/claude_code

Pra chamar, tu precisa de uma Admin API key (prefixo sk-ant-admin) enviada no header x-api-key

E se liga: essa chave só é provisionada por membros com papel de admin no Console, então não adianta tentar com a chave comum

Que tipo de número essa API NÃO te dá? Acompanhamento em tempo real, porque ela é diária e agregada

Pra isso a documentação do Claude Code indica a integração via OpenTelemetry, habilitada pela variável de ambiente:

CLAUDE_CODE_ENABLE_TELEMETRY=1

E administradores podem configurar as opções de OpenTelemetry pra todos os usuários pelo arquivo de managed settings, o que evita cada dev ligar do seu jeito

O erro comum deste passo: olhar só volume e esquecer o custo por desenvolvedor ativo, que é justamente o outro lado da conta

E contra o que tu compara esse custo? A documentação de custos do Claude Code publica faixas médias em implantações corporativas: cerca de US$ 13 por desenvolvedor por dia ativo e US$ 150 a US$ 250 por desenvolvedor por mês, com 90% dos usuários ficando abaixo de US$ 30 por dia ativo

Se o seu número está muito fora dessa faixa, pra cima ou pra baixo, já é um sinal de que o uso do time não é o que você imagina

Sinais de que o agente está criando trabalho em vez de tirar

Esses sintomas não aparecem no dia 1, aparecem depois de algumas semanas, quando a base já absorveu bastante código gerado

O código chega quase certo e come a sua revisão

Causa provável: o modelo acerta a forma e erra o detalhe, e detalhe errado só aparece na leitura atenta ou no runtime

Na pesquisa de desenvolvedores do Stack Overflow 2025, 66% citam "soluções de IA quase certas, mas não totalmente" como maior frustração, e 45% dizem que depurar código gerado por IA consome mais tempo

O que fazer: cronometrar a revisão e comparar com o que você levava pra revisar código humano equivalente

Se a revisão cresceu mais do que a entrega, o saldo já está negativo

Duplicação e churn subindo no repositório

Causa provável: é mais barato pro agente repetir um bloco do que entender a abstração que já existe

A pesquisa de qualidade de código da GitClear analisou 623 milhões de mudanças entre 2023 e 2026 e mediu duplicação de blocos subindo 81%, copiar e colar dentro do mesmo commit subindo 41% e churn de duas semanas subindo 15%

No mesmo período, a movimentação de linhas por refatoração caiu 70%, o código movido de forma corretamente refatorada caiu de 21% para 3,8%, as construções que mascaram erro subiram 47% e as chamadas de função entre arquivos caíram 35%

O que fazer: rodar uma medição de duplicação na sua base e comparar com o período anterior à adoção

Se a curva de duplicação sobe junto com a curva de entrega, o agente está pagando velocidade hoje com manutenção amanhã

Mais entrega, porém mais instabilidade

Causa provável: throughput maior sem malha de segurança maior

É o achado do DORA 2025: adoção de IA se relaciona positivamente com throughput e continua aumentando a instabilidade da entrega

O que fazer: olhar entrega e instabilidade lado a lado, sempre

Ganho de throughput que vem acompanhado de mais falha em produção não é ganho, é dívida antecipada

Os impostos ocultos que ninguém lança na planilha

Causa provável: o custo aparece fora do código, em lugares que não têm métrica

O DORA publicou um relatório específico de ROI de desenvolvimento assistido por IA ("ROI of AI-Assisted Software Development", edição 2026.01), com um framework pra traduzir métricas de engenharia em valor de negócio, e cita três impostos ocultos: sobrecarga de verificação, degradação de habilidade e problemas de integração

O que fazer: nomear esses três no seu acompanhamento, mesmo que a medição seja tosca no começo

Como prevenir os quatro de uma vez: escopo menor por sessão, revisão obrigatória de tudo que entra e um limite duro pra aceitar diff grande sem leitura

Diff gigante aceito no automático é a receita perfeita pra churn de duas semanas 😛

Quando o ganho aparece de verdade (e quando ele não vem)

Não adianta perguntar "o agente acelera?" no vácuo, a pergunta certa é "acelera EM QUÊ"

Onde a aceleração costuma ser real:

• tarefa nova, começando do zero, sem bagagem de contexto implícito
• repositório que tu conhece pouco e precisa navegar rápido
• trabalho repetitivo, aquele de padrão claro e execução chata
• esteira de entrega já saudável, com teste, revisão e deploy funcionando

Onde ela evapora:

• repositório maduro, cheio de contexto implícito que ninguém escreveu em lugar nenhum (foi exatamente esse o cenário do ensaio da METR que mediu 19% mais tempo)
• time sem plataforma interna decente
• processo de revisão frágil, onde o código gerado entra sem ninguém ler direito

O DORA sustenta que a IA funciona como amplificador: ela melhora times que já são bons e intensifica as disfunções de times que já vão mal

A IA não conserta o time, ela amplifica o que já existe, e o retorno vem da qualidade da plataforma interna, da clareza do fluxo e do alinhamento do time

Ou seja: se o seu processo é bagunçado, o agente vai te entregar bagunça mais rápido

O mesmo raciocínio vale pra configuração copiada de terceiro, e é por isso que tanta skill que não funciona morre no projeto dos outros, o contexto simplesmente não é o mesmo

E tem o pano de fundo da confiança, que não está lá essas coisas

No DORA 2025, 24% confiam muito na IA (4% "muitíssimo" e 20% "bastante") contra 30% que confiam pouco ou nada (23% "um pouco" e 7% "nada")

No Stack Overflow 2025 a foto é parecida: 46% desconfiam da precisão contra 33% que confiam, e apenas 3% confiam muito na saída, mesmo com 84% usando ou pretendendo usar ferramentas de IA

Muita gente usando, pouca gente confiando, o que combina bastante com a ideia de que o custo de verificação é o preço real do brinquedo

O que eu observei num projeto real do começo ao fim

Pra não ficar só na estatística, deixa eu contar um caso meu

No vídeo eu montei um fluxo em que o NotebookLM faz a pesquisa e o planejamento do produto, e o Claude Code executa a construção a partir desse material

A primeira coisa que aprendi ali: o tempo que parece "perdido" antes de codar é o que salva o resto

Eu alimento o NotebookLM com fontes (artigos, docs, concorrentes, pesquisa própria, vídeos, PDFs) e revisto fonte por fonte pra descartar as ruins, porque fonte ruim piora a resposta e isso volta como retrabalho lá na frente

Depois eu converso com ele até sentir que o produto foi entendido, e vou salvando as respostas boas em observações

O segundo aprendizado veio de um tropeço: pedi um prompt pro Claude Code, achei o resultado pouco detalhado, e só melhorou quando pedi de novo com a resposta configurada pra sair mais longa

E o terceiro foi o que mais mudou o resultado: eu abandonei a estratégia do prompt único gigante e passei a salvar um PRD em arquivo

O PRD virou prd.md dentro da pasta do projeto, e no Claude Code eu referencio o arquivo em vez de colar um bloco enorme

O motivo é simples: prompt muito grande faz o Claude Code perder pedaços do pedido pelo caminho, e pedaço perdido é exatamente o "quase certo" que come a sua revisão depois

Onde a velocidade apareceu de verdade foi na execução da V1, com o escopo já decidido no papel

Onde o tempo foi embora foi nas idas e voltas de pedido mal formulado, o que é custo de planejamento, não de digitação

E tem um efeito que não é de velocidade, é de resultado: pedir direto pra IA tende a gerar projetos parecidos entre si, e passar pelo planejamento com fontes é o que dá diferencial real ao produto

A lógica que eu sigo é de MVP: lança a V1 e depois volta ao NotebookLM pra gerar novos prompts e iterar funcionalidade por funcionalidade

No vídeo abaixo eu mostro o ciclo completo, do levantamento das fontes até o app rodando, se quiser ver o processo inteiro sem corte:

Veredito: o Claude Code acelera, mas só se você medir o custo do outro lado

Saldo honesto? O ganho existe e aparece em medição de campo, não é conversa de vendedor

Só que ele é bem menor do que a sensação de 2x, e vem grudado em dois custos: verificação e instabilidade

E tem o custo que dá pra somar em dinheiro, aquela faixa da documentação que a gente viu lá no passo 4: cerca de US$ 13 por desenvolvedor por dia ativo e US$ 150 a US$ 250 por desenvolvedor por mês, com 90% dos usuários ficando abaixo de US$ 30 por dia ativo

Coloca esse número ao lado do ganho que tu MEDIU, não do que sentiu

Se a sua saída subiu numa faixa parecida com a que a telemetria da Microsoft encontrou e a instabilidade não explodiu, a conta fecha com folga

Se a entrega subiu e a taxa de bug que volta subiu junto, tu está pagando pra criar trabalho novo

Pra quem já vale: time com esteira saudável, revisão levada a sério e escopo bem recortado por sessão

Pra quem ainda não vale: base madura sem documentação, processo de revisão frouxo e nenhuma métrica de linha de base

Nesse segundo caso, o passo anterior ao agente é arrumar o processo, senão o amplificador vai amplificar a bagunça

Conclusão: monte sua linha de base nesta semana

Recapitulando o combinado:

• a sensação de ganho é sistematicamente maior que a medição, isso está em estudo de mais de uma casa
• o ganho medido hoje é positivo, porém modesto, e depende MUITO do contexto do repositório
• os custos aparecem depois: revisão, duplicação, churn e instabilidade
• e a única régua que interessa é a do seu projeto

A ação mínima é registrar hoje as quatro métricas: pull requests mesclados, tempo de revisão, bugs que voltaram e custo por desenvolvedor ativo

Depois roda duas ou três semanas normais, sem forçar a barra, e só então julga

A decisão é POR PROJETO, não é opinião geral sobre IA, e ela pode mudar quando o repositório mudar

Quando os números chegarem, volta aqui e compara com os sinais da seção de sintomas, porque é ali que o ganho aparente costuma vazar…

até o próximo post! 😀