De benchmarks acadêmicos de 2026 a estudos com centenas de milhares de commits, um padrão começa a aparecer: a IA pode aumentar significativamente a velocidade de geração de código, mas esse ganho não necessariamente se traduz em software melhor ou mais sustentável no longo prazo.
Você já sentiu isso.
Você dá um prompt complexo ao seu agente de IA favorito. Em 15 segundos, ele cospe 300 linhas de código perfeitamente formatadas. Os testes unitários passam. O Pull Request é aprovado. Você se sente um engenheiro 10x.
Mas avance seis meses no tempo.
A próxima feature começa a exigir alterações em vários lugares. Uma mudança aparentemente simples quebra outra funcionalidade. Surgem funções enormes, código duplicado, abstrações inconsistentes e decisões arquiteturais difíceis de compreender.
A velocidade inicial continua parecendo impressionante.
Mas agora existe uma pergunta mais importante:
quanto dessa velocidade realmente representa ganho de produtividade e quanto representa apenas a antecipação de trabalho que alguém terá de pagar depois?
É nesse contexto que surge o que podemos chamar de AI Code Rot “apodrecimento” do código associado ao uso intensivo de IA.
Não estou afirmando que todo código produzido por IA seja ruim ou que a IA inevitavelmente destrua uma base de código. A evidência disponível não sustenta uma afirmação tão absoluta.
O que os estudos recentes sugerem é algo mais interessante:
A velocidade de geração de código pode crescer mais rapidamente do que a capacidade humana de revisar, compreender, refatorar e manter esse código.
1. O Diagnóstico Clínico: Agentes não sabem “Evoluir”
O desenvolvimento de software raramente é uma tarefa de “tiro único”.
Na prática, o processo é iterativo:
construir → testar → corrigir → refatorar → adaptar → estender → repetir.
O problema é que muitos benchmarks tradicionais de programação avaliam principalmente a capacidade de resolver uma tarefa isolada.
Mas software real não termina quando o primeiro conjunto de testes passa.
Ele precisa continuar evoluindo.
Foi justamente para investigar esse problema que pesquisadores criaram o SlopCodeBench, um benchmark desenvolvido para avaliar agentes em tarefas iterativas de longo horizonte. Em vez de simplesmente entregar uma especificação e avaliar uma solução final, os agentes precisam continuar modificando suas próprias soluções conforme os requisitos evoluem.
O resultado? Nenhum agente de IA avaliado conseguiu resolver um problema complexo do início ao fim sem degradar o código.
O estudo rastreou duas métricas fatais ao longo do tempo:
- Verbosidade: crescimento de código redundante ou excessivamente verboso.
- Erosão Estrutural: concentração crescente de complexidade em determinadas partes do código..
Isso não significa que agentes “não saibam programar”.
Eles conseguem produzir código funcional.
O problema aparece quando precisam continuar evoluindo o mesmo sistema.
Esse é um ponto fundamental.
Um agente pode produzir uma solução correta para a tarefa atual e, ainda assim, produzir uma estrutura que dificulta a próxima tarefa.
Em outras palavras:
Passar nos testes de hoje não garante que o código continuará saudável amanhã.
2. A velocidade pode esconder uma dívida de complexidade
Existe outro estudo particularmente interessante: Speed at the Cost of Quality? The Impact of LLM Agent Assistance on Software Development.
Os pesquisadores analisaram a adoção do Cursor em projetos do GitHub utilizando um desenho de diferença-em-diferenças, comparando projetos que adotaram a ferramenta com um grupo de controle semelhante.
O resultado é exatamente o tipo de fenômeno que deveria preocupar quem mede produtividade apenas pela velocidade.
A adoção do agente produziu um aumento significativo, grande e inicialmente transitório na velocidade de desenvolvimento.
Ao mesmo tempo, houve um aumento persistente em warnings(lembrando que avisos podem se tornar problemas futuros) de análise estática e complexidade do código.
Mais interessante ainda: os pesquisadores encontraram evidências de que esse aumento de complexidade contribuiu posteriormente para uma redução da velocidade.
Isso sugere um possível ciclo:
mais velocidade → mais código → mais complexidade → mais dificuldade de manutenção → menor velocidade futura.
Ou seja, a produtividade observada em uma janela curta pode esconder custos que aparecem somente depois.
A verdadeira pergunta deixa de ser:
“Quantas linhas conseguimos gerar hoje?”
e passa a ser:
“Quanto software sustentável conseguimos produzir e evoluir ao longo do tempo?”
3. A epidemia do “copiar e colar” e a morte da refatoração
Outro sinal aparece em análises longitudinais da indústria.
Um estudo da GitClear analisou mais de 211 milhões de linhas de código modificadas ao longo de vários anos e identificou mudanças importantes no perfil das alterações realizadas em bases de código durante o período de adoção dos assistentes de IA.
Entre os sinais observados estão o aumento do código clonado e uma queda significativa na proporção de alterações associadas à refatoração.
Em 2021, aproximadamente um quarto das linhas alteradas estava associado a atividades de refatoração; em 2024, essa proporção caiu para menos de 10%.
Ao mesmo tempo, a participação de código clonado aumentou significativamente.
Esses números não provam, isoladamente, que a IA causou a redução da refatoração. Existem outros fatores que podem influenciar esse comportamento.
Mas o padrão é compatível com uma hipótese preocupante:
estamos ficando cada vez melhores em adicionar código e potencialmente piores em parar para reorganizá-lo.
E esse problema não é exclusivo da IA.
A diferença é que agentes de codificação podem aumentar drasticamente a velocidade com que novas alterações são produzidas.
Quando a capacidade de geração aumenta mais rapidamente do que a capacidade de revisão e refatoração, o sistema pode acumular complexidade mais rapidamente.
4. O Cheiro do Débito Técnico (Code Smells*)*
Outro estudo recente ajuda a colocar esse problema em uma escala muito maior.
O trabalho Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild analisou a qualidade interna do código gerado por IA em repositórios do mundo real e descobriu que um boa parte do código introduz débito técnico na forma de code smells, além de bugs de runtime e falhas de segurança.
Isso não significa que “IA gera código ruim”.
Significa algo mais específico:
código gerado por IA pode introduzir problemas de qualidade que não são necessariamente corrigidos posteriormente.
E quando esses problemas permanecem, eles deixam de ser apenas pequenos defeitos locais e passam a fazer parte da história arquitetural do sistema.
É assim que a dívida técnica se acumula.
5. O problema não é que a IA seja “preguiçosa”
É tentador explicar esse fenômeno dizendo que a IA é “preguiçosa” ou que, por ser probabilística, prefere simplesmente gerar outra função em vez de procurar uma abstração existente.
Mas essa explicação é mais especulativa do que científica.
O que podemos observar empiricamente é que agentes podem produzir duplicação, aumento de verbosidade e erosão estrutural durante ciclos sucessivos de evolução.
Uma hipótese plausível é que os agentes tendam a privilegiar modificações locais que satisfazem os requisitos imediatos, enquanto decisões arquiteturais mais amplas exigem compreensão do histórico, das dependências, das restrições não funcionais e das consequências futuras.
Essa distinção é importante.
Não precisamos assumir que o modelo é “preguiçoso”.
Podemos simplesmente observar que:
resolver o requisito atual não é a mesma coisa que preservar a qualidade arquitetural do sistema para os próximos requisitos.
E esse talvez seja um dos maiores desafios do desenvolvimento de software com agentes.
6. Por que a IA não enxerga o “Quadro Geral”?
Essa afirmação precisa ser tratada com cuidado.
Não é correto dizer simplesmente que modelos de linguagem são “cegos” à arquitetura.
Agentes modernos conseguem analisar múltiplos arquivos, navegar por repositórios, executar testes, utilizar ferramentas, consultar documentação e até planejar alterações relativamente complexas.
O problema é outro.
Compreender o estado atual do código não é necessariamente suficiente para tomar boas decisões arquiteturais sobre seu futuro.
Arquitetura envolve contexto.
- decisões tomadas anos atrás;
- restrições de negócio;
- dependências implícitas;
- requisitos não funcionais;
- decisões de segurança;
- comportamento em produção;
- conhecimento tácito da equipe;
- razões pelas quais determinadas abstrações existem;
- consequências de uma mudança que talvez só apareçam meses depois.
É justamente por isso que a literatura recente sobre desenvolvimento assistido por IA vem destacando a importância da especificação, contexto e validação humana.
O problema não é simplesmente:
“a IA não entende código”.
É:
“a IA pode produzir uma alteração localmente correta que não seja a melhor decisão para a evolução global do sistema.”
Essa diferença é enorme.
7. A nova função do desenvolvedor
Existe outro efeito que talvez seja ainda mais importante do que a própria qualidade do código.
Um estudo longitudinal publicado em 2026 acompanhou profissionais de engenharia de software em dois momentos, com seis meses de intervalo. Annie Vella & Kelly Blincoe — The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study, 2026.
Os pesquisadores observaram uma mudança clara:
menos tempo escrevendo código e mais tempo verificando o trabalho produzido pela IA.
Ao mesmo tempo, os pesquisadores identificaram uma mudança mais ampla de criação para verificação e propuseram o conceito de supervisory engineering work: o trabalho necessário para direcionar, avaliar e corrigir as saídas da IA.
Isso cria um paradoxo interessante.
A produtividade percebida permaneceu alta os participantes relataram melhora mas, entre os participantes acompanhados longitudinalmente, a proporção daqueles que relataram piora em pelo menos uma dimensão da experiência de desenvolvimento praticamente dobrou.
Estudos longitudinais já identificaram aumento de carga cognitiva e mudanças na experiência de desenvolvimento.
Portanto, uma formulação mais responsável é:
A IA pode reduzir o esforço necessário para produzir código, mas isso não significa necessariamente reduzir o esforço total necessário para produzir software de qualidade.
Como Sobreviver à Era do AI Code Rot?
A IA não vai desaparecer.
E seria um erro tratá-la como inimiga.
Ela é extremamente útil para:
- protótipos;
- tarefas repetitivas;
- testes;
- documentação;
- exploração de APIs;
- geração de código inicial;
- refatorações bem especificadas;
- debugging;
- automação de tarefas mecânicas.
O problema começa quando confundimos:
gerar código
com
desenvolver software.
São coisas diferentes.
Se você é Tech Lead, Engineering Manager ou Arquiteto de Software, aqui estão três mudanças imediatas baseadas em evidências:
1 – Pare de medir apenas velocidade.
Linhas de código, quantidade de PRs e velocidade de implementação são métricas fáceis de aumentar com IA.
Mas elas não necessariamente representam produtividade sustentável.
Comece também a observar:
- complexidade;
- duplicação;
- code smells;
- churn;
- tempo de revisão;
- tempo de correção;
- defeitos pós-release;
- retrabalho;
- evolução da cobertura de testes;
- tempo necessário para modificar funcionalidades existentes.
A pergunta não deveria ser apenas:
“Quanto código produzimos?”
Mas:
“Quanto custo futuro estamos criando para produzir esse código?”
2 – A IA pode colocar os tijolos, mas o humano continua responsável pela arquitetura.
Agentes podem implementar funcionalidades.
Mas decisões arquiteturais importantes ainda precisam de supervisão adequada.
Quanto maior o impacto e a irreversibilidade de uma mudança, maior deveria ser o nível de revisão humana.
Não porque a IA seja incapaz de produzir uma boa solução.
Mas porque o custo de uma decisão arquitetural errada pode ser muito maior do que o custo de uma revisão adicional.
3 – Refatoração precisa fazer parte do processo
Se a organização aumenta drasticamente a velocidade de geração de código, precisa aumentar também sua capacidade de:
revisar → testar → observar → refatorar.
Caso contrário, a organização pode simplesmente acelerar a produção de dívida técnica.
Refatoração não deveria ser tratada como um luxo que será realizado “quando houver tempo”.
Porque, em um ambiente onde a IA produz código cada vez mais rápido, esse tempo talvez nunca apareça espontaneamente.
Ele precisa ser planejado.
A verdadeira ilusão da velocidade
Talvez a maior ilusão da era dos agentes de programação seja acreditar que:
se conseguimos escrever código 10 vezes mais rápido, conseguimos desenvolver software 10 vezes mais rápido.
Não necessariamente.
Software não é apenas código.
Software também é:
arquitetura + testes + revisão + integração + observabilidade + documentação + manutenção + evolução.
Se a IA acelera apenas a produção de código, mas não acelera na mesma proporção todas as outras etapas, o gargalo simplesmente muda de lugar.
E os estudos recentes começam justamente a mostrar isso.
Agentes podem aumentar a velocidade inicial.
Mas essa velocidade pode vir acompanhada de maior complexidade, mais verbosidade, erosão estrutural, problemas de qualidade e uma mudança significativa do trabalho humano para supervisão e verificação.
Portanto, talvez a pergunta mais importante para a engenharia de software na era da IA não seja:
“Quanto código a IA consegue escrever?”
Mas:
“Quanto software de qualidade conseguimos continuar evoluindo depois que a IA escreveu esse código?”
Essa é uma pergunta muito mais difícil.
E provavelmente é nela que estará a verdadeira disputa pela produtividade nos próximos anos.
A IA pode ser o estagiário mais rápido do mundo.
Mas velocidade não substitui arquitetura, julgamento e responsabilidade.
Se nós aumentarmos a velocidade de produção sem aumentar nossa capacidade de revisão e evolução, talvez não estejamos construindo software mais rápido.
Talvez estejamos apenas construindo mais rápido o software que teremos de consertar amanhã.
Referências:
GitClear — estudo longitudinal sobre qualidade e evolução do código assistido por IA.