Como medir a produtividade no Claude Code e saber se o sistema que você instalou está mesmo ajudando

Instalar uma skill, um plugin ou um sistema inteiro no Claude Code leva dois minutos

Decidir se aquilo ali está mesmo ajudando é a parte que quase ninguém faz

O que acontece na prática é isso: você instala, sente que ficou melhor, e o negócio fica no setup pra sempre ocupando contexto e queimando token, só porque nunca foi comparado com o cenário sem ele

A decisão de manter ou desinstalar costuma ser tomada por sensação, e existe um jeito bem mais honesto (e barato) de decidir isso

Bora ver na prática?

Por que a sensação de produtividade engana:

Antes do passo a passo, vale entender por que a sua percepção sozinha não serve como métrica

Em um ensaio randomizado da METR do começo de 2025, 16 desenvolvedores experientes fizeram 246 tarefas com e sem ferramentas de IA

O resultado: eles levaram 19% mais tempo para concluir as tarefas quando podiam usar IA

E aqui vem a parte insana: antes de começar, eles esperavam ficar 24% mais rápidos

Depois de terminar, mesmo tendo ficado mais lentos, ainda estimavam que a IA tinha acelerado eles em 20%

Ou seja, a diferença entre o que a pessoa sente e o que o cronômetro mostra foi enorme, e no sentido contrário do esperado

Isso significa que IA atrapalha? Não, e é importante não esticar o dado além do que ele diz

O estudo é daquele momento e daquelas ferramentas, e a própria METR anunciou em 2026-02-24 que está mudando o desenho do experimento: o novo estudo, iniciado em agosto de 2025, gerou sinal considerado não confiável por efeitos de seleção ligados à adoção mais ampla de IA

Traduzindo: não existe hoje um número atualizado de ganho ou perda medido em ensaio randomizado

O que existe é autorrelato, e ele conta outra história

Numa pesquisa da METR feita entre fevereiro e abril de 2026, com 349 participantes de perfis variados (engenheiros de software, pesquisadores, acadêmicos e doutorandos, fundadores e gestores), a mediana autorrelatada foi de 1,4x a 2x de mudança no valor do trabalho por causa das ferramentas de IA

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Os próprios autores colocam ressalvas quanto à magnitude, então trate isso como percepção agregada, não como medida

E tem o relatório DORA de 2025, que trata a IA como amplificadora: o retorno depende mais do sistema em volta (plataforma interna, clareza de fluxo, alinhamento de time) do que da ferramenta em si

Junta tudo e a conclusão prática é uma só: se a evidência de fora é dividida, a única evidência que vale pro SEU caso é a que você mede no seu projeto

O que você precisa antes de medir:

Medir aqui não é montar dashboard, é conseguir ligar e desligar o sistema e rodar a mesma coisa duas vezes

Pra isso você precisa de três coisas

1. Saber onde o sistema vive

Skills pessoais ficam em ~/.claude/skills e skills de projeto ficam em .claude/skills

Cada skill é um diretório com um SKILL.md obrigatório, que é a entrada dela

Plugins você liga e desliga pelo comando /plugin (com /plugin enable, /plugin disable e /plugin uninstall), e consegue listar por fora com claude plugin list, filtrando com --enabled ou --disabled

Se você não sabe apontar o diretório ou o plugin exato, você não tem o que desligar, e sem desligar não tem comparação

2. Uma tarefa-referência e um período

Escolha uma tarefa repetível do seu dia: criar um endpoint no padrão do projeto, escrever teste pra um serviço, refatorar um componente seguindo a convenção da casa

Tem que ser algo que você faz sempre, não a feature mais difícil do trimestre

Defina também o período de comparação: duas sessões no mesmo dia já servem, e é bom garantir que o modelo é o mesmo nas duas rodadas, então vale conferir qual versão do modelo está rodando antes de começar

3. Acesso, se a medição for de time

O painel de analytics do Claude Code fica em claude.ai/analytics/claude-code e é acessível a Admins e Owners

Se você não tem esse acesso, sem problema: os passos de sessão abaixo rodam local e resolvem o caso solo 😀

Passo a passo para medir a produtividade no Claude Code:

A ideia do protocolo é simples: mesma tarefa, dois cenários, três leituras

1. Defina a tarefa-referência e o que conta como "pronto"

Escreva numa linha o critério de pronto: testes passando, endpoint respondendo, componente renderizando sem erro no console

O erro comum deste passo: deixar o "pronto" no feeling, aí na segunda rodada você aceita um resultado pior (ou melhor) e a comparação vira ficção

2. Rode a linha de base com o sistema desligado

Desliga o plugin ou tira a skill do caminho, e faz a tarefa

   claude plugin list --enabled

   /plugin disable nome-do-plugin

O erro comum deste passo: rodar a linha de base depois, quando você já sabe a solução do problema

A segunda vez SEMPRE parece mais rápida, e não é mérito do sistema instalado

3. Leia a ocupação de contexto com /context

O /context mostra o que está ocupando espaço na janela de contexto

Anote esse número antes de digitar o pedido, porque essa é a conta que você paga a cada mensagem

Detalhe importante pra não sair caçando fantasma: enquanto uma skill não é acionada, ela ocupa no contexto só o metadado dela (nome e description), carregado no system prompt

O conteúdo do SKILL.md entra no contexto só quando a skill é usada

O erro comum deste passo: achar que cada skill instalada carrega o arquivo inteiro sempre

O peso constante é o metadado, e o peso variável aparece quando a coisa é acionada

4. Leia tokens e custo no /usage

O /usage mostra um bloco Session com estatísticas de uso de tokens e um valor em dólar estimado localmente a partir da contagem de tokens

   /usage

Esse é o seu "quanto custou essa tarefa", e ele é a leitura mais direta que existe

Coisa massa: /usage, /status e /tasks rodam imediatamente, sem interromper a resposta em andamento

Então dá pra espiar no meio do trabalho sem quebrar o fluxo

O erro comum deste passo: tratar o valor em dólar como fatura

Ele é estimado localmente a partir da contagem de tokens, e serve pra comparar rodada A com rodada B, não pra fechar contabilidade

5. Repita a mesma tarefa com o sistema ligado

Liga de volta e refaz a tarefa do zero, com o mesmo critério de pronto

   /plugin enable nome-do-plugin

Se o que você está avaliando é uma skill, o Claude Code detecta alterações em ~/.claude/skills e em .claude/skills dentro da própria sessão, sem precisar reiniciar

Isso é hot reload, dá pra recortar o SKILL.md e testar de novo na hora

O erro comum deste passo: aproveitar a segunda rodada pra "melhorar um pouquinho" o prompt

Mudou o prompt, você não está mais medindo o sistema, está medindo o prompt novo

6. Compare os dois registros

Bota lado a lado: contexto ocupado no início, tokens e custo estimado da sessão, quantas idas e voltas até o pronto

Uma tabelinha no bloco de notas já resolve, não precisa de PC da Nasa pra isso haha

O erro comum deste passo: olhar só o custo

Custo maior com retrabalho bem menor pode ser ótimo negócio, e custo menor com três correções depois é prejuízo disfarçado

7. Opcional: ligue a telemetria pra acompanhar ao longo do tempo

Duas sessões respondem "vale a pena?"

Se você quer a série histórica, a telemetria do Claude Code é opt-in e se habilita por variável de ambiente

   export CLAUDE_CODE_ENABLE_TELEMETRY=1
   export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
   export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

O exportador e o destino são configurados por variáveis OTEL (protocolo e endpoint OTLP), e para métricas existem opções como otlp, prometheus e console

Com isso ligado, o Claude Code emite métricas de uso de tokens, custo, contagem de sessões, linhas de código e commits, além de eventos estruturados pelo sinal de logs do OpenTelemetry

O erro comum deste passo: montar a stack inteira antes de ter uma pergunta

E tome cuidado: o suporte a OpenTelemetry no Claude Code está em beta, os detalhes podem mudar

O que aprendi olhando o consumo de tokens na prática:

Esse protocolo nasceu de um incômodo bem concreto: minhas sessões do Claude Code passaram a durar menos, e a cota vinha sendo consumida de forma mais agressiva

No vídeo abaixo eu mostro dez estratégias que uso pra reduzir esse consumo, e o que ficou claro montando ele é que boa parte do gasto não vem do trabalho, vem do que fica pendurado no setup

Meu critério pra manter alguma coisa no projeto é um só: aquilo evita idas e voltas?

Um arquivo de contexto bem feito faz o Claude achar a regra ali e não sair vasculhando arquivos pra deduzir o padrão sozinho

Só que o mesmo arquivo vira problema quando cresce demais, porque tudo que está nele entra como input em toda mensagem e passa a queimar token à toa

Enxuto ele ajuda, inchado ele cobra

O caso mais escancarado que eu mostro é o de MCP instalado global

Ele acaba carregado em projeto onde não faz o menor sentido, e fica lá disponível pro modelo usar sem necessidade

Cada MCP conectado adiciona as ferramentas dele no contexto de toda mensagem, o que polui o contexto e cobra token antes de você digitar qualquer coisa

Por isso minha estratégia hoje é começar com zero MCP e conectar só quando realmente precisa, preferindo instalar por projeto em vez de deixar tudo global

E eu audito isso: listo os MCPs ativos e confiro quais vieram do escopo do projeto e quais vieram do escopo do usuário, de preferência toda vez que abro um projeto

Tem também o arquivo de ignore pro Claude, na linha do gitignore, com as pastas e arquivos que não precisam ser lidos

Sinceramente? O Claude não necessariamente entraria lá

Mas o arquivo me dá a garantia de que ele nunca vai poluir o contexto com aquilo, e garantia é melhor que torcida

Outro hábito que queima token sem devolver nada é deixar o raciocínio sempre no nível máximo por costume

O que funciona pra mim é testar o nível mais baixo nas tarefas menores, ficar no médio como padrão depois que o projeto está de pé, e reservar os níveis mais altos pra início de projeto, planejamento e adição de módulo novo

E tem os dois cortes bobos que economizam muito: quando eu já sei o comando de terminal, eu rodo direto, sem passar pela LLM pra ela descobrir e executar

E quando dá erro, eu passo só a primeira linha em vez de colar o stack trace inteiro com centenas de linhas

Na maioria dos casos a primeira linha já é o suficiente

O efeito disso na medição é direto: se o seu /context já está pesado antes da tarefa começar, o "o sistema está ajudando" fica impossível de ler

Você não sabe se ganhou tempo por causa da skill nova ou se perdeu por causa dos três MCPs que estavam lá de bobeira

Limpa primeiro, mede depois

Como medir em cada cenário: uso solo, projeto e time:

O protocolo é o mesmo, o que muda é onde você lê o resultado

Uso solo:

Aqui é /context e /usage por sessão, e a comparação ligado/desligado do passo a passo

É o cenário mais rápido de rodar e o único que não depende de plano nem de permissão de admin

Se uma skill sua economiza duas idas e voltas por tarefa, isso aparece no bloco Session sem mistério

Projeto compartilhado:

Skills que ficam em .claude/skills são do repositório, então quem avalia é o time que compartilha aquele código

O teste bom aqui é pegar uma pessoa que NÃO escreveu a skill e pedir pra ela rodar a tarefa-referência

Skill que só funciona na cabeça de quem escreveu é documentação pessoal, não sistema

Time:

No painel em claude.ai/analytics/claude-code, acessível a Admins e Owners, você tem métricas de uso como linhas de código aceitas, taxa de aceitação de sugestões, usuários ativos diários e sessões

As métricas de contribuição (PRs e linhas de código enviadas com ajuda do Claude Code, via integração com GitHub) estão em beta público e disponíveis nos planos Claude for Teams e Claude for Enterprise

Se você quer puxar isso pra um lugar seu, existe a Claude Code Analytics API, que dá acesso programático a métricas diárias agregadas de uso por usuário

E pra transformar isso em conversa de dinheiro, a DORA tem um relatório dedicado ao ROI de desenvolvimento assistido por IA, com um framework pra calcular o retorno financeiro do investimento

Um aviso honesto pra fechar a seção: nenhuma dessas fontes entrega métrica por skill ou por plugin

Não existe, nas fontes oficiais, um número de "quantas vezes essa skill foi acionada e quanto ela custou"

É exatamente por isso que a comparação ligado/desligado continua sendo o método, e não uma gambiarra 🙂

Sinais de que o sistema não está ajudando (e o que fazer):

Sintoma: o contexto já está ocupado antes de você pedir qualquer coisa

Causa: setup acumulado

Cada skill instalada deixa o metadado (nome e description) no system prompt, e cada integração conectada joga as ferramentas dela no contexto de toda mensagem

Solução: rode /context antes de começar a tarefa e olhe a foto

O que não é usado sai: /plugin uninstall no plugin morto, e skill que você não aciona há semanas sai do diretório

Prevenção: fazer essa leitura ao abrir o projeto, não quando a sessão já está acabando

Sintoma: o custo por tarefa subiu e o retrabalho continua igual

Causa: o sistema está participando da conversa sem mudar o resultado

Solução: compare o bloco Session do /usage das duas rodadas junto com o número de correções até o pronto

Custo maior só se paga com retrabalho menor, e se as duas coisas subiram, é o sistema pedindo pra sair

Prevenção: anotar o par (custo, idas e voltas) sempre junto, nunca só um dos dois

Se o retrabalho vem de o modelo insistir na mesma solução errada, isso é outro problema, e eu já escrevi sobre quebrar o ciclo de erro repetido em vez de culpar a skill

Sintoma: o ganho só existe quando você fala sobre ele

Causa: é o efeito que a METR mediu, a percepção de aceleração sobreviveu até nos casos em que a pessoa ficou mais lenta

Solução: volta pra comparação com o sistema desligado, sem atalho

Sensação não é dado, mesmo quando é sua 😛

Prevenção: nunca decidir manter algo sem ter rodado ao menos uma vez sem ele

Sintoma: cada rodada dá um resultado diferente

Causa: a tarefa-referência mudou no meio do caminho, ou o critério de pronto está frouxo

Solução: congele a tarefa e o critério, e refaça o par ligado/desligado

Prevenção: guardar a tarefa-referência escrita em algum lugar, pra ela ser a mesma daqui a dois meses quando aparecer a próxima novidade

Manter, ajustar ou desinstalar: como decidir:

Com os números na mão, a decisão fica quase mecânica

O "ajustar" é o caso mais comum e o mais ignorado

Como o hot reload pega alteração em ~/.claude/skills e em .claude/skills na própria sessão, dá pra cortar metade do SKILL.md e rodar a tarefa de novo em seguida, sem reiniciar nada

E fica a régua honesta: nada disso autoriza você (nem a mim) a prometer um multiplicador fixo de produtividade

O ensaio randomizado que existe apontou 19% mais lento naquele contexto, o desenho do estudo mudou em 2026 e não há número atualizado, e o autorrelato de 1,4x a 2x vem com ressalva dos próprios autores

O que sobra de sólido é o que a DORA diz: a IA amplifica o sistema que já está lá

Então a pergunta certa nunca é "quanto essa skill me acelera", é "o que ela mudou nos meus números"

Conclusão:

Medir isso é barato absurdo

Cabe em duas sessões, usa comando que já vem no Claude Code e não precisa de planilha nem de dashboard: /context pra ver o que já está ocupado, /usage pra ver tokens e custo estimado da sessão, e a sua própria contagem de idas e voltas até o pronto

O caro é o contrário: carregar por meses um setup que ninguém nunca comparou com o cenário sem ele

Seu próximo passo, hoje mesmo: escolhe uma tarefa que você repete, roda o par ligado/desligado, anota os dois registros

E só depois disso instala a próxima novidade que aparecer no timeline 😀

Até o próximo post!