Quando reescrever do zero é a decisão certa (é raro)

Todo sistema chega num ponto em que alguém propõe começar de novo.

O código está bagunçado, ninguém entende direito, cada mudança dói. E agora tem um argumento novo e sedutor: com IA, refazer é rápido.

Na maioria das vezes, é a decisão errada. Vale entender por quê antes de decidir.

O que o sistema antigo sabe

O código feio que está lá não é só código feio. Ele acumulou conhecimento que ninguém escreveu em lugar nenhum.

Aquele tratamento estranho existe porque um cliente manda o arquivo num formato diferente.

Aquela validação aparentemente redundante existe porque um dia entrou dado quebrado e deu problema.

Aquela exceção existe por causa de uma regra que vale só pra um estado, ou pra contrato antigo.

Nada disso está documentado. Está embutido. E some inteiro na hora em que você apaga tudo.

O sistema novo nasce limpo e ignorante. Ele vai passar meses redescobrindo, um a um, problemas que já estavam resolvidos, e cada redescoberta acontece em produção, com cliente reclamando.

O que a IA mudou e o que não mudou

Mudou: gerar o código ficou rápido. A parte que levava meses agora leva dias.

Não mudou: saber o que o sistema precisa fazer. E essa sempre foi a parte difícil.

Se você descrever pra IA o que o sistema faz, ela constrói. Mas você vai descrever o que você lembra, e o que você lembra é a versão limpa. Os quarenta detalhes que se acumularam em três anos não estão na sua descrição, porque você não sabe que eles existem.

Reescrita não falha por falta de código. Falha por falta de memória.

Quando reescrever se justifica

Poucos casos, e todos objetivos:

A tecnologia acabou. A linguagem, o framework ou a plataforma não recebe mais suporte nem correção de segurança. Aqui não tem escolha, tem prazo.

O negócio mudou de forma estrutural. Não é uma funcionalidade nova; é o modelo mudando. O sistema foi feito pra vender produto avulso e agora a empresa é assinatura. Adaptar custa mais que refazer.

O custo de manter passou consistentemente o de refazer. Consistentemente, medido, não sensação de um mês ruim.

Ninguém consegue mais mudar com segurança. Toda alteração quebra algo em outro lugar, e ninguém sabe prever o quê. Aí o sistema já parou, só não avisou.

Quando não se justifica

Porque está feio. Feio funcionando é ativo. Bonito quebrado é passivo.

Porque queremos usar outra tecnologia. Preferência técnica não paga reescrita.

Porque ninguém entende. Isso se resolve entendendo, que é mais barato e mais rápido do que refazer.

Porque a IA facilita. Facilitar a parte fácil não muda a decisão sobre a parte difícil.

O caminho do meio, que quase sempre é melhor

Substituição por partes.

Novo e antigo convivem. Você escolhe um pedaço, constrói a versão nova dele, direciona o tráfego pra ela e desliga o pedaço antigo. Depois o próximo.

Três vantagens que decidem:

Cada pedaço migrado já dá retorno, em vez de esperar o fim. Dá pra parar no meio se as prioridades mudarem, e o que foi feito continua valendo. O conhecimento é transferido aos poucos, porque você olha o pedaço antigo enquanto constrói o novo.

Reescrita total tem que terminar inteira pra valer alguma coisa. E projeto que só vale no fim é projeto que costuma ser cancelado no meio.

A pergunta que decide

Antes de aprovar qualquer reescrita:

O que esse sistema sabe que a gente não escreveu em lugar nenhum?

Se a resposta é "não faço ideia", essa é exatamente a razão pra não apagá-lo ainda.

A decisão é sua.