Na era da codificação com IA, bons hábitos de programação continuam importantes

Recentemente, ao fazer um benchmark de Agentes, percebi que não se pode avaliar a complexidade de uma tarefa de programação para IA apenas do ponto de vista do desenvolvedor.
Por exemplo, uma tarefa de refatoração: dividir um arquivo grande de várias milhares de linhas em mais de dez pequenos módulos por funcionalidade.
Essa tarefa, para um desenvolvedor, na verdade, não é difícil; o trabalho principal é mover código, organizar imports, validar a compilação, o que até um iniciante consegue fazer.
Por isso, pensei em usar uma tarefa simples para fazer um benchmark, mas o resultado foi surpreendente.
Claude Code achou que essa tarefa era grande, tentou dividir uma parte, fez um PR e escreveu um Future work planejando fazer em etapas.
Meu próprio agente é “forçar a barra”, avançando mais na direção de uma divisão completa, mas o custo também é evidente: o consumo de tokens é dezenas de vezes maior que o do Claude, e grande parte do tempo é gasta lendo arquivos repetidamente, corrigindo erros de compilação, lendo novamente, corrigindo mais erros.
Isso me fez perceber que tarefas que parecem simples para as pessoas, nem sempre são simples para o Agente.
Para o humano, essa espécie de refatoração muitas vezes é só “mover esse trecho para lá”. Mas para o Agente, ele precisa primeiro ler o arquivo em partes, lembrar quais funções e testes estão relacionados, depois gerar uma série de modificações entre arquivos, e por fim, ir corrigindo os erros de compilação aos poucos.
Parece uma tarefa mecânica, mas na prática se torna uma tarefa de alto custo de tokens e gerenciamento de estado.
Recentemente, vi alguém dizer que, na era da codificação com IA, princípios de programação como divisão em módulos não são tão importantes, já que as pessoas também não olham o código.
Agora, acho que não concordo muito. Ter limites de módulo bem definidos, arquivos com granularidade adequada e dependências simples não só facilita a leitura humana, mas também ajuda a reduzir a complexidade da tarefa para o Agente.
Por outro lado, os ferramentas de leitura e edição de arquivos do Agente atualmente não são muito amigáveis para esse tipo de refatoração.
Quando um Agente de codificação modifica arquivos, geralmente faz substituições de texto. Por exemplo, Claude Code costuma usar o padrão old_string / new_string: primeiro fornece um trecho de texto antigo, depois substitui pelo novo.
Codex costuma usar apply_patch: gera um patch semelhante ao git diff, que expressa a substituição do conteúdo antigo pelo novo.
Ambos funcionam bem para pequenas modificações, mas se for necessário deletar uma grande porção de código antigo ou mover várias funções para outros arquivos, o modelo geralmente precisa primeiro ler o conteúdo original no contexto, depois gerar uma grande substituição ou diff.
Por isso, depois, dei uma dica ao Agente: usar scripts, sed, perl ou ferramentas similares para dividir grosseiramente o arquivo grande, deletar o conteúdo antigo e escrever no novo arquivo, depois ir ajustando aos poucos.
A sua taxa de sucesso realmente aumentou bastante.
Por padrão, o Agente não faz assim, principalmente porque o sistema de prompts força o Agente a usar ferramentas internas para modificar arquivos, e não comandos de linha de comando.
Pensando um passo adiante, talvez o Agente de codificação precise de ferramentas de edição mais avançadas.
Não apenas uma interface de “substituir texto”, mas criar uma estrutura de código usando parser, LSP ou compilador, permitindo que o Agente faça refatorações como um IDE: mover funções, deletar blocos de implementação, organizar imports.
Não sei se alguém já tentou algo assim.
No geral, mesmo na era da codificação com IA, bons hábitos de programação ainda têm valor.
Tentar, desde cedo, através de engenharia de harness, transformar bons hábitos na forma padrão de trabalho do Agente é muito mais barato do que fazer refatorações posteriores.