Por que não medimos a produtividade do desenvolvedor (e o que medimos em vez disso)

A Rebelião Está Aqui

Em janeiro de 2024, a autoridade de proteção de dados da França multou a Amazon em €32 milhões por vigilância "excessivamente intrusiva" de funcionários¹. A empresa estava rastreando toques de teclado, atividade de scanner e cada momento de "inatividade" em seus armazéns.

A Amazon não está sozinha. Um estudo recente descobriu que 50% dos trabalhadores sendo monitorados prefeririam pedir demissão do que suportar vigilância constante². Enquanto isso, "mouse jigglers"—dispositivos que simulam atividade para enganar software de monitoramento—agora são best-sellers da Amazon. A ironia se escreve sozinha.

Isso não está acontecendo apenas em armazéns. Está acontecendo na engenharia.

Um ecossistema crescente de ferramentas de "produtividade do desenvolvedor" promete ajudar líderes de engenharia a entender o que suas equipes estão fazendo. Elas rastreiam linhas de código, commits por dia, horas no teclado e, cada vez mais—com IA—até o conteúdo do que os desenvolvedores escrevem.

Aqui está a verdade desconfortável: essas ferramentas são vigilância disfarçada de gestão. E elas estão tornando as equipes de engenharia piores, não melhores.

O Problema: Por Que Métricas de Produtividade São Tóxicas

Vamos examinar o que essas ferramentas realmente medem:

Linhas de Código

Como diz o ditado, medir produtividade de programação por linhas de código é como medir progresso de aeronaves por peso. Bill Gates supostamente disse sem rodeios: "Medir progresso de programação por linhas de código é como medir progresso de construção de aeronaves por peso."

Uma discussão no Stack Overflow capturou perfeitamente: "Medir output de desenvolvedor por linhas de código é como medir a eficácia de uma usina de energia pelo lixo que ela produz."

Mais linhas frequentemente significa código pior. Refatoração que reduz 500 linhas para 50 é progresso. Automação que elimina um processo manual é progresso. Uma abstração bem projetada que previne trabalho futuro é progresso. Nada disso aparece positivamente em métricas de LOC.

Commits Por Dia

Trivialmente fácil de manipular. Quer aumentar sua contagem de commits? Divida uma única mudança lógica em quinze commits minúsculos. Adicione mudanças de espaçamento. Faça commit do seu intervalo de almoço.

Mais importante, commits medem atividade, não impacto. Um desenvolvedor que passa uma semana projetando uma arquitetura que economiza meses de trabalho da equipe terá menos commits do que alguém entregando freneticamente features que criam débito técnico.

Horas Trabalhadas

Esta é particularmente insidiosa. Pesquisas mostram consistentemente que trabalhar além de 50 horas por semana na verdade reduz o output total³. Desenvolvedores que ficam até tarde realizam menos, não mais, porque a exaustão leva a bugs, decisões ruins e código que requer retrabalho.

Um estudo descobriu que desenvolvedores trabalhando horas excessivas literalmente produziam trabalho negativo—eles criavam mais problemas do que resolviam.

Ainda assim, "horas online" permanece uma pedra angular das ferramentas de vigilância.

O Problema de Goodhart

O economista britânico Charles Goodhart observou que "quando uma medida se torna uma meta, ela deixa de ser uma boa medida."⁴

Cada métrica mencionada acima é trivialmente manipulável:

• Quer mais commits? Divida mudanças em fragmentos.
• Quer mais linhas? Escreva código verboso.
• Quer mais horas? Mantenha seu laptop aberto.
• Quer mais PRs? Envie mudanças menores e mais frequentes.

No momento em que você começa a medir essas coisas, você não está mais medindo o que queria medir. Você está medindo quão bem as pessoas manipulam suas métricas.

O Paradoxo da IA: Por Que Está Ficando Pior

Se você achava que métricas tradicionais eram quebradas, a IA está prestes a piorar tudo.

A Ilusão de Produtividade

O relatório DORA (DevOps Research and Assessment) de 2024—o estudo anual mais abrangente sobre desempenho de entrega de software—descobriu algo surpreendente: equipes usando assistentes de codificação com IA mostraram uma diminuição de 1,5% no throughput e uma diminuição de 7,2% na estabilidade⁵.

Espera, o quê?

Um estudo de 2025 da METR foi além. Eles descobriram que desenvolvedores experientes usando assistentes de IA eram na verdade 19% mais lentos em tarefas do mundo real. Mas aqui está o detalhe: esses mesmos desenvolvedores acreditavam que eram 20% mais rápidos⁶.

A IA cria uma lacuna entre percepção e realidade. Desenvolvedores se sentem mais produtivos enquanto na verdade realizam menos.

Velocidade Individual, Lentidão Organizacional

A IA amplifica a produtividade individual em certas tarefas—gerar boilerplate, escrever testes, explicar código. Mas esse aumento de velocidade individual frequentemente se traduz em lentidão organizacional.

Análise de dados de engenharia descobriu que equipes assistidas por IA completaram 21% mais tarefas, mas suas revisões de código levaram 91% mais tempo, e elas introduziram 9% mais bugs⁷.

Mais output + revisões mais longas + mais bugs = entrega mais lenta.

Qual é a Diferença Entre Produtividade e Eficácia?

A produtividade do desenvolvedor mede atividade: commits, linhas de código, horas no teclado. A eficácia do desenvolvedor mede resultados: se o trabalho foi entregue, se permaneceu, e se ajudou a equipe. É aqui que divergimos da abordagem de capitalismo de vigilância para métricas de engenharia.

"Produtividade do desenvolvedor" é um conceito quebrado. Mas a eficácia do desenvolvedor é mensurável—se você focar em resultados, não em atividade.

Nossos cinco princípios centrais guiam tudo o que construímos:

1. Orientado a resultados: Meça valor entregue, não atividade
2. Neutro em relação à IA: Não rastreie uso de ferramentas, infira a partir de resultados
3. Desenvolvedor em primeiro lugar: Perfis individuais privados por padrão
4. Coaching em vez de julgamento: Tendências e orientação, não rankings
5. Anti-manipulação: Pontuação multidimensional resiste à manipulação

O Que Isso Significa na Prática

Não medimos commits, linhas de código ou horas trabalhadas. Medimos:

• O trabalho foi entregue? (Entrega)
• Fluiu de forma sustentável? (Fluxo)
• Permaneceu? (Qualidade)
• Ajudou a equipe? (Colaboração)

Um desenvolvedor alcançando resultados excelentes com IA = eficaz. Um desenvolvedor alcançando resultados excelentes sem IA = eficaz. Alta atividade + baixos resultados = preocupação, independentemente das ferramentas.

As 6 Dimensões da Eficácia

Medimos eficácia em seis dimensões. Cada dimensão tem múltiplos componentes que intencionalmente criam tensão entre si.

Cada dimensão conta parte da história. A mágica está em como elas interagem.

O Design Anti-Gaming (O Segredo)

Aqui está o que torna este sistema diferente: otimizar qualquer dimensão isolada normalmente prejudica pelo menos uma outra.

O Ponto Ideal de Tamanho de Lote

Considere os tamanhos de PR. Não recompensamos "mais PRs" ou "PRs maiores". Recompensamos o dimensionamento ideal:

• 100-400 linhas: Ideal. Pontuação de 100.
• Menos de 50 linhas: Fragmentação excessiva. Pontuação cai.
• Mais de 800 linhas: Grande demais para revisão eficaz. Pontuação cai.

Você não pode manipular isso tornando os PRs menores OU maiores. Existe uma faixa ideal, e desvios em qualquer direção prejudicam você.

Proporção de Correção de Bugs

Da mesma forma para qualidade, não apenas penalizamos bugs. Medimos a contribuição líquida:

• Corrigiu mais bugs do que introduziu: Pontos de bônus.
• Introduziu mais do que corrigiu: Penalidade.

Você não pode manipular isso evitando código (sem bugs, mas também sem correções). O sistema recompensa contribuição líquida positiva para a qualidade.

Privacidade como Arquitetura, Não Política

Muitas ferramentas afirmam ser "focadas em privacidade" enquanto ainda permitem vigilância. Elas adicionam uma caixa de seleção nas configurações. Prometem que os gerentes não olharão dados individuais. Criam políticas.

Políticas podem ser mudadas. Configurações podem ser alternadas. Promessas podem ser quebradas.

Nossa abordagem é diferente. A privacidade está incorporada na arquitetura:

1. Perfis individuais são isolados — Não há endpoint para recuperar "todas as pontuações de desenvolvedores"
2. Não existem placares de líderes — O conceito não foi construído
3. Gerentes veem agregados — Padrões no nível da equipe, não classificações individuais
4. Insights de coaching têm escopo definido — Visíveis apenas para o desenvolvedor (e opcionalmente, seu gerente direto)
5. Limitações de exportação — Dados individuais só podem ser exportados pelo próprio indivíduo

Isso não é apenas sobre respeitar desenvolvedores (embora seja). É sobre obter dados precisos. No momento em que as pessoas sabem que estão sendo classificadas, a Lei de Goodhart entra em ação. No momento em que a vigilância começa, os dados se tornam não confiáveis.

Confiança permite precisão. Vigilância destrói ambos.

A Visão: De Atividade para Resultados

A indústria está em um ponto de inflexão.

A abordagem antiga — métricas de vigilância, rastreamento de atividade, teatro de produtividade — está desmoronando. A IA está acelerando o colapso. Os números são maiores, mas significam menos.

A nova abordagem foca no que importa:

• De "quanto código" → "isso ajuda os usuários?"
• De vigilância → confiança
• De métricas de vaidade → impacto no negócio
• De teatro de produtividade → melhoria real

As equipes que descobrirem isso terão uma vantagem enorme. Elas reterão melhores desenvolvedores (que não tolerarão vigilância). Tomarão melhores decisões (baseadas em dados significativos). Realmente melhorarão (em vez de manipular métricas).

O Sonho do CTO

O que líderes de engenharia realmente querem:

1. Prova de que a engenharia está melhorando — Não apenas instantâneos, mas trajetórias
2. Métricas defensáveis — Algo que possam mostrar ao conselho que não pode ser facilmente descartado
3. Sem manipulação — Métricas que resistem à manipulação
4. Preservação da confiança — Medição que não destrói a cultura da equipe
5. Medição pronta para IA — Métricas que funcionam independentemente das ferramentas que as pessoas usam

Métricas tradicionais de produtividade falham em todos os cinco requisitos. São instantâneos, facilmente manipuladas, destroem a confiança e são completamente quebradas pela IA.

Métricas de eficácia — focadas em resultados, projetadas para anti-manipulação, construídas sobre confiança — entregam todos os cinco.

O Que Isso Significa Para Sua Equipe

Se você é um líder de engenharia considerando ferramentas de "produtividade de desenvolvedores", faça estas perguntas:

1. O que exatamente estamos medindo? Se a resposta for atividade (commits, LOC, horas), fuja.
2. Pode ser manipulado? Se otimizar a métrica é mais fácil do que fazer um bom trabalho, a métrica é inútil.
3. O que acontece com os dados? Se indivíduos podem ser comparados e classificados, a confiança será corroída.
4. Como lida com IA? Se tenta rastrear o uso de ferramentas, já está obsoleta.
5. Ajuda os desenvolvedores a melhorar? Se é apenas medição sem coaching, é vigilância com etapas extras.

Se você é um desenvolvedor sendo submetido a essas ferramentas, saiba que você não está louco. As métricas são sem sentido. A vigilância prejudica sim. As melhores equipes — aquelas para as quais você provavelmente quer trabalhar — estão rejeitando essa abordagem.

Junte-se à Rebelião

Estamos construindo algo diferente.

Não vigilância. Não teatro de produtividade. Não métricas de vaidade que ficam bem em apresentações ao conselho, mas geram comportamento ruim.

Estamos construindo prova de que sua equipe está realmente melhorando.

Começa com medir o que importa: resultados, não atividade. Tendências, não instantâneos. Eficácia, não produtividade.

Se você está cansado de métricas que medem as coisas erradas, vigilância que destrói a confiança e ferramentas que se tornam obsoletas no momento em que alguém abre um assistente de IA — devemos conversar.

Fontes