Vibecoding
Como mudar uma parte que o sistema inteiro usa
Existe um tipo de mudança que dá medo com razão: aquela em que quarenta lugares dependem da coisa que você vai mexer. Tem um caminho que reduz isso a passos pequenos.
Tem mudança que dá medo com razão.
Não é a mudança grande. É a mudança compartilhada: aquela função que quarenta lugares chamam, aquele campo que todo relatório usa, aquele formato que o sistema inteiro assume.
Você mexe num lugar e não faz ideia do que acontece nos outros trinta e nove.
Por que o medo é justificado
Porque o alcance da mudança é maior que a área que você consegue testar.
Cada ponto que depende daquilo usa de um jeito ligeiramente diferente. Um passa um parâmetro a mais, outro assume que o retorno nunca é vazio, um terceiro depende de um efeito colateral que ninguém documentou.
Você testa cinco e os cinco funcionam. Os que quebram são os que você não pensou em testar, e eles aparecem depois, em produção.
A ideia central: não troca, adiciona
O erro é tratar isso como substituição: apago o velho, coloco o novo, torço.
O caminho seguro é outro: o novo nasce ao lado do velho, e os dois convivem durante a transição.
Isso muda a natureza do risco. Em vez de uma mudança grande e irreversível, você tem uma sequência de mudanças pequenas, cada uma reversível sozinha.
Passo 1: descobre o alcance
Antes de qualquer coisa, quem depende daquilo.
Busca por referências no projeto inteiro. Depois complementa com medição em produção, porque existe chamada que a busca não acha: nome montado em tempo de execução, configuração externa, sistema de terceiro batendo na sua rota.
Se você não sabe o alcance, você não sabe o tamanho do que está fazendo.
Passo 2: cria a versão nova ao lado
A nova versão existe com outro nome. A antiga continua intacta, funcionando, sem ninguém tocar nela.
Nesse momento nada mudou pra ninguém. O sistema está exatamente como estava, com uma coisa nova disponível e sem uso.
Isso já é metade do trabalho, e é a metade que tem zero risco.
Passo 3: migra um ponto por vez
Aqui é onde o método rende.
Pega o ponto menos crítico que usa a versão antiga. Migra só ele. Testa. Salva.
Depois o próximo.
Se quebrar, você sabe exatamente qual foi, porque foi a única coisa que mudou. E voltar afeta um ponto, não quarenta.
Ordem que funciona: começa pelo menos crítico pra pegar as diferenças de comportamento em lugar barato, e deixa o mais crítico pro fim, quando você já entendeu todas as pegadinhas.
Passo 4: confirma que ninguém usa o antigo
Antes de remover, evidência.
Coloca um contador na versão antiga e espera. Semanas, não horas. Existe caminho que roda uma vez por mês, no fechamento, e você não quer descobrir isso do jeito difícil.
Zero uso comprovado por um período é o que autoriza a remoção. Antes disso é aposta, e o método inteiro existe pra não apostar.
Passo 5: remove
Aí sim, apaga a versão antiga, seguindo o mesmo cuidado de apagar código com segurança.
Se você pulou o passo 4, esse é o momento em que descobre o que faltava.
Onde a IA ajuda e onde não
Ajuda: encontrar as referências, gerar a versão nova, fazer a alteração mecânica em cada ponto de chamada, explicar diferenças de comportamento entre as duas versões.
Não ajuda: decidir a ordem de migração, saber qual ponto é crítico pro negócio, e ter paciência. Se você pedir pra ela migrar tudo de uma vez, ela migra tudo de uma vez, com competência, e você fica com o problema que o método evitaria.
Convivência é mais lenta e é a diferença entre uma tarde chata e uma semana ruim.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Por que mudar algo compartilhado é tão arriscado?
Porque o alcance da mudança é maior que a área que você consegue testar. Cada ponto que depende daquilo pode usar de um jeito ligeiramente diferente, e é nas diferenças que a quebra acontece.
+Qual a alternativa à troca de uma vez?
Criar a versão nova ao lado da antiga e migrar um ponto por vez. Durante a transição as duas convivem, e cada migração é pequena e reversível.
+Como saber quem depende daquilo?
Buscando por referências no projeto inteiro e complementando com medição em produção, porque existem chamadas que a busca não encontra, como as montadas em tempo de execução ou vindas de fora.
+Quando remover a versão antiga?
Depois que a medição mostrar que ninguém a usa mais por um período. Remover antes de comprovar é apostar, e apostar é justamente o que o método evita.
Continue lendo
Como documentar um sistema que a IA escreveu
Documentação longa ninguém escreve e ninguém lê. Existe uma versão curta que cabe em uma página e resolve 90% do problema, principalmente quando quem escreveu o código foi a IA.
VibecodingComo subir pra produção numa sexta sem medo
A regra de não subir na sexta existe porque o processo é ruim, não porque sexta é perigosa. Com quatro coisas no lugar, o dia da semana para de importar.
VibecodingO agente de código entrou no canal do time. Ver não é revisar
O Slack lançou canais onde agentes de IA programam na frente de todo mundo, com Claude, Copilot, Devin, ChatGPT e Vercel. É a melhor notícia de governança do ano e a maior armadilha de teatro de revisão.