Meu app vibe-coded quebrou: o guia de manutenção pra não-dev

Quando seu app vibe-coded para de funcionar do nada, o primeiro passo não é entrar em pânico nem procurar um suporte que não existe. É rodar um protocolo de 4 perguntas antes de tocar em qualquer coisa: o que mudou por último, qual é a mensagem de erro exata, dá pra voltar pra uma versão anterior e o problema é do seu app ou de uma integração externa. Na maioria dos casos, um não-dev resolve isso sozinho, sem escrever uma linha de código.

---

Meu app parou de funcionar do nada: o que eu faço primeiro?

Antes de qualquer ajuste, confira o óbvio: sua internet, se você não deslogou sem querer, se o navegador não tá com cache velho. Um Ctrl+Shift+R pra forçar recarregar a página resolve mais coisa do que devia.

Se o óbvio não resolveu, responda 4 perguntas antes de mexer em mais nada: o que mudou recentemente, qual é a mensagem de erro exata, existe uma versão anterior que funcionava, e o problema está no seu código ou numa integração externa (Supabase, Zapier, WhatsApp, Stripe). Não acho que pânico ajude nessa hora. Pq a grande maioria dos “quebrou tudo” é uma chave de API expirada, um limite de uso estourado ou uma mudança de ontem que ninguém testou.

---

Como descubro o que mudou por último no meu app?

A forma mais rápida é olhar o histórico de versões da ferramenta que você usou pra construir: no GitHub é a aba de commits, no Vercel é o log de deploys, no Supabase é o histórico de migrations do banco. Praticamente toda ferramenta de vibe coding grava quem mudou o quê e quando.

A pergunta que resolve a maior parte dos casos é simples: “o que eu mudei nas últimas 24 a 48 horas antes disso parar de funcionar?” Se você pediu pra IA adicionar um campo ou integrar um serviço novo, essa é a suspeita número 1. Se você não mudou nada, a suspeita número 2 é uma integração externa que mudou do lado de fora, sem avisar. No Vercel, cada deploy fica listado com data e hora, e dá pra comparar o que funcionava com o que quebrou.

---

Como eu faço a IA entender o erro se eu não sei ler código?

Cole a mensagem de erro completa, não um resumo do que você entendeu, na mesma ferramenta de IA que construiu o app, junto com o que você estava fazendo e o que esperava que acontecesse. Essas 3 informações bastam pra Claude Code ou ChatGPT levantar as causas mais prováveis, mesmo você não entendendo nada de código.

• A mensagem de erro completa, sem resumir com suas palavras.
• O que você estava fazendo quando o erro apareceu.
• O que você esperava que acontecesse.

“Tá dando erro” não ajuda nem um dev júnior, quanto mais uma IA. O que ajuda é o texto exato do erro, geralmente em vermelho, numa tela de console. Se aparecer um textão técnico que parece grego, copia e cola inteiro, sem editar nada.

Ler o erro em voz alta pra IA funciona literalmente: descreve o que você vê na tela como se estivesse contando pra um amigo ao telefone. “Apareceu uma tela vermelha escrito Error 500 depois que eu cliquei em salvar” já é informação suficiente pra levantar as 3 ou 4 causas mais prováveis. Print de tela do erro completo, incluindo a barra de endereço do navegador, resolve mais rápido que qualquer descrição só em texto.

---

Dá pra voltar pra uma versão anterior que funcionava?

Sim, e na maioria das plataformas de deploy (Vercel, Netlify, Railway) isso costuma levar menos de 2 minutos: você promove o deploy anterior pra produção com um clique. Se o app usa banco de dados (Supabase, Cloudflare D1), reverter só o código não desfaz mudanças no banco.

Reverter resolve o sintoma na hora: o app volta a funcionar enquanto você, ou a IA, investiga o que causou o problema. Se a quebra envolveu mudança de estrutura no banco (um campo novo, uma tabela alterada), reverter só o código pode criar uma incompatibilidade ainda mais confusa. Essa é uma das poucas situações em que vale parar e chamar ajuda antes de mexer sozinho.

---

Como isolar se o problema é uma integração externa ou o app em si?

Teste a integração isolada, fora do seu app: se você usa Zapier, Make, Supabase, Stripe ou a API do WhatsApp, entra direto no painel dessa ferramenta e confere se ela está no ar e respondendo.

Imagine uma papelaria hipotética que automatizou o envio de nota fiscal por WhatsApp usando Zapier. Se o envio parou, o primeiro teste não é mexer no app: é abrir o Zapier e ver se aquela automação tem erro registrado ali. Isso já corta a investigação pela metade.

3 perguntas isolam a maioria dos casos:

• Isso funciona testando direto no painel do serviço, fora do meu app?
• Alguma ferramenta mandou e-mail avisando de mudança de plano ou limite de uso?
• O erro acontece sempre no mesmo passo do fluxo, ou muda de lugar cada vez?

Boa parte dos “quebrou tudo” é só um limite de plano gratuito. Supabase, por exemplo, costuma pausar o projeto no plano free depois de cerca de 7 dias sem uso, e o app mostra um erro genérico de conexão que parece grave, mas é só o banco dormindo.

---

Quando resolvo sozinho e quando chamo ajuda técnica?

Sendo bem sincero: boa parte do medo de mexer sozinho vem de achar que vai piorar. Na prática, reverter uma versão e testar de novo raramente piora as coisas, porque o pior cenário (voltar pro que já estava quebrado) também é reversível. O que exige ajuda de verdade é quando tem dado real em jogo: cliente, dinheiro, nota fiscal, informação de saúde.

Não acho que travar sozinho mais de 2 horas no mesmo erro compense. Pq esse é o sinal mais confiável de que o problema passou do nível que instrução em linguagem natural resolve.

---

Como evito que isso aconteça de novo?

3 hábitos cortam a maior parte dos sustos: versionar cada mudança no Git, manter backup dos dados fora do app principal e testar mudança grande num ambiente separado antes de aplicar na versão que seus usuários usam.

1. Versionamento. Cada vez que você, ou a IA a seu pedido, muda algo no app, isso devia virar um commit no Git com uma frase curta descrevendo o que mudou. Não é burocracia de dev: é o botão de “voltar pra ontem”.
2. Backup de dados. Dado que mora só dentro do banco do app (Supabase, Cloudflare D1) está a um erro de exclusão em massa de sumir de vez. Exportar os dados críticos pra uma planilha por semana, ou configurar backup automático diário, é a diferença entre um susto de 10 minutos e uma perda sem volta.
3. Ambiente de teste. Antes de aplicar uma mudança grande na versão que sua equipe usa de verdade, teste numa cópia separada do app (staging). Vercel e Netlify já criam essa cópia automaticamente a cada alteração.

Nenhum desses 3 hábitos exige aprender a programar. Exige a mesma disciplina que você já usa em outra área do negócio: não jogar fora a única cópia de um documento importante antes de guardar uma cópia em outro lugar.

---

FAQ

Preciso saber programar pra consertar meu app vibe-coded? Não, na maioria dos casos. O protocolo de diagnóstico (identificar o que mudou, copiar a mensagem de erro exata, testar a integração isolada, reverter pra uma versão anterior) exige descrever com clareza pra IA o que você está vendo na tela, não ler código. Erros com estrutura de banco de dados ou dado financeiro sumido exigem mais atenção, e vale chamar ajuda antes de mexer sozinho.

Quanto tempo leva pra resolver um bug sozinho, sem dev? Casos simples (chave de API expirada, limite de plano gratuito estourado, mudança recente não testada) costumam resolver em menos de 1 hora, incluindo conversar com a IA e reverter uma versão se precisar. Passar de 2 horas travado no mesmo erro sem nenhum progresso já é sinal de chamar ajuda técnica em vez de continuar tentando sozinho, porque o custo do tempo perdido passa a ser maior que o custo de pedir apoio.

O que é ambiente de teste (staging) e eu realmente preciso de um? Staging é uma cópia do seu app, separada da versão que seus usuários usam de verdade, onde você testa uma mudança antes de aplicá-la na produção. Se seu app é usado por mais de uma pessoa no dia a dia, ou lida com dado que custa dinheiro errar, vale a pena. Vercel e Netlify já criam essa cópia automaticamente a cada alteração, sem custo extra na maioria dos planos.

Como faço backup dos dados do meu app sem contratar ninguém? A forma mais simples é exportar os dados críticos pra uma planilha numa rotina fixa, semanal ou diária, dependendo de quanto dado novo entra por dia. Supabase e Cloudflare D1 também oferecem opção de backup automático nas configurações do projeto, sem escrever nenhuma linha de código. O importante é essa cópia ficar fora do app principal, pra sobreviver mesmo se o app inteiro parar de funcionar.

Quando devo contratar um dev pra resolver o problema em vez de tentar sozinho? Quando o problema envolve dado sensível ou financeiro que sumiu ou duplicou, quando você já reverteu e o erro continua, ou quando passou de 2 horas travado no mesmo erro sem progresso. Esses 3 sinais indicam que o problema passou do nível que uma instrução em linguagem natural resolve pra um nível que precisa de alguém lendo código com profundidade técnica.

O erro sumiu sozinho depois que eu recarreguei a página, isso é normal? Sim, e não significa que o problema não existiu. Erro que some com um recarregamento costuma ser cache do navegador, instabilidade momentânea de rede ou uma integração externa que ficou fora do ar por poucos minutos. Vale registrar o que você viu (um print, o horário) mesmo assim: se o mesmo erro voltar, esse registro já te dá metade do diagnóstico pronto.