Quick Tip — This Is All You Need to Know to Get Started
The app broke. Login that worked yesterday doesn’t work today. Payments are being charged twice. Every code change breaks something else. Telling the AI to “fix it” makes things worse.
Don’t rebuild. Rebuilding lands you in the same place three months from now. Lock down the current state first.
Three structural tools:
- codistill — Diagnose. Automatically extracts API endpoints, DB schemas, and auth flows from existing code.
- huma — Lock. Puts regression tests on every endpoint to protect current behavior.
- yongol — Migrate. Generates a new backend from SSOT and proves identical behavior using the existing tests.
Work left to right. Diagnose with codistill, lock with huma, and migrate with yongol when ready.
Tell the agent: “Run codist scan to extract the endpoints, DB schema, and auth flows for this project.”
You get the current state. You can see how many of the 25 endpoints are alive and how many are dead.
Tell the agent: “Run huma verify to check the status of all endpoints, and write a Hurl test for each live one.”
This is your regression test suite. It locks what’s currently working. As long as these tests pass, the agent can modify code without breaking existing behavior.
Tell the agent: “Now fix the login bug. But all Hurl tests must pass.”
Fix the bug without breaking anything else. You’re making repairs with the ratchet engaged.
Try It Yourself
You don’t need a broken app to try this. Experience the “build → break → rescue” cycle in under three minutes.
Step 1 — Build the app
In Claude Code:
“Create a simple to-do list API. Five endpoints: list todos, add todo, update todo, delete todo, mark todo complete. Start the server.”
Step 2 — Diagnose with codist
“Run codist scan to extract the list of endpoints for this project.”
codist automatically pulls the path, method, and parameters for all 5 endpoints. This is your current map.
Step 3 — Lock with huma
“Run huma verify and write a Hurl test for every endpoint.”
A Hurl file is generated for each of the 5 endpoints. Current behavior is now locked.
Step 4 — Break it on purpose
“Change the response format of the update todo endpoint. Rename the title field to name.”
After the change:
“Run the Hurl tests.”
A test fails. “Expected title but got name.” Drift is caught. The ratchet is working.
Step 5 — Make repairs with the ratchet engaged
“Fix it so all Hurl tests pass. But the new feature using the name field must be preserved too.”
The agent maintains backward compatibility while applying the fix. When Hurl passes, existing behavior is preserved.
This is a miniature version of codistill → huma → repair. With a real broken app the process scales to 25, 50, or 200 endpoints — the principle is the same.
Why This Is the Right Approach
Introduction: The Real Reason Your App Broke
In 2025, the databases of 170 apps built with Lovable were exposed to the internet — emails, API keys, payment information. The cause wasn’t a code bug. AI built the apps with security policies missing, and nobody verified them.
In January 2026, 1.5 million API tokens leaked from the AI social network Moltbook. Same cause. AI built it, humans didn’t check.
This isn’t someone else’s story. If you built an app with vibe coding, you’re sitting on the same structure.
“Make a login” — 30 seconds. “Add payments” — 2 minutes. “Add an admin dashboard” — 5 minutes. Three months later, AI “cleans up” the payment logic and changes discount calculations, adding a new feature breaks auth, and a page that worked yesterday returns a 500 error today.
You face two choices:
- Rebuild
- Rescue
Rebuilding was an option three months ago. The problem is that rebuilding repeats the same pattern. Drift is not a code problem — it’s a structural problem.
You need to learn how to rescue.
Self-Rescue for the Stranded — 5 Steps
Rescuing a broken app is like responding to a hiking emergency. Don’t run. Identify your position, secure safety, and move one step at a time.
Step 1. Diagnose — What Is Still Alive
The first thing to do is not fix the code. It’s understand the current state.
Tell the agent: "Scan all API endpoints in this project.
Send an actual request to each endpoint and
record the response status code.
Summarize results as a table: path, method, status code, response time."
If 18 of 25 endpoints return 200, 4 return 401, and 3 return 500 — that is your current map. Start repairs without a map and fixes break other things.
codistill’s codist scan automates this work. It extracts endpoints, data models, and auth flows from existing code.
Step 2. Lock — Protect What’s Alive First
Once diagnosed, lock the live endpoints.
Tell the agent: "Write a Hurl test for each of the 18 endpoints returning 200.
Use the current response as the expected value.
For endpoints requiring auth, run the login sequence first to
get a token and use it."
These 18 Hurl files are your safety net. No matter what changes come next, if these tests pass, existing behavior is preserved.
huma’s huma verify systematizes this process. It tracks status per endpoint and grades each as PASS/IMPROVE/FAIL.
Important: Partial locking won’t do. If you lock only 10 of the 18 endpoints, you won’t know if the other 8 break during repairs. Full coverage is the rule.
Step 3. Repair — Fix With the Ratchet Engaged
With the safety net in place, you can now fix bugs.
Tell the agent: "Find and fix the cause of the login failure.
All Hurl tests must pass.
If any test fails, revert the change."
This is real-world application of the Ratchet Pattern from Class 6. Fix without breaking. Run Hurl after every repair. Pass — move to the next bug. Fail — revert.
Fix the 3 endpoints returning 500 errors the same way. Once repaired, add new Hurl tests. The ratchet clicks one notch tighter.
Step 4. Extract — Pull Logic Out of the Black Box
This is the critical step. The root cause of a broken app is usually here.
If you’re using Supabase:
- RLS policies exist only in the dashboard, not in the code
- Business logic is hidden inside Edge Functions
- Auth logic is tied to Supabase Auth
If you’re using Firebase:
- Security Rules exist only in the console
- Logic is scattered across Cloud Functions
Same structure regardless of which BaaS you use. Business logic lives outside the codebase.
Tell the agent: "Extract all RLS policies from the Supabase dashboard.
Save the SELECT, INSERT, UPDATE, DELETE policies for each table
as SQL files. Commit to git."
Tell the agent: "Analyze the business logic in Edge Functions.
Document which functions implement which business rules."
This is pulling logic from the black box into the codebase. Once out, the agent can read it, test it, and lock it with the ratchet.
codistill’s codist ddl extracts DDL from existing databases. codist scan extracts SSOT from code. These are tools for moving from black box to declarative layer.
Step 5. Migrate — Only When Ready
After steps 1–4, the app is in this state:
- Every endpoint has a Hurl regression test
- Bugs are fixed
- Black-box logic is documented in the codebase
- The ratchet is engaged, preventing new changes from breaking existing behavior
From this state, decide on migration. Supabase to self-hosted backend, Deno to Go, whatever.
The migration safety net is the Hurl tests written in step 2. Run the same Hurl against the new server — if everything passes, identical behavior with the legacy is proven.
Tell the agent: "Generate a Go+Gin backend with yongol generate.
Make all existing Hurl tests pass."
Migration is step 5, not step 1. Attempting migration at step 1 will fail. This is a lesson confirmed in incident onboarding.
How to Escape Supabase
The most frequent Class 11 scenario is Supabase. Start with vibe coding, go all-in on Supabase, and three months later it breaks.
The exit sequence:
1. Keep the DB, just add the ratchet
Keep Supabase’s PostgreSQL as-is. Changing the DB comes last.
codist ddl → extract DDL from existing tables
huma verify → assess endpoint status
hurl → lock all live APIs
2. Move logic into code
RLS policies → Rego files. Edge Functions → SSaC annotations. Move from dashboard to codebase.
3. Decouple auth
Supabase Auth is the last thing to remove. Since password hashes can’t be extracted from auth.users, migrate immediately if there are no customers yet; if customers exist, run a dual-auth period.
4. Bring up the new server and validate with Hurl
yongol generate → generate Go+Gin backend
run all hurl tests → prove identical behavior to legacy
When Hurl passes entirely, switch over the traffic.
Why You Shouldn’t Rebuild
“Can’t I just rebuild from scratch?”
No. Three reasons:
1. The same pattern repeats
Drift is a structural problem, not a code problem. Rebuilding without a ratchet puts you back at the same breaking point in three months.
2. Knowledge is buried in the legacy
Three months of vibe coding accumulated business rules in the code. Rebuilding means reconstructing those rules from memory. Memory is wrong.
3. You may already have customers
There’s a moment when a prototype becomes production. If even one user exists, “rebuild” means data migration, auth transition, and downtime.
Learning to rescue is more valuable than learning to rebuild. Because legacy always exists, and new code becomes legacy in six months.
How Class 11 Relates to Classes 1–10
| Class | Building right from the start | Class 11: Rescuing what broke |
|---|---|---|
| Class 3 Hurl | Declare the API contract | Lock existing behavior as regression tests |
| Class 4 yongol | Generate from SSOT | Extract SSOT from existing code |
| Class 6 Ratchet | Lock when tests pass | Fix without breaking |
| Class 8 filefunc | Structure the code | Clean up legacy code |
| Class 10 DDL | Declare the schema | Extract DDL from existing DB |
Same tools, opposite direction. Classes 1–10 went “top-down” (declare → generate). Class 11 goes “bottom-up” (existing code → extract → declare).
codistill is the tool that automates this “bottom-up” extraction. It distills SSOT from existing code.
From Stranded to Rescuer
After completing this process, you have two capabilities:
- How to build from scratch (Classes 1–10) — declare, verify, lock, persist
- How to rescue what broke (Class 11) — diagnose, lock, repair, extract, migrate
Most code in the world is legacy. Projects built from scratch are rare. The ability to rescue gets used more often.
Vibe coding isn’t over. You’ve learned how to hold the reins.
Related Articles
- Supabase Is a Vibe-Coding Trap — The theoretical background for Class 11. Why BaaS breaks.
- Hurl Stops the Drift in Vibe Coding — Details on step 2 locking.
- codistill — Distilling SSOT from Existing Code — Tool for step 1 diagnosis and step 4 extraction.
- huma — The Ratchet That Misses No Endpoint — Tool for step 2 locking.
- yongol — The Keel of AI Coding SaaS — Tool for step 5 migration. Full-stack generation from SSOT.
- An Agent-Operable Codebase — The principle behind turning a black box into a factory.
- tsma — Regression Defense for Legacy Code — How to make repairs with the ratchet engaged.
- Building Agent-Operable Systems — Making locked legacy reachable by agents.
Reins Engineering — All Classes
| Class | Title |
|---|---|
| Class 1 | How to Delegate to AI |
| Class 2 | How to Distrust AI |
| Class 3 | Apps That Don’t Break |
| Class 4 | Decisions Outside the Code |
| Class 5 | AI on a Leash |
| Class 6 | Lock When Tests Pass |
| Class 7 | Flipping Sycophancy |
| Class 8 | The Agent’s Factory |
| Class 9 | Automation Beyond Code |
| Class 10 | The Law of Data |
| Class 11 | How to Rescue a Broken Vibe-Coded App |
Sources
- Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — The original work on characterization testing. The technique of wrapping legacy code in tests to lock current behavior. Theoretical foundation for Class 11, step 2.
- CVE-2025-48757 (2025). Lovable-generated apps 170+ with missing RLS exposing Supabase DBs. ameeba.com
- OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API token exposure. 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 — Permanent 41.6% increase in code complexity after Cursor adoption. Quantitative evidence for why vibe coding breaks.
- 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 — Analysis of 6,299 repositories and 302,600 AI commits. Unresolved technical debt surged from hundreds in early 2025 to over 110,000 by February 2026.
- Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — Theorizes the root cause of drift as “cognitive debt” (erosion of shared understanding) and “intent debt” (unexpternalized rationale).
- Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — The first academic paper documenting the flow-debt tradeoff in vibe coding.
- Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — 45% of AI-generated code contains OWASP Top 10 vulnerabilities. Secret exposure rate in AI commits is 2x.
- GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — Analysis of 211M lines. Code duplication 4x increase, refactoring ratio down from 25% to 10%.
- Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — BaaS exit is not porting — it’s a backend rewrite.