Teste de realidade da produção
O vibe estava impecável. A aplicação está avariada.
O protótipo tornou-se sistema antes de receber testes e um processo de release. O próximo prompt pode não ser o melhor passo.
01
O que aconteceu?
Vibe coding favorece velocidade; produção exige repetibilidade. Um prompt amplo pode misturar correção, refactoring, dependências e migrações.
02
Porque é que isto acontece
- Não existe um diff pequeno entre a versão boa e a má.
- Dados de preview ou mocks esconderam uma dependência real.
- Cada tentativa altera mais uma zona sem relação.
03
O que pode verificar
- Pare as edições e guarde commit, logs e erro.
- Compare apenas alterações depois do último commit estável.
- Transforme a falha original num teste de regressão.
NÃO TÉCNICO
Não escreveu o código você mesmo? Ainda assim pode ajudar a corrigi-lo.
A coisa mais útil que pode fazer agora não é um prompt melhor, é parar de gerar mais alterações.
- Congele o projeto — nada de prompts do género "tenta isto" até alguém ver o que avariou.
- Anote mais ou menos quando funcionou pela última vez e o que pediu à IA para construir ou mudar desde então.
- Guarde (ou peça à sua ferramenta de IA) a exportação atual do projeto ou acesso ao repositório.
- Liste tudo o que toca em utilizadores reais, dinheiro ou dados pessoais — isso muda o cuidado que a correção exige.
O Shipvise ou um revisor sénior consegue usar esse histórico para determinar qual a alteração que avariou a aplicação, sem que precise de perceber commits ou diffs.
04
Como testar a correção em segurança
Faça a correção num branch separado, valide-a num staging próximo de produção e publique exatamente a versão aprovada. Mantenha disponível o último artefacto estável e um rollback testado.
05
Quando precisa de um programador
Chame um revisor sénior quando ninguém conseguir explicar a arquitetura gerada, quando dados possam ser perdidos, ou quando cada correção avaria outro caminho. O Shipvise acrescenta staging versionado, verificações, revisão e uma decisão de release explícita sem o obrigar a abandonar a sua ferramenta de IA. Não precisa de uma equipa de DevOps própria só por causa de uma aplicação.
FAQ
Perguntas que as pessoas realmente fazem
Vibe coding é sempre inseguro?
Não. O risco vem de comportamento não revisto e releases sem controlo, não do rótulo.
É preciso reescrever tudo?
Não automaticamente. Primeiro delimite a falha e compare uma reparação controlada com o risco da reescrita.
O que devo dar a um programador para corrigir isto?
Acesso ao repositório, o URL que falha, os passos para reproduzir o problema, os logs, o último commit que funcionava, a configuração de deploy e uma descrição do que a IA alterou.
Como corrijo uma aplicação vibe-coded que avariou de repente?
Primeiro, pare de pedir mais alterações à IA — cada nova tentativa pode esconder o que realmente avariou. Encontre o último ponto em que funcionava, compare-o com o estado atual, e corrija a regressão específica em vez de pedir à IA para reconstruir a funcionalidade do zero.
Porque é que o vibe coding continua a avariar funcionalidades que antes funcionavam?
Prompts amplos e rápidos tendem a tocar em mais partes da aplicação do que a tarefa exigia, por isso corrigir uma coisa pode avariar silenciosamente outra. Sem alterações pequenas e revisíveis e sem testes, nada apanha esses danos colaterais até um utilizador os encontrar.
Devo continuar a pedir à IA para corrigir, ou isso só vai piorar?
Outro pedido de "corrige isto" pode ajudar. Também pode avariar mais três coisas. Preserve primeiro a versão avariada atual, perceba o que realmente mudou, e dê à IA uma tarefa mais restrita e específica em vez de repetir o mesmo pedido vago.
Não uso Git — como volto a uma versão que funcionava?
Verifique se a sua ferramenta de IA tem histórico de versões ou checkpoints, uma exportação anterior, ou um deploy anterior que possa restaurar. Se nada disso existir, este é o momento certo para começar a guardar — mesmo uma cópia manual do projeto antes de cada alteração grande ajuda da próxima vez.
Um programador consegue corrigir uma aplicação feita com Lovable, Bolt, Replit ou Cursor mesmo sem a ter construído?
Sim. Um programador não precisa de ter usado a mesma ferramenta — precisa de acesso ao código, do comportamento que falha e do que mudou recentemente. A aplicação final continua a ser apenas código e serviços; a ferramenta de IA usada para a gerar não muda isso.