O código sai em 40 segundos. O que some é a refatoração.

Escrever código nunca foi a parte cara do trabalho. A parte cara é manter aquilo funcionando enquanto o negócio muda, a equipe troca e o sistema acumula onze anos de decisões que ninguém documentou. Uma análise de larga escala publicada em 2025 mostra que a ferramenta que acelerou a parte barata está, ao mesmo tempo, reduzindo a prática que segura a parte cara.

O que os dados mostram

A GitClear analisou 211 milhões de linhas alteradas entre janeiro de 2020 e dezembro de 2024. Dois números do levantamento importam mais que os outros:

E um marco: 2024 foi o primeiro ano registrado em que copiar e colar superou mover código — ou seja, em que duplicar passou a ser mais comum que reorganizar.

Antes de seguir, o incentivo: a GitClear vende plataforma de análise de código. Um relatório que aponta queda de qualidade de código serve ao produto dela. Isso não invalida a medição — é dado de repositório, não opinião de survey —, mas sobe a régua sobre o método, e o método aqui está declarado: linhas alteradas, período definido, categorias explícitas.

Por que refatorar é o que segura o sistema

Refatorar é reorganizar o que já existe sem mudar o que ele faz. É a atividade que mantém um sistema compreensível conforme ele cresce — e é a primeira coisa que se corta quando há pressa, porque não produz nada visível para quem está de fora.

Quando a proporção de refatoração cai enquanto a de duplicação sobe, o resultado não é neutro. O sistema fica maior e mais difícil de mudar ao mesmo tempo. A mesma alteração que levaria um dia passa a levar duas semanas, porque agora ela precisa ser feita em quatro lugares — e quem faz precisa antes descobrir que os quatro lugares existem.

Esse custo não aparece na velocidade de entrega. Aparece meses depois, na estimativa que estourou, no bug que voltou, no incidente às três da manhã em que alguém descobre que a correção aplicada em janeiro não foi aplicada na cópia.

A demo não tem legado

É aqui que a demonstração engana, e não por má-fé: ela é honesta sobre o que mostra.

Numa demonstração, o problema é novo, o código é limpo, não há integração com um sistema de 2014, ninguém depende daquele comportamento estranho que virou contrato implícito. Sob essas condições, escrever é de fato quase todo o trabalho, e a ferramenta é impressionante.

Em produção, escrever é a menor parte. A maior é entender o que já existe antes de acrescentar. E é justamente aí que a sugestão automática tem menos contexto: ela não sabe que aquele campo é preenchido por um processo noturno, nem que aquela função foi deixada assim de propósito depois de um incidente.

Aceitar a sugestão é rápido. Verificar se ela cabe no que existe é o trabalho — e é o passo que a pressa remove.

O que medir em vez de velocidade

Se o seu time adotou assistente de código e você quer saber se valeu, pare de medir tempo até o código existir. Meça:

1. Tempo até produção estável — do início ao ponto em que ninguém precisa voltar naquilo por duas semanas.
2. Proporção de mudanças que exigem tocar em mais de um lugar — é o sintoma direto de duplicação acumulada.
3. Tempo que um recém-chegado leva para fazer a primeira alteração sozinho — mede se o sistema continua compreensível.

Nenhuma das três é rápida de coletar, e é por isso que quase ninguém coleta. Mas são elas que dizem se o sistema está ficando melhor ou apenas maior.

Não estou defendendo que se largue a ferramenta — ela resolve problema real, e o ganho na parte chata é verdadeiro. Estou dizendo que a conta que está sendo apresentada tem só um lado. O código sai em 40 segundos. A pergunta é quem vai mantê-lo em 2029, e com qual mapa.

Marta respondeu a esta coluna: “As três métricas do Rui são ótimas. Nenhum time vai coletar.”.