TL;DR
De uns meses pra cá mudou o perfil de quem me procura. Antes era “tenho uma ideia, faz pra mim”. Agora é “já tenho o app, ele até funciona, mas trava na hora de crescer, e eu não sei se conserto ou jogo fora”. O produto foi vibe coding: gerar software pedindo pra IA e aceitando o resultado sem ler nem entender o código que saiu. Funciona o suficiente pra ter cliente pagando. E o suficiente pra dar medo.
A primeira decisão diante de um desses não é técnica. É de triagem. E a tentação mais cara, a que quase todo mundo tem no primeiro dia, é mandar reescrever tudo do zero. Quase sempre é erro. Na maioria dos casos não é transplante: é suíte de testes primeiro, depois bisturi no que de fato apodreceu. Salva-se muito mais do que o desespero sugere.
Os números explicam o susto e por que ele engana. 45% do código gerado por IA carrega uma falha do OWASP Top 10 (Veracode), e só 10,5% do código vibe-coded passa num review de segurança decente contra 61% que simplesmente “funciona” (Carnegie Mellon). Parece sentença de demolição. Não é. É a medida da distância entre funcionar e aguentar, e distância a gente mede ANTES de demolir, não depois.
Funciona não é o mesmo que pronto. Mas também não é o mesmo que lixo.
Reescrever do zero é o erro mais caro que existe
Todo mundo que me liga com um app travado chega com a mesma sentença na ponta da língua:
“Esse código é uma zona. É mais rápido refazer do zero do que entender essa bagunça.”
Calma lá. Essa frase é o canto da sereia mais caro da engenharia de software, e não fui eu que descobri isso. Joel Spolsky chamou reescrever do zero de “o pior erro estratégico que uma empresa de software pode cometer”, e isso foi em 2000, muito antes de a IA deixar a reescrita ainda mais tentadora e ainda mais cara.
Por que é erro? Porque você está prestes a jogar fora justamente a única coisa que esse MVP provou: que tem gente querendo. O código é feio, mas ele carrega meses de aprendizado embutido. Cada gambiarra esquisita é, na metade das vezes, um caso de borda real que algum cliente encontrou e que a versão “limpa” do zero vai redescobrir do jeito difícil, em produção, de novo.
Pensa no Twitter. Nasceu num monólito Rails porque era o que dois caras conseguiam tocar rápido o bastante pra achar product-market fit. Os problemas de escala vieram depois. Porque deu certo. Se tivessem começado “do jeito certo”, parrudo e distribuído, provavelmente não existiria Twitter pra ter problema de escala. A velocidade do vibe coding é real e é valiosa pra validar. O erro não é ter validado assim. É não trocar de marcha quando a validação acabou.
Reescrita do zero é a vaidade de quem acabou de chegar no projeto.
Antes de tocar em qualquer linha, a suíte de testes
Aqui está o passo que quase todo mundo pula, e é o que separa um resgate de um segundo desastre: você não conserta o que não consegue testar, nem refatora com segurança o que não cobriu antes. Teste não é o último passo do resgate. É o primeiro.
E é exatamente o que o código vibe-coded não tem. A IA gera com um viés brutal de caminho feliz: cobre o fluxo que você descreveu e ignora o resto do universo. Erro de rede, input inválido, dois cliques no mesmo botão, o usuário que faz na ordem errada. Nada disso existe no código, então nada disso quebra de forma visível. Até quebrar na frente do cliente.
“Escrever teste antes de entregar feature nova? Vou ficar duas semanas sem mostrar nada pro board.”
Entendo a ansiedade, e ela está invertida. A suíte de testes não é tempo perdido antes de entregar valor. É o que te dá permissão pra mexer no código sem rezar. Sem ela, cada refactor é uma aposta cega: você arruma um bug e descobre, três dias depois, que quebrou dois outros que ninguém via. Com ela, você refatora de olhos abertos. É a diferença entre operar com luz acesa e operar no escuro.
Na prática, eu nem peço cobertura total de cara. Peço teste nos fluxos que dão dinheiro e nos que perdem dinheiro: o checkout, o login, o que mexe em saldo. É a rede de segurança mínima pra tudo que vem depois ser cirurgia, e não roleta. Essa mesma disciplina de validar antes de confiar a gente já destrinchou em validação local com qualidade real, só que ali aplicada ao fluxo de quem está construindo, não resgatando.
O diagnóstico: lendo o extrato da dívida
Com rede de segurança no lugar, dá pra abrir o capô sem medo. O diagnóstico de um MVP vibe-coded quase sempre encontra os mesmos quatro buracos. Eu chamo de ler o extrato da dívida, porque é literalmente isso: descobrir quanto você deve e pra quem.
- Arquitetura acoplada. A regra de negócio está grudada na infraestrutura, a API foi desenhada sem pensar em carga, o schema não aguenta crescer de lado. Funciona com cinquenta usuários porque tudo funciona com cinquenta usuários. O paper que formalizou isso chama de flow-debt trade-off: a fluidez de gerar código mascara a dívida que cresce em paralelo.
- Observabilidade ausente. Logging, trace e métrica entraram como pensamento tardio, ou não entraram. Quando cai às 3 da manhã, você não tem onde olhar. A frase da OneUptime fica na parede: “observabilidade não é um nice to have, é a sua única rede de segurança”. No código vibe-coded ela é a substituta da revisão humana que nunca aconteceu.
- Segurança de enfeite. Chave de API hardcoded no repositório, autenticação com a lógica invertida, banco exposto sem regra de acesso. Não é exceção: a Apiiro mediu código gerado por IA somando 10x mais achados de segurança em seis meses, com caminhos de escalonamento de privilégio subindo 322%.
- Deploy e CI frágeis. O caso clássico é preview, teste e produção dividindo o mesmo banco. Foi assim que a IA da Replit apagou o banco de produção durante um congelamento de código explícito, em CAIXA ALTA no prompt, e depois mentiu dizendo que o rollback era impossível. A separação de ambientes é a lição mais barata e mais ignorada da lista.
O extrato assusta de propósito. Mas extrato não é despejo. Ele te diz onde está a dívida cara e onde está a dívida que dá pra rolar, e essa distinção é o resgate inteiro.
Como sei se a arquitetura dá pra salvar ou não?
O critério prático é um só: o nível de acoplamento entre a regra de negócio e a infraestrutura, somado a se o modelo de dados aguenta crescer. Se a lógica que importa está enfiada no meio do controller, dependente de um detalhe do banco que não escala de lado, aquele pedaço é reescrita localizada: não tem como salvar a fundação sem refazê-la. Se a regra de negócio está minimamente isolada, mesmo que feia, é remediação: você melhora por dentro sem demolir. A maior parte de um MVP cai no segundo caso. É por isso que reescrita total quase nunca é a resposta certa: você condena o prédio inteiro por causa de dois cômodos.
O que salvar e o que reescrever sem dó
Triagem é decidir o que entra no centro cirúrgico e o que recebe alta. Depois de fazer isso em vários apps, o padrão é bem estável.
Salvar quase sempre: o modelo de domínio que reflete o negócio de verdade (os nomes das coisas e como se ligam), os fluxos que o usuário já validou na prática, e boa parte da interface. Esse é o conhecimento que custou meses e que uma reescrita joga no lixo de graça. A versão dessa disciplina no nível da estrutura do código a gente abriu em seu codebase é o novo prompt: o que decide se escala não é a stack, é o repositório continuar navegável.
Reescrever sem dó: a camada de autenticação e permissão (é onde mais dói deixar errado, porque toca toda requisição), a lógica de negócio que a IA duplicou em oito, dez, doze lugares, o schema que não aguenta tração, e as integrações sem nenhum fallback. A duplicação não é detalhe: em 2024, pela primeira vez na história, código copiado e colado superou código refatorado, com blocos duplicados crescendo 8x (GitClear). Cada cópia é um lugar a mais pra um bug se esconder e nunca ser corrigido em todos.
O que guia o corte é entender por que o app empaca onde empaca. Addy Osmani batizou de 70% problem: a IA leva você rápido a 70%, só que é 70% do volume de código, não 70% do caminho até um produto pronto. Os 30% que faltam são exatamente o que não dá pra gerar no susto: caso de borda, manutenibilidade, performance, segurança. É a parte cara. É a parte que a triagem isola.
Vibe coding serve pra produção?
Serve pra chegar até a porta dela, não pra entrar. Vibe coding é um acelerador de validação espetacular: prova a hipótese, conquista os primeiros clientes, mostra que existe negócio. O erro não é usar. É confundir o protótipo que validou com o produto que escala, e seguir empilhando feature por cima de uma fundação que nunca foi feita pra carregar peso. A própria mecânica disso, de por que o “pede, aceita, deploya” empaca na hora de crescer, a gente discutiu em sair do vibe coding. Vibe coding leva ao MVP. Método leva o MVP a produto.
Estabilizar sem parar o negócio: a cirurgia com o paciente acordado
A última peça, e a que mais diferencia um resgate competente, é o “sem parar o negócio”. Porque o app está no ar, tem cliente usando, tem fatura entrando. Você não pode desligar tudo por dois meses pra arrumar a casa. Tem que operar com o paciente acordado.
O jeito de fazer isso tem nome: padrão Strangler: substituir o sistema velho por fora, módulo a módulo, enquanto ele continua rodando, até o novo estrangular o antigo. Em vez do big bang (“vira a chave do novo num domingo e reza”), você escolhe um pedaço (a autenticação, digamos), constrói a versão nova ao lado, manda uma fração do tráfego pra ela com feature flag, confirma que aguenta, e só então aposenta a velha. Errou? Rollback num clique, ninguém percebe. Repete pro próximo módulo. O risco fica fatiado em pedaços que cabem no bolso, em vez de uma aposta única que pode derrubar a empresa.
E a primeira fatia, quase sempre, é a mais barata e a mais esquecida: separar os ambientes. Banco de produção é sagrado, tem backup automático testado, e ninguém, humano ou IA, encosta nele sem rede. É a correção que teria evitado o desastre da Replit inteiro, e custa um dia.
Tem trade-off, e eu não vendo milagre. No papel, o Strangler é mais lento que reescrever do zero: você mantém dois sistemas vivos ao mesmo tempo por um período, paga o custo de manter os dois falando. É chato. Mas é o preço de não parar de faturar enquanto opera, e é incomparavelmente mais barato que a reescrita que congela o produto por um trimestre e ainda chega atrasada. É o tipo de diagnóstico independente, sem amarra comercial, que a gente entrega numa Auditoria antes de qualquer linha ser tocada: o mapa do que salvar, do que reescrever e em que ordem mexer. O que cortar e o que manter quando se decide o escopo dessa reconstrução a gente abriu em o que cortar e o que manter num MVP.
Funciona não é pronto. Mas também não é lixo.
O instinto diante de um MVP vibe-coded travado é binário: ou ele é maravilhoso porque está no ar, ou é lixo porque o código é feio. Os dois estão errados. Ele é exatamente o que parece: um protótipo que validou um negócio e agora precisa virar produto, com uma dívida que dá pra ler, item por item, e pagar na ordem certa.
A distância entre a demo que encantou e o sistema que aguenta tração é mensurável. Não é fé, é diagnóstico: testes pra acender a luz, o extrato pra saber o que se deve, a triagem pra separar o que salva do que reescreve, e o Strangler pra operar sem desligar o paciente. Quase sempre dá pra fazer sem demolir a casa.
Pronto é um estado que se prova, não que se sente.