Aula 11. Como salvar um app de vibe coding que quebrou

Dica de ouro — é isso que você precisa saber

O app quebrou. O login que funcionava ontem não funciona mais. O pagamento é cobrado duas vezes. A cada toque no código, algo diferente quebra. Quando você pede à IA para “consertar”, piora ainda mais.

Não reconstrua do zero. Mesmo que reconstrua, vai quebrar no mesmo lugar em 3 meses. Trave o estado atual primeiro.

Existem três ferramentas estruturais:

• codistill — Diagnóstico. Extrai automaticamente os endpoints de API, o esquema do banco de dados e o fluxo de autenticação do código existente.
• huma — Travamento. Adiciona testes de regressão em todos os endpoints para proteger o comportamento atual.
• yongol — Conversão. Gera um novo backend a partir do SSOT e prova o comportamento equivalente com os testes existentes.

O fluxo vai da esquerda para a direita: diagnostica com codistill, trava com huma e, quando estiver pronto, converte com yongol.

Para o agente: “Execute codist scan para extrair os endpoints, o esquema do banco de dados e o fluxo de autenticação deste projeto.”

A situação atual aparece. Você vê quantos dos 25 endpoints estão vivos e quantos estão mortos.

Para o agente: “Execute huma verify para verificar o status de todos os endpoints e escreva um teste Hurl para cada um que estiver vivo.”

Esses são os testes de regressão. Você trava o que funciona agora. Enquanto esses testes passarem, o comportamento existente não vai quebrar mesmo que o agente modifique o código.

Para o agente: “Agora conserte o bug do login. Mas todos os testes Hurl precisam passar.”

Você conserta o bug sem quebrar nada mais. O reparo acontece com o ratchet travado.

Experiência introdutória

Mesmo sem um app quebrado, você pode experimentar. Vivencie o processo “construir → quebrar → salvar” em 3 minutos.

Passo 1 — Construa o app

No Claude Code:

“Crie uma API simples de lista de tarefas. 5 endpoints: listar tarefas, adicionar tarefa, editar tarefa, excluir tarefa, marcar tarefa como concluída. Suba o servidor.”

Passo 2 — Diagnostique com codist

“Execute codist scan para extrair a lista de endpoints deste projeto.”

O codist extrai automaticamente o caminho, o método e os parâmetros dos 5 endpoints. Esse é o mapa atual.

Passo 3 — Trave com huma

“Execute huma verify e escreva testes Hurl para todos os endpoints.”

Um arquivo Hurl é criado para cada um dos 5 endpoints. O comportamento atual está travado.

Passo 4 — Quebre de propósito

“Mude o formato de resposta do endpoint de edição de tarefa. Renomeie o campo title para name.”

Depois da mudança:

“Execute os testes Hurl.”

O teste falha. “Era esperado title, mas veio name.” O drift foi capturado. O ratchet funcionou.

Passo 5 — Conserte com o ratchet travado

“Modifique para que todos os testes Hurl passem. Mas também mantenha a nova funcionalidade que usa o campo name.”

O agente mantém a compatibilidade retroativa ao modificar. Hurl passando significa que o comportamento existente foi preservado.

Esse é o modelo reduzido de codistill → huma → reparo. Em apps realmente quebrados, esse processo se expande para 25, 50 ou 200 endpoints, mas o princípio é o mesmo.

Por que você deve trabalhar dessa forma

Introdução: o verdadeiro motivo pelo qual seu app quebrou

Em 2025, os bancos de dados de 170 apps construídos com Lovable ficaram completamente expostos na internet. E-mails, chaves de API, dados de pagamento. A causa não foi um bug de código. A IA criou os apps sem políticas de segurança e ninguém verificou.

Em janeiro de 2026, 1,5 milhão de tokens de API vazaram da rede social Moltbook. Mesma causa. A IA construiu, o humano não verificou.

Isso não é história dos outros. Quem construiu um app com vibe coding está sentado em cima da mesma estrutura.

“Crie login” — 30 segundos. “Adicione pagamento” — 2 minutos. “Adicione painel de administrador” — 5 minutos. Após 3 meses a IA “organiza” a lógica de pagamento e muda o cálculo de desconto, adicionar uma nova funcionalidade quebra a autenticação, e a página que funcionava ontem retorna erro 500 hoje.

Você está diante de duas escolhas:

1. Reconstruir
2. Salvar

Reconstruir era possível 3 meses atrás. O problema é que o mesmo padrão se repete ao reconstruir. O drift é um problema estrutural, não de código.

Você precisa aprender a salvar.

Método de autorescate do náufrago — 5 etapas

Salvar um app quebrado é como responder a uma situação de emergência em uma trilha. Não corra. Identifique sua posição atual, garanta sua segurança e avance passo a passo.

Etapa 1. Diagnóstico — o que ainda está vivo?

A primeira coisa a fazer não é consertar o código. É entender a situação atual.

Para o agente: "Escaneie todos os endpoints de API neste projeto.
Envie uma requisição real para cada endpoint
e registre o código de status da resposta.
Organize os resultados em uma tabela: caminho, método, código de status, tempo de resposta."

Se 18 dos 25 endpoints retornam 200, 4 retornam 401 e 3 retornam 500 — esse é o mapa atual. Começar o reparo sem mapa faz com que o que foi consertado quebre outras partes.

O codist scan do codistill automatiza essa tarefa. Extrai do código existente os endpoints, modelos de dados e fluxos de autenticação.

Etapa 2. Travamento — proteja o que está vivo primeiro

Após o diagnóstico, trave os endpoints vivos.

Para o agente: "Escreva um teste Hurl para cada um
dos 18 endpoints que retornam 200.
Use a resposta atual como valores esperados.
Para os que exigem autenticação, execute
a sequência de login primeiro para obter o token."

Esses 18 arquivos Hurl são a rede de segurança. Independente de quais modificações forem feitas depois, se esses testes passarem, o comportamento existente foi preservado.

O huma verify do huma organiza esse processo. Rastreia o status por endpoint e julga PASS/IMPROVE/FAIL.

Importante: travamento parcial não é permitido. Travar apenas 10 dos 18 significa que os outros 8 podem quebrar durante o reparo sem que você saiba. Travamento total é o princípio.

Etapa 3. Reparo — conserte com o ratchet travado

Com a rede de segurança pronta, agora você pode consertar os bugs.

Para o agente: "Encontre a causa do falha no login e conserte.
Mas todos os testes Hurl devem passar.
Se algum falhar, desfaça a modificação."

Essa é a aplicação prática do Ratchet Pattern que você aprendeu na Aula 6. Conserta sem quebrar. Após cada reparo, executa o Hurl. Se passar, vai para o próximo bug. Se falhar, desfaz.

Os 3 endpoints que retornam 500 são reparados da mesma forma. Após o reparo, novos testes Hurl são adicionados. O ratchet trava mais um dente.

Etapa 4. Extração — tire a lógica da caixa preta

Aqui está o ponto central. A causa raiz do colapso do app geralmente está aqui.

Se você está usando Supabase:

• Políticas RLS existem apenas no painel, ausentes do código
• Lógica de negócio escondida em Edge Functions
• Lógica de autenticação presa no Supabase Auth

Se você está usando Firebase:

• Security Rules existem apenas no console
• Lógica distribuída pelo Cloud Functions

Independente do BaaS, a estrutura é a mesma. A lógica de negócio está fora do codebase.

Para o agente: "Extraia todas as políticas RLS do Supabase.
Salve as políticas SELECT, INSERT, UPDATE e DELETE
de cada tabela em arquivos SQL. Faça commit no git."

Para o agente: "Analise a lógica de negócio das Edge Functions.
Documente quais funções implementam quais regras de negócio."

O objetivo é mover a lógica de dentro da caixa preta para o codebase. Após mover, o agente pode ler, testar e travar com o ratchet.

O codist ddl do codistill extrai DDL do banco de dados existente. codist scan extrai SSOT do código. São ferramentas que movem da caixa preta para uma camada declarativa.

Etapa 5. Conversão — somente quando estiver pronto

Após completar as etapas 1-4, o app estará neste estado:

• Todos os endpoints têm testes de regressão Hurl
• Os bugs foram corrigidos
• A lógica da caixa preta foi documentada no codebase
• O ratchet está travado, impedindo que novas modificações quebrem o comportamento existente

Neste estado você decide a conversão. Do Supabase para backend próprio, de Deno para Go, o que for.

A rede de segurança da conversão são os testes Hurl escritos na Etapa 2. Execute o mesmo Hurl no novo servidor e, se tudo passar — fica provado que ele funciona da mesma forma que o legado.

Para o agente: "Execute yongol generate para criar o backend Go+Gin.
Faça passar todos os testes Hurl existentes."

A conversão é a Etapa 5, não a Etapa 1. Tentar converter na Etapa 1 vai falhar. Essa é uma lição confirmada por incidentes reais de onboarding.

Como sair do Supabase

O caso mais frequente na Aula 11 é o Supabase. As pessoas começam com vibe coding, colocam tudo no Supabase e após 3 meses tudo colapsa.

Ordem de saída:

1. Mantenha o banco de dados e apenas aplique o ratchet

Use o PostgreSQL do Supabase como está. Mudar o banco de dados vem por último.

codist ddl → extrai DDL das tabelas existentes
huma verify → entende o status atual dos endpoints
hurl → trava totalmente as APIs vivas

2. Mova a lógica para o código

Políticas RLS → arquivos Rego. Edge Functions → anotações SSaC. Do painel para o codebase.

3. Separe a autenticação

O Supabase Auth é o último a ser separado. Como não é possível extrair os hashes de senha de auth.users, se você está na fase inicial (sem clientes) converta imediatamente; se tem clientes, opere um período de autenticação dupla.

4. Suba o novo servidor e valide com Hurl

yongol generate → cria o backend Go+Gin
executa Hurl completamente → prova comportamento idêntico ao legado

Se o Hurl passar completamente, transfira o tráfego.

Por que você não deve reconstruir do zero

“Não seria mais fácil reconstruir do zero?”

Não. Três razões:

1. O padrão se repete

Drift é um problema estrutural, não de código. Reconstruir sem ratchet vai colapsar no mesmo ponto em 3 meses.

2. O conhecimento está enterrado no legado

As regras de negócio acumuladas em 3 meses de vibe coding estão no código. Reconstruir significa recompor essas regras da memória. E a memória erra.

3. Pode já haver clientes

Existe um momento em que o protótipo vira produção. Se há pelo menos um usuário, “reconstruir” implica migração de dados, conversão de autenticação e tempo de inatividade.

Aprender a salvar é mais valioso do que aprender a reconstruir. Porque código legado sempre existe, e um novo código se torna legado em 6 meses.

A relação entre o que você aprendeu nas Aulas 1-10 e a Aula 11

As mesmas ferramentas, direção oposta. Se as Aulas 1-10 eram “de cima para baixo” (declaração → geração), a Aula 11 é “de baixo para cima” (código existente → extração → declaração).

O codistill automatiza esse “de baixo para cima”. Extrai o SSOT do código existente.

De náufrago a resgatador

Ao concluir este processo, você terá duas habilidades:

1. Como construir desde o início (Aulas 1-10) — declarar, validar, travar, persistir
2. Como salvar o que falhou (Aula 11) — diagnosticar, travar, reparar, extrair, converter

A maior parte do código no mundo é legado. Projetos construídos do zero são raros. A habilidade de salvar é usada com mais frequência.

O vibe coding não acabou. Você aprendeu a segurar as rédeas.

Artigos relacionados

• Supabase é a armadilha do vibe coding — O contexto teórico da Aula 11. Por que o BaaS colapsa?
• Hurl previne o drift do vibe coding — Detalhes da etapa de travamento na Etapa 2.
• codistill — extrai SSOT do código existente — Ferramenta para diagnóstico na Etapa 1 e extração na Etapa 4.
• huma — ratchet que não perde um único endpoint — Ferramenta de travamento na Etapa 2.
• yongol — a quilha do SaaS de codificação AI — Ferramenta de conversão na Etapa 5. Gera fullstack a partir do SSOT.
• Codebase que o agente consegue operar — O princípio de transformar a caixa preta em fábrica.
• tsma — linha de defesa de regressão para código legado — Como reparar com o ratchet travado.
• Construindo sistemas que agentes conseguem operar — Como tornar o legado travado acessível ao agente.

Todas as aulas de Reins Engineering

Fontes

• Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — Characterization testing의 원전. 레거시 코드에 테스트를 감싸서 현재 동작을 잠그는 기법. 11강 2단계의 이론적 기초.
• CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
• OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 노출. blog.ogwilliam.com
• Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427 — Cursor 도입 후 코드 복잡도 41.6% 영구 증가. 바이브 코딩이 터지는 정량적 근거.
• Liu, Z. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arxiv.org/abs/2603.28592 — 6,299개 리포지토리, 302,600건 AI 커밋 분석. 미해결 기술 부채가 2025년 초 수백 건에서 2026년 2월 110,000건 이상으로 급증.
• Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — 드리프트의 근본 원인을 “인지 부채”(공유 이해 침식)와 “의도 부채”(근거의 미외부화)로 이론화.
• Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — 바이브 코딩의 flow-debt 트레이드오프를 문서화한 최초의 학술 논문.
• Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — AI 생성 코드의 45%가 OWASP Top 10 취약점 포함. AI 커밋의 시크릿 노출률 2배.
• GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — 2.11억 라인 분석. 코드 중복 4배 증가, 리팩토링 비율 25% → 10% 감소.
• Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — BaaS 이탈은 포팅이 아니라 백엔드 재작성.