Vibecoding
Como apagar código com segurança
Todo projeto tem código que não faz mais nada. Tirar dá medo porque ninguém sabe quem depende daquilo. Existe um caminho de quatro passos que remove o medo.
Todo projeto tem trechos que não fazem mais nada.
A funcionalidade que foi substituída, o campo que ninguém preenche, a integração de um serviço que a empresa parou de usar.
E ninguém tira, porque tirar dá medo. O medo é legítimo: você não sabe quem depende daquilo.
Quatro passos resolvem.
Passo 1: descobre quem chama
Busca no projeto inteiro pelo nome da função, do arquivo, do campo, da rota.
Três resultados possíveis:
Ninguém chama. Bom sinal, mas não é conclusão. Pode ser chamado por nome montado em tempo de execução, por configuração, ou por sistema externo.
Chamado só por código que também está morto. Você achou um bloco inteiro em vez de uma peça.
Chamado por coisa viva. Não é remoção, é refatoração. Assunto diferente.
Passo 2: mede se é usado de verdade
Busca no código não basta, porque existe código alcançável que ninguém alcança.
A rota existe, funciona, e nenhum usuário entra nela há sete meses.
Aqui você precisa de dado de uso: registro de acesso, contador, qualquer sinal de execução real. Se não existir, coloca um contador temporário e espera algumas semanas.
Parece lento e é muito mais rápido que remover errado e descobrir pelo cliente.
Passo 3: desativa antes de apagar
Esse é o passo que transforma aposta em teste, e é o que quase todo mundo pula.
Em vez de apagar, você impede que aquilo seja alcançado. Bloqueia a rota, desliga por configuração, faz o caminho falhar de forma explícita e registrada.
O código continua lá, então voltar é imediato.
Espera duas ou três semanas. Se ninguém reclamou e o registro não acusou tentativa de uso, você tem evidência em vez de intuição.
E se alguém reclamar, ótimo: você descobriu a dependência sem ter destruído nada.
Passo 4: apaga de verdade
Depois da quarentena, remove.
Duas regras:
Uma remoção por vez. Se algo quebrar, você sabe exatamente o quê. Cinco remoções juntas viram investigação.
Mensagem explicando. Registra o que foi removido e por quê, com a evidência de uso zero. Daqui a um ano, quando alguém perguntar onde foi parar aquilo, a resposta está lá.
O que nunca remover sem avisar
Três casos pedem conversa antes:
Endereço que outro sistema chama. Integração externa não aparece na busca do seu projeto.
Campo de banco. Dado apagado não volta. Marca como obsoleto, para de escrever nele, e só remove muito depois.
Coisa que alguém usa manualmente. Aquele relatório que uma pessoa roda uma vez por mês não aparece em nenhuma métrica de uso diário.
Onde a IA ajuda e onde ela atrapalha
Ajuda a mapear referências, explicar o que um trecho fazia e sugerir o que parece morto.
Atrapalha se você aceitar a sugestão dela como decisão. Ela não sabe que aquele campo é usado uma vez por ano no fechamento contábil. Ela vê o código, não o negócio.
Sugestão dela é ponto de partida da investigação, nunca conclusão. É o mesmo cuidado de não delegar arquitetura.
Por que vale o esforço
Código morto não é neutro. Ele custa: aparece nas buscas, confunde quem lê, atrapalha refatoração, e engana a IA que você usa, porque ela também lê aquilo como se fosse relevante.
Cada trecho removido deixa o sistema mais fácil de entender pra todo mundo, inclusive pra ferramenta.
Apagar com método não é arriscado. Apagar no chute é.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Como saber se um trecho ainda é usado?
Combinando busca por referências no projeto com medição de uso real em produção. Busca mostra quem chama no código; medição mostra se aquele caminho é executado por alguém.
+O que é desativar antes de apagar?
Deixar o código no lugar mas impedir que ele seja alcançado, por configuração ou por um bloqueio explícito. Se ninguém reclamar em algumas semanas, a remoção definitiva vira rotina em vez de aposta.
+Preciso avisar alguém antes de remover?
Sim, quando o trecho tem qualquer chance de ser usado por outra pessoa ou por integração externa. Remoção silenciosa de algo compartilhado é a forma mais comum de quebrar o trabalho alheio.
+E se eu apagar algo importante por engano?
Com versionamento você volta em minutos, e é justamente por isso que remoção só deveria acontecer em projeto versionado. Sem isso, apagar vira decisão sem volta.
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.