O código duplicado que a IA cria enquanto parece produtiva
A confiança na IA não começa no modelo, começa no processo.
Esta é a terceira parte de uma série sobre a metodologia que uso para continuar sendo, de fato, o responsável pelo que um agente de IA produz: o caso aplicado do artigo anterior, sobre por que a disciplina nasce em rajada.
Se alguém te perguntasse, agora, quantos trechos de código funcionalmente idênticos existem espalhados pelo seu projeto, você saberia responder? Ou só saberia dizer que “provavelmente não muitos, a gente tenta reaproveitar”?
Disclaimer: este texto reflete minha visão prática sobre o tema, construída em projetos pessoais e profissionais. Não representa, necessariamente, a posição oficial de nenhuma organização à qual eu esteja afiliado.
Essa pergunta ficou mais difícil de responder com confiança desde que agentes de IA passaram a escrever boa parte do código novo. Não é porque a IA seja descuidada. É porque ela é rápida o suficiente para que duplicar pareça, no momento, indistinguível de produtividade.
A GitClear vem publicando, em relatórios sucessivos desde 2025, análises de centenas de milhões de linhas de código alteradas em repositórios reais. O relatório de 2025 já registrava um marco: 2024 foi o primeiro ano da série em que “copiar e colar” superou “mover código” como padrão dominante.
A edição mais recente, de 2026, analisou 623 milhões de mudanças entre 2023 e 2026, e o retrato piorou a cada nova leitura. A proporção de linhas classificadas como “copiar e colar” subiu de 9,4% em 2022 para 15,7% no primeiro semestre de 2026, um crescimento de 67%.
No mesmo período, a conectividade entre funções (quantas vezes um código novo chama uma função já existente em vez de reescrevê-la) caiu 35%, de 343 para 223 chamadas a cada mil linhas alteradas. E a proporção de mudanças que atualizam código com mais de doze meses (sinal de manutenção de longo prazo, não só produção de código novo) caiu 74% desde 2023.
Em 2022, refatorar era a escolha preferida sobre duplicar, numa proporção de 2 para 1. Essa preferência não só desapareceu: o relatório mede a virada como um salto de cerca de 5 vezes na chance relativa de duplicar em vez de refatorar, comparado à proporção de 2022. É uma medida de quanto a preferência mudou, não uma taxa absoluta de duplicação.
O próprio relatório aponta duplicação de bloco como o sinal isolado com correlação mais direta a defeitos, segundo a literatura acadêmica. Não crava uma taxa específica, mas o sinal em si já está 81% mais alto do que em 2023.
Por que isso acontece, mesmo com um agente competente
Um agente de IA não duplica código por preguiça ou por falta de capacidade técnica de generalizar. Duplica porque, sem instrução em contrário, o caminho de menor resistência para resolver uma tarefa isolada é escrever a solução mais direta para aquele pedido específico.
E o código mais direto para resolver um problema pontual, visto isoladamente, frequentemente já existe em outro lugar do projeto, resolvendo um problema quase idêntico sob um nome diferente.
Encontrar essa duplicata exigiria que o agente parasse, procurasse deliberadamente por padrões já existentes, e avaliasse se vale a pena generalizar. É um passo a mais que ninguém pediu explicitamente, e que compete, em cada tarefa, contra a pressão implícita de entregar rápido.
Isso não é um problema específico de IA. É o mesmo problema que qualquer desenvolvedor enfrenta, ampliado pela velocidade. A diferença é que um humano duplica algumas vezes por sprint. Um agente de IA, gerando volume de código muito maior no mesmo período, pode duplicar dezenas de vezes antes que qualquer revisão humana perceba o padrão, porque cada duplicata, olhada isoladamente, parece uma solução razoável para o problema que tinha na frente.
Isso é exatamente o que se acumula no intervalo que descrevi no artigo anterior
No artigo anterior desta série, expliquei por que a disciplina pesada só se justifica depois de um evento de risco, e por que, mesmo assim, as três práticas mais baratas (guardrails fixos, prova em vez de crença, registro de decisão com prazo curto) já deveriam estar rodando desde o primeiro commit.
Duplicação de código é o exemplo mais concreto que conheço de uma dívida (Risco) que se acumula apesar dessas três práticas já estarem ativas, porque nenhuma delas, sozinha, foi desenhada para pegar esse problema específico.
Pensar antes de codificar evita um mal-entendido sobre o pedido, não uma duplicata de uma função que já existe em outro arquivo. Provar que um bug foi corrigido não diz nada sobre se a correção reaproveitou algo existente ou reescreveu do zero. E um ADR registra uma decisão de arquitetura, não decide, sozinho, se duas funções parecidas deveriam virar uma só.
O que falta é um guardrail específico (checar o que o próprio projeto já faz para problemas parecidos antes de escrever uma solução nova), que vou descrever com mais profundidade no próximo artigo desta série, sobre as práticas que nunca esperam gatilho.
Por ora, o que importa é a forma como ele resolve esse problema específico: antes de escrever uma implementação nova, a instrução padrão passa a ser perguntar “já existe algo parecido em outro lugar do projeto?” Se existir, a decisão passa a ser explícita entre generalizar ou manter as duas versões separadas, em vez de deixar a duplicação acontecer por padrão, sem que ninguém tenha decidido nada.
Recebi, mais de uma vez, um retorno explícito desse guardrail em ação, numa forma um pouco diferente da usual: “já existe uma função parecida em outro lugar do projeto, resolvendo um problema quase idêntico. Quer que eu generalize essa em vez de criar uma nova, ou existe uma razão para manter as duas separadas?” Isso transforma duplicação de um acidente silencioso em uma decisão explícita, com um responsável.
Duplicação como hipótese a medir, não sensação a confiar
“Nosso código está razoavelmente livre de duplicação” é exatamente o tipo de crença confortável que raramente é verificada até doer.
Ferramentas de detecção de clones existem há décadas. O que costuma faltar não é a ferramenta, é o hábito de rodá-la com a mesma regularidade que se roda qualquer outra verificação, e tratar o resultado com a mesma seriedade: uma hipótese sobre o estado do código, que ou se confirma, ou não.
A auditoria com frentes independentes que descrevo mais à frente nesta série é o lugar natural para incluir essa medição como rotina, não como reação a um problema que já apareceu visível.
Na prática
Antes de qualquer implementação nova, pergunte explicitamente se algo parecido já existe. Não como checklist burocrático: a pergunta “isso já existe em algum lugar?” custa segundos e evita horas de manutenção duplicada depois.
Trate duplicação intencional como decisão documentada, não como exceção silenciosa. Às vezes copiar é mesmo a escolha certa: dois contextos que parecem iguais hoje podem divergir de propósito amanhã. A diferença entre isso e dívida técnica acidental é, de novo, inteiramente uma questão de ter sido uma decisão consciente ou um acidente que ninguém percebeu.
Meça duplicação periodicamente, não só quando alguém desconfia dela. Uma métrica que você só olha quando já suspeita de problema não é uma métrica: é uma confirmação tardia de algo que já estava ruim há tempo.
Desconfie especialmente de volume alto de código novo em pouco tempo. Não porque volume seja ruim, mas porque é exatamente a condição em que duplicação silenciosa tem mais espaço para se acumular sem ser notada. O mesmo ritmo que faz um agente de IA parecer produtivo é o que torna mais fácil não perceber o padrão se repetindo.
Conclusão
A promessa de um agente de IA é velocidade. O risco, se ninguém desenha o processo em volta dela, é que essa velocidade vire volume, e volume, sem disciplina de reuso, vire dívida técnica que ninguém decidiu contrair: aconteceu uma tarefa isolada de cada vez, cada uma parecendo razoável no momento em que foi escrita. Os números do GitClear não são uma previsão distante: são o que já está acontecendo, medido em centenas de milhões de linhas reais.
No próximo artigo desta série, volto ao nível estrutural: as três práticas que nunca esperam gatilho, incluindo a definição formal do guardrail que já apareceu aqui em ação: avaliar um padrão antes de adotá-lo, a régua que também resolve o problema descrito neste texto.
Tenham um excelente dia!
Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável. Como arquiteto sênior, aproveito meus mais de 30 anos de experiência em arquitetura e desenvolvimento de software para projetar e implementar soluções baseadas em nuvem que ajudam os clientes a transformar seus negócios com tecnologia.
Este texto foi escrito com apoio do Claude Code, a partir da minha experiência, minhas decisões e revisão: o próprio processo que a série descreve.
Nesta série
- Metodologia de Desenvolvimento Assistido por IA Centrada na Decisão Humana
- Disciplina em rajada: por que o rigor não nasce junto com o código
- O código duplicado que a IA cria enquanto parece produtiva (este artigo)
- As três práticas que nunca esperam gatilho
- Quem autorizou essa atualização de dependência? Pode ter sido sua IA
- Os quatro eventos de risco e a auditoria multi-frente
- Seu agente de IA resolve a issue de verdade, ou só parece resolver?
- ADRs em lote, e a regra da visibilidade
- IA no time não reduz o bus factor do seu projeto — pode aumentar
- Calibrando a intensidade ao risco real
- O alinhamento entre produto e engenharia começa onde a decisão fica registrada
- Segurança psicológica também vale para o time formado por você e sua IA
- Releitura: o papel do humano, os sinais que funcionam, e onde a metodologia ainda é fraca
Referências citadas
- GitClear, “AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones” (2025): https://www.gitclear.com/ai_assistant_code_quality_2025_research
- GitClear, “The Maintainability Gap: 2026 AI Code Quality Research” (2026): https://www.gitclear.com/the_ai_code_quality_maintainability_gap
