Churn de Código de 861%: O Que Você Entregou no Último Trimestre Sobreviveu?

O churn de código subiu 861% entre trimestres de baixa e alta adoção de IA na telemetria 2026 da Faros AI, que cobre 22.000 desenvolvedores em mais de 4.000 times. A métrica é a razão entre linhas deletadas e linhas adicionadas em código mergeado por trimestre, e ela roda agora a 9,6 vezes a taxa anterior. A legenda da própria Faros é direta: “O churn de código é o asterisco em cada número de output desta seção.” O throughput de tarefas por desenvolvedor subiu 33,7% no mesmo conjunto de dados. A conclusão de épicos subiu 66,2%. O asterisco paira sobre tudo isso, porque uma fração crescente do que é mergeado é deletada pouco depois.

Cobrimos o lado de qualidade desse relatório, as taxas de defeito e a carga de revisão, em o chicote da aceleração e o trabalho de verificação. Este texto fica no número de churn, porque ele levanta uma pergunta que dashboards de velocidade nunca respondem e que a maioria das organizações de engenharia hoje também não consegue responder: o código que você entregou no último trimestre sobreviveu?

Uma Métrica Ambígua por Construção

Entenda como o número é construído antes de decidir o que ele significa. A Faros calcula o churn como deleções sobre adições, para código mergeado, por trimestre, a partir de metadados de repositório em milhares de organizações clientes. Essa construção carrega um ponto cego de fábrica: ela conta linhas deletadas sem saber a idade delas.

Um trimestre é uma janela larga. Uma linha deletada em março pode ter sido escrita em fevereiro por um agente, ou em 2019 por um engenheiro que já saiu da empresa. A métrica trata as duas deleções de forma idêntica. A Faros é explícita: pesquisa observacional entre clientes, nesse nível, não resolve a ambiguidade. O que ela detecta é que algo grande está se movendo.

E algo grande está se movendo. Um aumento de 9,6x na razão de deleção significa que o formato do trabalho de engenharia mudou sob adoção de IA. O que mudou é a pergunta em aberto, e existem três respostas candidatas.

Três Histórias, Um Número

A Faros nomeia três explicações e afirma que as três são consistentes com os dados.

A primeira é o retrabalho do tipo aceita-e-substitui. Desenvolvedores aceitam código gerado por IA rapidamente, entregam, e voltam para substituí-lo quando ele se mostra insuficiente na prática. A deleção acontece dentro da mesma janela de medição da adição. Isso é desperdício real: os números de throughput contaram código que não durou um trimestre, e a aceleração que todo mundo está celebrando é em parte uma esteira.

A segunda é a história otimista. A IA tornou grandes projetos de refatoração baratos o suficiente para ganhar equipe. Sistemas legados acumulados por anos estão finalmente sendo substituídos, e o volume de deleção reflete trabalho arquitetural produtivo. Nessa história, os 861% são o melhor número do relatório: a indústria está pagando uma década de manutenção adiada.

A terceira fica entre as duas. A IA acelera o ritmo em que engenheiros voltam para melhorar código com o qual nunca ficaram plenamente satisfeitos. Nem desperdício, nem onda de refatoração, apenas iteração mais rápida sobre código sabidamente mediano.

O que está em jogo ao separá-las é orçamentário, e a resposta muda decisões. Se a sua organização está na história um, seus ganhos de velocidade estão superestimados e o seu harness de IA precisa de trabalho antes do merge. Se está na história dois, você deveria financiar mais refatoração enquanto a janela está aberta. O mesmo número de dashboard recomenda investimentos opostos dependendo de qual história é verdadeira, e a métrica como entregue não diz qual é.

A Tendência Corroborante Aponta em Uma Direção

A GitClear analisou 211 milhões de linhas alteradas entre 2020 e 2024 e publicou os resultados em fevereiro de 2025. A fatia de código novo revisado em até duas semanas depois de escrito cresceu de 3,1% em 2020 para 5,7% em 2024. Código revisado em duas semanas é jovem demais para ser refatoração de legado; essa fração é retrabalho por construção. O mesmo estudo encontrou blocos duplicados de cinco ou mais linhas crescendo 8x em 2024, e código copiado e colado subindo de 8,3% para 12,3% das linhas alteradas, enquanto linhas “movidas”, a assinatura de refatoração e reuso, caíram 39,9%. 2024 foi o primeiro ano do conjunto de dados em que código copiado superou código movido.

O estudo de janeiro de 2024 da GitClear, sobre um corpus anterior de 153 milhões de linhas, já projetava que o churn dobraria em 2024 contra a linha de base pré-IA de 2021. A projeção acertou a direção antes de a telemetria da Faros fazê-la parecer conservadora.

Uma ressalva pertence aqui: a GitClear constrói um produto de análise de código e a Faros vende ferramentas de inteligência de engenharia, então as duas empresas se beneficiam quando os dados revelam problemas que seus produtos endereçam. Leia os percentuais exatos com isso em mente. A direção, porém, aparece em dois conjuntos de dados independentes com metodologias diferentes, e a janela de duas semanas nos dados da GitClear enfraquece especificamente a história de refatoração pura. Isso ainda não resolve a questão para a sua organização. Só o seu próprio histórico Git resolve.

O Método: Proveniência, Janelas, Durabilidade

Resolver a ambiguidade localmente custa alguns dias de engenharia, e a própria Faros aponta o mecanismo: proveniência de linhas no nível do Git. Aqui vai a versão concreta.

Estreite a janela. Calcule a razão deleção-adição por repositório em intervalos mensais, e abandone o trimestre. Uma janela de um mês restringe onde o código deletado pode ter nascido e transforma uma média trimestral vaga em um sinal que você consegue alinhar com projetos, migrações e incidentes específicos. Rode sobre os últimos 12 meses para ter uma linha de base anterior à rampa de adoção de IA, se o seu histórico alcançar.

Date as linhas deletadas. Para os meses de maior churn, pegue as linhas deletadas e pergunte quando foram escritas. Um git blame no commit pai de cada commit que deleta entrega a data de nascimento de cada linha que morreu. Agrupe as idades: linhas com menos de 60 dias na deleção são retrabalho; linhas com mais de um ano são refatoração de legado; a faixa do meio é a sua história de iteração sobre código mediano. Esse único histograma é a análise que a Faros diz que resolveria a ambiguidade da própria manchete, e quase ninguém o roda.

Adicione uma métrica de durabilidade. O churn mede deleções olhando para trás. A durabilidade olha para frente: das linhas que você mergeou há N dias, qual percentual continua vivo no HEAD? Escolha N em 90 dias e calcule por repositório, por time e, se você marca pull requests assistidos por IA, por modo de autoria. Essa é a taxa de sobrevivência do código entregue, e ela pertence ao lado de cada número de velocidade que você reporta. Um time que mergeia 30% mais código com sobrevivência de 90 dias caindo de 92% para 70% não acelerou.

A interpretação segue do formato. Retrabalho concentrado em repositórios ou times específicos aponta para um problema de harness: prompts, contexto, profundidade de revisão ou seleção de tarefas naquelas áreas. Deleções dominadas por linhas antigas em muitos repositórios são uma onda de refatoração, e a resposta certa é financiá-la. Uma faixa do meio crescente sugere que iterar ficou genuinamente mais barato, o que é aceitável enquanto o número de durabilidade se sustentar.

A conexão com compreensão é direta. Código que os engenheiros não entenderam plenamente na hora do merge é exatamente o código que é substituído quando encontra a produção, uma dinâmica que examinamos em compreensão é o gargalo. E o volume que alimenta esse pipeline segue crescendo, como mostra o tsunami de código chegando à produção. O churn é onde essas duas pressões viram algo mensurável no seu próprio histórico.

Faça Isso Agora

Escolha seus três repositórios de maior volume de merge. Para cada um, rode a razão deleção-adição mensal do último ano e marque os dois meses de maior churn. Para esses meses, date as linhas deletadas com git blame contra os commits pais e agrupe: menos de 60 dias, de 60 dias a um ano, mais de um ano. Você agora sabe em qual das três histórias está, por repositório, com evidência.

Depois torne a durabilidade uma métrica permanente. Reporte a sobrevivência de linhas em 90 dias ao lado do throughput na revisão que o seu time já faz. Quando alguém apresentar um ganho de velocidade, o número de sobrevivência é o asterisco, tornado visível.

Times que não conseguem responder “o que entregamos sobreviveu?” estão reportando velocidade, não progresso. A resposta custa alguns dias de um engenheiro. A ambiguidade custa cada ciclo de planejamento em que fica sem resolução.

---

Fontes

• Faros AI. “AI Engineering Report 2026: The Acceleration Whiplash.” Abril de 2026.
• GitClear. “AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones.” Fevereiro de 2025.
• GitClear. “Coding on Copilot.” Janeiro de 2024.

A Victorino ajuda times de engenharia a instrumentar proveniência de linhas e durabilidade de código na entrega assistida por IA: contato@victorino.com.br | www.victorino.com.br