Métricas de efetividade de uso de IA — Spark Monitor

Resumo da pesquisa sobre como medir se uma sessão de IA (Claude Code) foi produtiva, e como ranquear uso entre várias pessoas de forma fidedigna.

Problema-base

Token bruto (input/output/cache) mede atividade, não resultado. Ranquear pessoas só por isso vira Goodhart's law: o comportamento se otimiza para o número, não para a entrega.

Métricas para somar ao que o Spark Monitor já captura

• Cache hit ratio = cache_read / (cache_read + input) — sinal de reuso eficiente de contexto.
• Output por task fechada, não por sessão — normaliza por dificuldade da tarefa.
• Sessões por task — muitas sessões para fechar 1 task indica retrabalho ou task mal escopada.
• Rework rate real — % de código gerado por IA que é revertido ou reescrito em N dias. É a 5ª métrica oficial do DORA desde 2025. Sem esse dado, as métricas acima medem atividade, não qualidade.

Base acadêmica

Paper: Chen et al., "Beyond the Commit: Developer Perspectives on Productivity with AI Coding Assistants" — ICSE-SEIP 2026 (CMU + BNY Mellon). Survey com 2989 devs + 11 entrevistas.

• Correlação entre satisfação percebida e tempo economizado auto-reportado: r = 0,34 (fraca). Confirma que métrica única não captura produtividade.
• 6 fatores identificados, agrupados em desenvolvimento / deploy / longo prazo:
  1. Autossuficiência
  2. Fricção e carga cognitiva
  3. Taxa e qualidade de conclusão de tarefa
  4. Facilidade de peer review
  5. Expertise técnica (longo prazo)
  6. Ownership do código (longo prazo)
• Achado direto ao caso: commit frequency e taxa de aceite de sugestão (o que o Spark Monitor já capta) cobrem apenas o fator de deployment — não medem tempo real gasto nem qualidade.
• Risco documentado: ranking competitivo por atividade tende a empurrar devs júnior a confiar demais na IA, corroendo aprendizado e senso de ownership.
• Meta usa métrica própria, Diff Authoring Time (DAT) — tempo real de autoria de um diff, sinal mais fino que token bruto (Beller et al. 2025).

Gate de avaliação por LLM (se for implementado)

Riscos documentados de usar um LLM como juiz de código:

• Viés de verbosidade — o juiz tende a preferir código/resposta mais longa, mesmo sem ganho real de conteúdo.
• Autopreferência — o modelo tende a preferir a própria saída/estilo (efeito de menor "perplexidade").
• Boa notícia: em tarefas verificáveis (código com teste/build), a autopreferência tende a refletir qualidade real — diferente de tarefas subjetivas como chat/resumo.

Desenho recomendado — gate em 2 camadas:

1. Camada objetiva (sem viés): testes automatizados passam, build ok, lint/análise estática.
2. Camada LLM-juiz: só para o que a camada objetiva não pega — legibilidade, aderência a padrão. Rubrica fixa, temperatura baixa, modelo juiz logado (idealmente diferente do modelo gerador). Calibrar periodicamente contra o rework rate real.

Mercado — não existe score pronto, mas existe a categoria

• GitClear — mede churn, duplicação, idade do código, atribuição IA vs. humano. ~US$15/contribuidor/mês.
• DX — feito pelos autores do SPACE e do DORA; lançou framework de IA dedicado em 2026 (utilização, impacto, custo).
• Nenhuma resolve o problema sozinha. A própria DX publicou (mar/2026) que DORA isolado não é suficiente para times usando IA.

Dados já disponíveis para implementação

• Projeto: campo cwd presente em cada linha do JSONL de sessão do Claude Code (~/.claude/projects/<cwd-codificado>/<uuid>.jsonl — no Windows, %USERPROFILE%\.claude\projects\), mais gitBranch. Já está no dado que o Spark Monitor lê.
• Push feito pela própria IA: já registrado no mesmo JSONL, como tool_use/tool_result do Bash rodando git push.
• Push manual do humano (fora do Claude Code): não está no log do Claude Code. Requer hook git global (git config --global core.hooksPath <pasta>, hook pre-push) — cobre todos os repositórios de uma vez. Atenção: pre-push confirma a intenção do push, não garante que a transferência de rede terminou com sucesso.
• Atenção: "subiu pro remoto" ≠ "foi pra produção". Confirmar deploy real exige integração com CI/CD.

---

Fontes

Acadêmico

• Chen et al., "Beyond the Commit: Developer Perspectives on Productivity with AI Coding Assistants", ICSE-SEIP 2026 — https://arxiv.org/abs/2602.03593
• Wataoka et al., "Self-Preference Bias in LLM-as-a-Judge" — https://arxiv.org/html/2410.21819v1
• "Judging the Judges: A Systematic Evaluation of Bias Mitigation Strategies in LLM-as-a-Judge Pipelines" — https://arxiv.org/pdf/2604.23178
• "Do LLM Evaluators Prefer Themselves for a Reason?" (Univ. of Virginia, 2025) — https://papers.lunadong.com/paper/6021
• DORA Research, AI Capabilities Model — https://dora.dev/research/ai/ai-capabilities-model

Indústria / mercado

• GetDX, "How to Implement the AI Measurement Framework" — https://getdx.com/blog/how-to-implement-ai-measurement-framework/
• GitClear, estudo de churn/duplicação em código gerado por IA — via https://arc.dev/talent-blog
• Faros AI, "AI Engineering Report 2026" — https://www.faros.ai

Documentação técnica Claude Code

• Formato JSONL de sessão — https://claude-dev.tools/docs/jsonl-format
• Local dos logs (~/.claude/) — https://claude-dev.tools/docs/log-locations