Claude Code e subagentes reduzem a reescrita de um projeto legado de três meses para uma semana

A diferença entre três meses e uma semana nesta história não se explica por os modelos terem passado a escrever código perfeito, e sim porque o autor deixou de usar a IA como um autocompletar inteligente e a transformou em uma esteira de engenharia completa. Com dois projetos Go da mesma escala, ele mostra que, quando o legado é destrinchado à mão e por intuição, a velocidade esbarra no caos. Quando o modelo tem papéis, procedimentos, revisão e um circuito de testes, a reescrita de um monólito acelera várias vezes.

Há um ano, o ponto de partida era a dívida técnica pós-MVP, familiar a muita gente. O projeto tinha um único main.go de cerca de duas mil linhas, onde lógica de negócio, configuração, handlers HTTP, acesso ao banco e outros elementos auxiliares estavam todos misturados. Uma estrutura assim pode sobreviver ao lançamento inicial de um produto, mas aguenta mal o crescimento: qualquer mudança arrasta efeitos colaterais, o código é difícil de dividir em áreas de responsabilidade e os testes deixam de ser um apoio para virar mais uma dor de cabeça. O autor lembra que, na época, levou o sistema a uma arquitetura decente aos poucos, com testes caseiros e reconferência manual constante.

Ele fez a primeira refatoração no Cursor e gastou cerca de três meses nela. Foi um processo cuidadoso, quase cirúrgico: extrair um bloco, verificar se o comportamento quebrou e só então passar ao próximo.

Um projeto recente da mesma escala deu um resultado bem diferente. O autor pegou o Claude Code com o modelo Opus, conectou três subagentes revisores e montou ao redor deles cerca de trinta skills, cenários repetíveis para operações típicas. A reescrita levou uma semana, e uma parte considerável desse tempo foi gasta não na migração do código em si, mas na camada de BDD sobre a implementação. Pela estimativa dele, sem os cenários em godog a tarefa poderia ter levado cerca de três dias.

O ponto do artigo não é que uma ferramenta específica tenha se mostrado melhor que outra, mas que o autor mudou a forma de trabalhar. Ele contrapõe sua prática aos conselhos populares do tipo "dê um bom prompt à rede neural e espere o resultado". No legado real, isso não basta: o modelo precisa não só de contexto, mas de um ambiente controlado.

Os subagentes dão uma visão paralela das mudanças e pegam erros antes que cheguem à branch principal. As skills eliminam a rotina, padronizam os passos e reduzem o número de decisões que precisam ser tomadas de novo. O BDD acrescenta um contrato externo de comportamento, para que a reescrita não vire uma troca silenciosa da lógica de negócio por uma estrutura nova e bonita.

Por isso o autor considera que o resultado mais importante não é apenas a aceleração, mas o surgimento de um toolchain funcional, o level85. Na prática, é um conjunto de acordos entre a pessoa, o modelo e os agentes auxiliares: como decompor a tarefa, como verificar resultados intermediários, como limitar a liberdade de geração e onde incluir testes. Essa abordagem faz da IA não um botão mágico, mas um participante disciplinado do desenvolvimento.

O autor não tenta vender uma receita universal. Pelo contrário, ele ressalta que, mesmo na configuração montada, restam armadilhas: excesso de contexto, decomposição errada, verificações fracas ou um momento mal escolhido para automatizar podem facilmente consumir o ganho. A conclusão principal é prática: a aceleração no desenvolvimento assistido por IA nasce não de um único modelo, mas do sistema operacional ao redor dele.

Se a equipe continua usando a IA como uma janela de chat para dicas pontuais, o código monolítico continuará sendo reescrito de forma lenta e estressante. Mas se o modelo virar parte do processo, com papéis, revisão, cenários e técnicas fixas, até um legado pesado pode ser desmontado muitas vezes mais rápido, sem abrir mão da disciplina de engenharia. Essa é, talvez, a principal lição do artigo.