Principais destaques
- Mais código nem sempre é melhor: agentes de programação podem entregar funcionalidades rapidamente, mas também aumentar a complexidade e o custo de manutenção.
- O acúmulo acontece aos poucos: soluções redundantes, funções desnecessárias e padrões diferentes transformam projetos organizados em bases difíceis de entender.
- Excluir exige tanto critério quanto criar: a IA pode identificar código aparentemente inútil, mas testes e revisão humana continuam essenciais para evitar problemas inesperados.
Os agentes de inteligência artificial estão mudando a maneira como desenvolvedores criam software. Ferramentas como Claude Code, Cursor e Codex conseguem implementar funcionalidades, corrigir erros e modificar projetos inteiros a partir de instruções em linguagem natural.
O ganho de produtividade é evidente. Mas existe um efeito colateral menos discutido: quanto mais fácil fica adicionar código, maior é o risco de acumular código que não precisava existir.
A questão não é que os agentes sejam incapazes de programar. É que escrever uma solução funcional e decidir se ela realmente deveria fazer parte do projeto são tarefas diferentes.
🧩 O agente termina a tarefa. Mas o projeto fica melhor?
Quando um desenvolvedor pede à IA para implementar uma funcionalidade, existe um objetivo relativamente simples de verificar. O recurso funciona? A validação está correta? O erro desapareceu?
Se tudo der certo, a tarefa pode ser considerada concluída.
O problema começa quando esse critério se torna a única medida de sucesso.
Um agente pode entregar exatamente o que foi solicitado e, ao mesmo tempo, criar novas funções, adicionar dependências e espalhar a lógica por vários arquivos. A funcionalidade funciona, mas o projeto fica mais difícil de manter.
🔎 A diferença está no que não aparece no teste: o resultado imediato pode ser excelente, enquanto a estrutura interna do software se torna progressivamente mais complicada.
Isso também ajuda a explicar por que uma alteração aparentemente pequena pode acabar exigindo mudanças em diversas partes de uma aplicação.
Cada nova funcionalidade deixa uma conta para pagar
Imagine um projeto que começa com uma estrutura simples. Há componentes bem definidos, funções reutilizáveis e padrões consistentes.
Depois de algumas semanas trabalhando com agentes de IA, novas funcionalidades são adicionadas. Cada solicitação é resolvida isoladamente, mas nem sempre respeita as decisões arquiteturais anteriores.
Uma ferramenta cria uma função auxiliar. Outra implementa uma lógica semelhante em outro arquivo. Uma terceira adiciona uma camada de abstração para resolver um problema que poderia ter sido tratado de forma mais direta.
Individualmente, as decisões podem parecer razoáveis.
O conjunto, porém, conta outra história.
📦 O efeito acumulativo: o código passa a ter várias maneiras de resolver problemas semelhantes. Para entender uma funcionalidade, o desenvolvedor precisa percorrer mais arquivos, identificar dependências e descobrir por que determinadas decisões foram tomadas.
Esse tipo de deterioração pode acontecer sem erros evidentes, telas quebradas ou falhas que interrompam a execução.
O software continua funcionando. Só que trabalhar nele começa a custar mais.
O código que funciona também pode ser desnecessário
Existe uma diferença importante entre código mal escrito e código que não deveria existir.
O primeiro pode precisar de uma refatoração. O segundo pode simplesmente ser eliminado.
Uma função perfeitamente implementada, por exemplo, não agrega valor se nenhuma parte do sistema precisa dela. Uma biblioteca adicional pode funcionar sem problemas e ainda assim ser dispensável. E uma camada de abstração pode aumentar a complexidade sem oferecer benefícios proporcionais.
💡 O verdadeiro desperdício não é apenas escrever código ruim. É gastar tempo criando, testando e mantendo código que não entrega valor ao produto.
Essa distinção importa especialmente em projetos que recebem mudanças frequentes. Cada função, condição e dependência adicional representa mais um elemento que precisa ser considerado nas próximas alterações.
O custo não está restrito ao momento da implementação. Ele acompanha o projeto.
Quando a velocidade de hoje vira o trabalho de amanhã
Uma funcionalidade criada em minutos pode economizar horas no curto prazo. Mas, se sua implementação introduzir dependências desnecessárias ou duplicar comportamentos existentes, as próximas alterações poderão exigir uma investigação muito maior.
É uma espécie de dívida técnica que não aparece necessariamente na entrega inicial.
E existe um agravante: quanto mais código se acumula, mais difícil pode ser distinguir o que é essencial daquilo que foi criado por conveniência.
✂️ Por que apagar código é mais difícil do que escrevê-lo
Esse é o ponto em que a participação humana continua fazendo diferença.
Um agente pode procurar funções não utilizadas, examinar dependências e sugerir trechos que parecem dispensáveis. O problema é transformar essa análise em uma decisão segura.
Uma função aparentemente sem referências pode ser chamada dinamicamente. Um método pode ser utilizado por uma integração externa. Um arquivo pode ser necessário em um processo de compilação ou em uma rotina executada apenas em determinadas condições.
Portanto, ausência de uso evidente não significa necessariamente ausência de utilidade.
🛠️ O trabalho precisa ir além da busca automática: identificar candidatos à remoção, entender seu contexto, verificar dependências e testar o comportamento da aplicação antes de aceitar as alterações.
Ou seja, o Claude Code poderia examinar um projeto de gerenciamento hospitalar e identifica sete métodos aparentemente não utilizados. A ferramenta propõe a remoção de aproximadamente 130 linhas, explicando os motivos para a exclusão e solicitando autorização antes de prosseguir.
O caso ilustra uma aplicação útil dos agentes: eles podem acelerar a investigação e organizar uma proposta de limpeza. Mas a identificação automática não deve ser confundida com uma garantia de que a exclusão é segura.
O que um agente deveria fazer antes de adicionar mais código?
A lógica de trabalho pode ser invertida. Em vez de tratar toda solicitação como uma oportunidade para criar algo novo, o agente também pode avaliar o que já existe.
Antes de implementar uma funcionalidade, uma revisão bem orientada deveria responder a algumas perguntas:
- Já existe uma solução? Verificar se o projeto possui uma função, um componente ou uma dependência que resolva o problema.
- A mudança pode ser menor? Priorizar alterações localizadas em vez de criar novas camadas sem necessidade.
- Existe duplicação? Identificar comportamentos semelhantes que possam ser reaproveitados com segurança.
- O que pode ser removido? Avaliar código obsoleto, caminhos redundantes e dependências que deixaram de ser necessárias.
- Como comprovar que nada foi quebrado? Executar testes relevantes e comparar o comportamento antes e depois da alteração.
Esses critérios não eliminam a necessidade de revisão humana. Eles tornam a própria IA mais útil durante a análise e ajudam a evitar que cada tarefa deixe uma nova camada de complexidade para a próxima.
A próxima evolução não depende apenas de escrever melhor código
O avanço dos agentes de programação costuma ser associado à capacidade de produzir mais código, resolver problemas complexos e executar tarefas com menos intervenção humana.
Mas existe outra dimensão de qualidade: a capacidade de reconhecer quando uma mudança não é necessária.
Isso exige mais do que gerar uma implementação que passe nos testes. Exige compreender as convenções do projeto, considerar as consequências das alterações e avaliar se a solução proposta é proporcional ao problema.
Para quem desenvolve plugins, aplicações ou sistemas que evoluem continuamente, essa diferença é especialmente relevante. A velocidade de implementação só representa um ganho real quando não é acompanhada por um aumento desproporcional no esforço de manutenção.
A pergunta que fica é outra: quando os agentes conseguirem escrever código cada vez mais rápido, eles também serão capazes de demonstrar que a melhor solução era não escrever nada?
