Refactors e migrations em massa

Existe um tipo de trabalho onde a IA não só ajuda — ela supera o humano com folga: a mudança repetitiva espalhada por dezenas de arquivos. É o trabalho que cansa, entedia e, justamente por isso, é onde gente erra. Este post mostra como a gente usa Claude Code pra isso com segurança.

Por que refactor em massa é o lar do vibe coding

Renomear um conceito em 40 arquivos. Migrar um padrão antigo pro novo em todo o repo. Ajustar a assinatura de uma função usada em 30 lugares. Pra um humano: horas tediosas com risco de pular um caso. Pra IA: minutos consistentes — ela não cansa, não distrai, não "quase termina".

O monorepo do ClubPetro (apps/web + 10 packages) tem muito desse tipo de mudança transversal. É onde a alavancagem da IA mais aparece.

O método seguro

1. Defina o padrão num exemplo

Mostre um caso já no formato novo. "Aqui está como deve ficar; aplica isso em todos os lugares equivalentes." Exemplo concreto > descrição abstrata.

2. Peça o inventário antes

"Liste todos os lugares afetados antes de mudar." Você confere o escopo — e pega caso que não devia entrar.

3. Vá em fatias revisáveis

Mudança em 40 arquivos de uma vez é PR impossível de revisar. Quebre por pacote ou por grupo lógico. PR pequeno é PR que pega o erro.

4. Apoie-se na rede de segurança

typecheck e AI Code Review (Módulo 7) seguram o que escapar do olho. Refactor em massa + CI verde é uma dupla poderosa.

O caso especial: migrations

Migration é refactor de dados — e aqui o cuidado sobe vários níveis, porque a regra da série manda: antes de mexer em dado, cheque a base.

• Nossas migrations são SQL escritas à mão (packages/db/drizzle/NNNN_*.sql); o _journal.json está desatualizado, então db:migrate não é o mecanismo. A IA precisa saber disso — e o CLAUDE.md conta.
• Toda tabela nova exige ENABLE ROW LEVEL SECURITY no mesmo migration. Inegociável.
• Há drift conhecido DB↔Drizzle: o .ts nem sempre reflete o banco. Confira o real.
• Jamais db:push em produção. E lembre que o .env.local local aponta pra prod.

Onde o humano não sai do volante

Refactor mecânico, a IA faz. Decidir se o refactor vale, qual é o padrão certo e revisar a migration linha a linha — isso é seu. Migration ruim é irreversível; e irreversível, a gente decide devagar.

⚠️ Armadilha #16: soltar a IA pra refatorar/migrar em massa e aprovar sem revisar porque "é só repetição". É exatamente na repetição que um erro vira 40 erros. Volume amplifica tanto o acerto quanto a besteira.

Próximo da série: #17 — Debugging com IA: do stack trace à causa raiz.