Seus números nunca subiram tanto. E, ironicamente, nunca disseram tão pouco.
O volume parou de significar valor no exato dia em que a Inteligência Artificial passou a escrever o código.
Existe uma pergunta que toda liderança de engenharia de software precisa se fazer com frequência: o que estamos entregando é realmente bom?
Quando volume ainda significava maturidade
Por anos, essa pergunta foi respondida de forma indireta, olhando para a velocidade: deploys frequentes, ciclos curtos, alto volume de pull requests e aumento de throughput costumavam ser sinais de um time saudável.
Essas métricas nunca foram uma medida perfeita de qualidade, mas funcionavam como indicadores razoáveis em um contexto no qual esforço humano e volume de entrega ainda caminhavam relativamente próximos.
Até pouco tempo atrás, quando a escrita do código dependia quase inteiramente do trabalho humano, havia uma relação mais estável entre o trabalho produzido e o cuidado necessário para produzi-lo. Um time que entregava mais, com ciclos menores e frequência constante, provavelmente tinha processos mais maduros, menor fricção e boa capacidade de execução. O volume não dizia tudo, mas ajudava a interpretar a saúde da engenharia.
O que a IA generativa mudou
A adoção de IA generativa mudou essa relação.
Hoje, um desenvolvedor apoiado por um agente consegue abrir múltiplos PRs em poucos minutos. O painel pode registrar mais atividade, mais entregas e mais velocidade, sem que isso represente, necessariamente, uma base de código mais saudável. O que antes era uma pista razoável de maturidade agora passou a capturar também a intensidade de uso da ferramenta.
Essa mudança cria um problema importante para quem lidera engenharia: as métricas tradicionais continuam subindo, mas parte delas deixa de responder à pergunta central sobre qualidade. Elas mostram que mais coisas estão sendo produzidas. Não mostram, sozinhas, se essas coisas melhoram ou deterioram o sistema.
O que o relatório DORA de 2026 revela
O relatório DORA de 2026 ajuda a enxergar a amplitude desse descompasso. Ao medir os efeitos da adoção de IA sobre diferentes dimensões de engenharia, o estudo identificou um ganho relevante na efetividade individual do desenvolvedor. Esse resultado é esperado: a IA ajuda a escrever, completar, revisar e acelerar partes do trabalho.
O ponto crítico está em outro efeito detectado pelo relatório: um aumento expressivo na instabilidade da entrega.
Ao mesmo tempo em que a IA torna cada pessoa mais rápida, a qualidade do código e o throughput do time apresentam ganhos limitados, aumentando o risco de instabilidade no sistema. O resultado é um descompasso: o processo acelera sem que aquilo que realmente importa melhore na mesma proporção.
Onde a fricção foi parar
Isso não significa que a IA seja ruim para engenharia. Significa que ela muda o lugar onde a fricção aparece. Parte do esforço economizado na escrita do código passa a ser gasto na validação de um código que parece correto, compila, passa em testes automatizados, mas ainda pode falhar em aspectos importantes de arquitetura, negócio, manutenção ou integração com o restante da base.
Esse efeito também não se distribui de maneira uniforme. Em códigos novos e simples, os ganhos de produtividade podem chegar a 35% ou 40%. Em bases legadas, com dependências acumuladas, decisões antigas e maior complexidade estrutural, esse ganho pode cair para 10% ou menos.
A leitura superficial dos indicadores tende a mostrar uma melhora geral. Os indicadores do painel ficam todos verdes, mas a realidade por baixo desses números é mais fragmentada. Em alguns contextos há ganho real. Em outros, há apenas mais produção sobre uma estrutura igualmente frágil.
A decepção por trás dos números verdes
Esse descompasso já aparece na percepção executiva. Em uma pesquisa recente conduzida pela Writer em parceria com a Workplace Intelligence, quase metade dos executivos relatou decepção relevante com o retorno do investimento em IA, em um movimento que cresceu de forma consistente de um ano para o outro.
O padrão é compreensível. Os indicadores tradicionais mostram aumento de atividade, mas quem opera os sistemas percebe mais retrabalho, mais revisão, mais dúvidas sobre o que foi realmente resolvido e mais dificuldade para separar velocidade real de produção inflada. Quando isso acontece, a liderança perde clareza sobre a pergunta mais importante: a engenharia está entregando melhor ou apenas entregando mais?
Métricas que medem consequência, não atividade
A resposta não está em abandonar métricas. Métricas continuam sendo fundamentais para entender fluxo, gargalos, previsibilidade e capacidade de entrega. O problema está em tratar métricas de volume como se fossem evidência direta de qualidade.
Alguns indicadores continuam úteis justamente porque medem consequências, não atividade. Falhas em produção, tempo de recuperação, volume de retrabalho e recorrência de incidentes dizem mais sobre o efeito real das entregas do que a simples contagem de PRs, deploys ou linhas de código.
Um defeito que chega ao ambiente de produção é um fato concreto, independentemente de ter sido escrito por uma pessoa ou gerado com apoio de IA.
O tempo necessário para recuperar um sistema depois de um incidente também revela algo importante sobre a compreensão da base, a robustez da arquitetura e a capacidade do time de operar aquilo que constrói.
O retrabalho segue a mesma lógica. Quando um código precisa ser refeito logo depois de ser considerado pronto, existe uma diferença entre produção aparente e entrega real. Esse cenário tende a se tornar mais frequente quando o código gerado com IA resolve o sintoma imediato, mas não considera adequadamente o contexto do sistema ou o objetivo de negócio. Por isso, a pergunta sobre qualidade precisa ir além da contagem.
O teste que separa atividade de qualidade real
Uma forma simples de testar uma métrica é perguntar se um agente de IA conseguiria inflar aquele número sem de fato gerar melhorias. Se a resposta for sim, a métrica ainda pode ter valor operacional, mas não deve ser lida como prova de qualidade.
Isso vale para número de PRs, linhas de código, volume de commits e até frequência de deploys. Esses indicadores ajudam a entender movimento. Não bastam para entender saúde. Para avaliar qualidade, é preciso observar o conteúdo do que foi entregue.
Imagine dois PRs com o mesmo cycle time, ambos aprovados no CI e registrados da mesma forma no painel. No primeiro, o desenvolvedor entendeu a causa raiz de um bug e corrigiu o problema na origem. No segundo, um agente de IA tratou apenas o sintoma, adicionou mais linhas de código, acoplou uma nova dependência e não criou testes capazes de validar o cenário de risco.
Pelas métricas de fluxo, os dois PRs podem parecer equivalentes. Em alguns casos, o segundo pode até parecer mais produtivo, simplesmente por gerar mais código. A diferença real aparece quando alguém analisa o conteúdo da entrega: um PR reduziu risco e melhorou a base; o outro apenas deslocou o problema para o futuro.
Esse é o tipo de distinção que a contagem não consegue fazer sozinha. Ela exige leitura do código, da arquitetura, dos testes, das dependências e dos efeitos acumulados sobre a base.
Ler o conteúdo significa observar sinais que nem sempre viram número de forma automática: aumento de acoplamento, duplicação de lógica, crescimento de complexidade, ausência de testes em áreas críticas, dependências mal introduzidas e soluções que resolvem o caso imediato sem preservar a qualidade estrutural do sistema.
Esses sinais ajudam a responder uma pergunta diferente daquela respondida pelas métricas de fluxo. O fluxo mostra como o time entrega, onde trava e com que velocidade avança. A leitura do conteúdo mostra o que está sendo acumulado na base a cada entrega, independentemente da velocidade.
As duas dimensões são necessárias. Sem métricas de fluxo, a liderança perde visibilidade sobre ritmo, previsibilidade e gargalos. Sem leitura do conteúdo, ela pode confundir atividade com evolução. O risco, na era da IA, é deixar que um dashboard cheio de sinais positivos esconda uma base de código que está ficando mais frágil.
Por que criamos o WeLuvCode
Foi a partir dessa leitura que criamos o WeLuvCode.
O WeLuvCode integra métricas de fluxo, extraídas do histórico do Git, com análise semântica do conteúdo do código. A proposta é oferecer à liderança uma visão que conecte velocidade de entrega com impacto estrutural sobre a base.
Na prática, isso permite identificar situações em que o cycle time caiu, mas o acoplamento nos módulos alterados aumentou na mesma proporção. Também permite observar quando uma sequência de PRs acelerou o fluxo, mas elevou complexidade, duplicação ou risco de manutenção em partes importantes do sistema.
Em outras palavras, o WeLuvCode mostra se a velocidade veio com um custo estrutural. Algo que nenhum dos dois indicadores mostraria sozinho.
Esses sinais, vistos isoladamente, podem passar despercebidos. A queda no cycle time sugere ganho de eficiência. O aumento de acoplamento sugere perda estrutural. Quando os dois aparecem juntos, a liderança consegue enxergar o custo real da velocidade.
E não se trata de uma foto pontual, mas de uma leitura contínua e automatizada. O WeLuvCode realiza uma leitura contínua e acompanha a evolução da base a cada nova entrega. Isso permite observar tendências, identificar deterioração progressiva e entender como decisões de curto prazo afetam a saúde do código ao longo do tempo.
Nossa própria experiência com IA em escala
Sobre essa fundação, estamos construindo uma camada adicional voltada especificamente para o uso de IA na engenharia. O objetivo é entender quanto do código já é assistido por ferramentas de IA generativa, qual é o custo desse uso e que nível de qualidade ele produz.
Essa convicção vem da nossa própria experiência. A Duranium é parceira oficial da Anthropic e implementa IA aplicada à engenharia no dia a dia.
Convivendo de perto com código gerado em larga escala, ficou claro que medir apenas adoção, volume ou velocidade seria insuficiente. A pergunta relevante não é apenas quanto a IA está sendo usada, mas o que ela está produzindo para a saúde da base.
O WeLuvCode nasce desse aprendizado: medir fluxo continua importante, mas a liderança também precisa ler o conteúdo do que está sendo entregue.
Da contagem ao entendimento
Para quem lidera engenharia, a recomendação não é descartar frameworks como DORA ou SPACE. Eles continuam úteis para entender desempenho, fluxo e operação. O ponto é complementar essas métricas com uma camada capaz de avaliar qualidade estrutural.
A relação histórica entre volume e valor ficou menos confiável. Com IA, um time pode produzir mais sem necessariamente melhorar o sistema. Pode reduzir cycle time e, ao mesmo tempo, aumentar retrabalho. Pode elevar o número de entregas e acumular dívida técnica silenciosa.
A liderança que quiser avaliar o impacto real da IA na engenharia precisará olhar para além da atividade gerada. Será necessário conectar fluxo, consequência e conteúdo: o que foi entregue, como isso afetou a base e quais sinais indicam melhora ou deterioração ao longo do tempo.
No fim das contas, quem vai saber se a IA está ajudando o time ou deteriorando a base de código em silêncio é quem parou de contar o que a engenharia produz e começou a entender o que cada entrega muda no sistema.