Claude Code e Subagentes Reduziram Reescrita de Projeto Legacy de Três Meses para Uma Semana

A diferença entre três meses e uma semana nesta história é explicada não pelo fato de os modelos de repente começarem a escrever código perfeito, mas pelo fato de o autor ter parado de usar IA como um autocompletar inteligente e transformá-la em um pipeline de engenharia completo. Usando dois projetos Go de escala similar como exemplo, ele mostra: quando o legado é refatorado manualmente e intuitivamente, a velocidade é limitada pelo caos; quando o modelo tem papéis, procedimentos, revisão e um loop de testes, a reescrita do monólito se acelera exponencialmente. Um ano atrás, o ponto de partida era a familiar dívida técnica após um MVP.

O projeto tinha um main.go de aproximadamente duas mil linhas, onde lógica de negócios, configuração, handlers HTTP, operações de banco de dados e outro código de suporte foram misturados em um lugar. Tal estrutura pode sobreviver ao lançamento inicial do produto, mas não escala bem: qualquer mudança causa efeitos colaterais, o código é difícil de dividir em zonas de responsabilidade, e os testes se tornam dor adicional ao invés de suporte.

O autor se lembra que naquela época estava puxando o sistema para uma arquitetura normal aos poucos, com testes improvisados e constante reverificação manual. Ele fez o primeiro refatoramento no Cursor e gastou cerca de três meses nele. Foi um processo cuidadoso, quase cirúrgico: extrair um bloco, verificar se o comportamento quebrou, depois passar para o próximo.

Um projeto recente de escala similar rendeu resultados muito diferentes. O autor pegou Claude Code, modelo Opus, conectou três subagendes revisores e construiu ao redor deles aproximadamente trinta skills — cenários repetíveis para operações típicas. Como resultado, a reescrita levou uma semana, com uma porção significativa desse tempo não gasta na migração de código em si, mas na camada BDD sobre a implementação.

Segundo sua avaliação, sem cenários no godog a tarefa poderia caber em aproximadamente três dias. A essência do artigo não é que uma ferramenta específica se mostrou mais forte que outra, mas que o autor mudou sua forma de trabalhar. Ele contrasta sua prática com conselhos populares da série "dê à rede neural um bom prompt e aguarde o resultado".

No legado real isso não é suficiente: modelos precisam não apenas de contexto, mas também de um ambiente gerenciado. Subagendes fornecem uma perspectiva paralela sobre as mudanças e capturam erros antes que eles atinjam o ramo principal. Skills eliminam rotina, padronizam etapas e reduzem o número de decisões que precisam ser tomadas novamente.

BDD adiciona um contrato de comportamento externo para que a reescrita não se transforme em substituição silenciosa de lógica de negócios por uma nova estrutura bonita. É por isso que o autor chama o resultado mais importante não simplesmente aceleração, mas o surgimento de um toolchain funcional nível85. Essencialmente, este é um conjunto de acordos entre uma pessoa, um modelo e agentes auxiliares: como decompor uma tarefa, como verificar resultados intermediários, como limitar a liberdade de geração e onde conectar testes.

Tal abordagem torna a IA não um botão mágico, mas um participante disciplinado do desenvolvimento. Ao mesmo tempo, o autor não está tentando vender uma receita universal. Pelo contrário, ele enfatiza que mesmo na configuração montada existem armadilhas: contexto extra, decomposição incorreta, verificações fracas, ou momento incorretamente escolhido para automação facilmente consomem o ganho.

A conclusão principal aqui é prática: a aceleração em desenvolvimento auxiliado por IA nasce não de um modelo, mas do sistema operacional ao seu redor. Se uma equipe continua trabalhando com IA como uma janela de chat para conselhos pontuais, o código monolítico ainda será reescrito lentamente e nervosamente. Mas se você transformar o modelo em parte do processo — com papéis, revisão, cenários e técnicas fixas — mesmo o legado pesado pode ser desmontado várias vezes mais rápido sem abandonar completamente a disciplina de engenharia.

E isso, talvez, seja a principal lição do artigo.