explainx / blog
Wiped databases, broken auth, three-hour debugging loops, and code no one can maintain. These are the real disasters vibe coders run into — and exactly what to do instead.
Jun 29, 2026
Karpathy's viral line predated vibe coding by two years. English became the interface — but agents, repos, and tests became the runtime. A 2026 read on prompt-as-program from GPT-3 to shipping software in plain language.
Jun 27, 2026
Vibe coding explained: what it actually means, how to do it with Claude Code and Cursor, what you can realistically build, and where the limits are in 2026.
Jul 17, 2026
Full-stack AI engineer Kr$na (@krishdotdev) posted the "new development cycle" July 16, 2026 — idea in minutes, working demo in hours, six months on the last 10%, then infinity in the graveyard. ThePrimeagen called it first principles. explainx.ai maps where AI actually helps and where human obsession still wins.
Vibe coding is genuinely powerful. It's also genuinely dangerous if you don't know where it breaks.
The disasters are predictable. The same mistakes happen to beginners and experienced builders alike. This guide documents the real ones — with the exact behaviour that causes each and what to do instead.
What happens:
You're building a side project with a local PostgreSQL database. You tell Claude Code: "Delete all the test data and reset the users table." You meant the fake users you seeded for development. The AI runs TRUNCATE users CASCADE. In a staging environment connected to real data, that wipes 40,000 users and cascades deletes through orders, sessions, and preferences.
Or a more subtle version: you say "clean up old records" and the AI runs DELETE FROM sessions WHERE created_at < NOW() - INTERVAL '7 days' — but your sessions table uses created_at to store permanent user data, not just session timestamps. Everything older than a week is gone.
Why it happens:
AI agents execute what you describe, not what you meant. They don't know the difference between "test data" and "production data." They don't know your table means something different from what it looks like.
The fix:
Before running any SQL that deletes, truncates, or drops anything,
show me the exact query and wait for me to type CONFIRM.
Wrap any destructive operations in a transaction. Show me what it will do
before committing.
pg_dump mydb > backup_$(date +%Y%m%d).sql.What happens:
You build an API that lets users update their profile. The AI generates an endpoint like:
app.put('/api/user/:id', async (req, res) => {
const { id } = req.params;
const updates = req.body;
await db.user.update({ where: { id }, data: updates });
res.json({ success: true });
});
This looks fine. It is not fine. Any user can pass { "role": "admin" } in the body and promote themselves. Or pass { "id": 2 } and update someone else's record. The AI wrote functional code that is completely insecure.
Other common AI security holes:
const key = "sk-ant-..." in a .tsx file)Why it happens:
AI models optimise for code that works, not code that's safe. Security requires understanding threat models — who might send unexpected input and why — which requires knowing your context. The AI doesn't know if your app is internal-only or public-facing.
The fix:
Review everything you just wrote for security issues.
Check: are secrets ever in frontend code? Is user input validated?
Are there SQL injection risks? Are routes authenticated where they should be?
Flag every issue you find.
Users should only be able to update their own records.
Verify the authenticated user's ID matches the record being updated.
.env files. Ask the AI: "Are there any hardcoded secrets or API keys in this code?"What happens:
You start a Claude Code session with a clear goal. After 45 minutes and 20 back-and-forths, the app "works" but nobody — including the AI — knows what it actually does anymore. The auth flow calls three different session handlers. Two components share global state in a way that causes random re-renders. The database schema has been migrated four times with conflicting column names. Everything sort of works until it doesn't.
You try to fix a bug. The AI makes a change that breaks something else. You describe the new breakage. It fixes that and breaks the first thing. You're in a loop.
Why it happens:
AI agents don't maintain a mental model of the system. Each prompt gets a context window of what's visible — but after 20 edits, the visible code no longer matches any coherent design. The AI is patching patches.
The fix:
git add .
git commit -m "Working: user profile page"
git checkout HEAD~1.CONTEXT.md in the project folder:
# Project context
This is a job tracker. Users can add jobs and track status.
Stack: Next.js App Router, Prisma, PostgreSQL, Tailwind.
Current task: build the status update endpoint.
Do not modify the auth setup in /app/api/auth/.
What happens:
Your app worked yesterday. You made a change today — added a new page, installed a package — and now something unrelated is broken. You can't reproduce the exact break. You start describing symptoms to the AI and it starts guessing. An hour later you've changed 12 files and the original bug still exists plus two new ones.
Why it happens:
Without a clean diff, neither you nor the AI knows what actually changed. Vibe coding sessions often touch multiple files. If you don't commit between working states, you lose the ability to isolate what broke.
The fix:
git add . && git commit -m "feature: X working". You can always git diff HEAD~1 to see exactly what changed.git diff
What happens:
You vibe-coded a working app. Three months later you need to change something. You open the code and it's thousands of lines with no structure — logic mixed with UI, variables named data2 and tempResult, inline styles everywhere, and a function called handleStuff that does six different things. The AI can't help because it can't understand what the code is supposed to do either.
Why it happens:
AI generates working code for the current task, not maintainable code for future tasks. Unless you ask for structure and naming, you get whatever the AI defaults to.
The fix:
Separate this into: a data fetching function, a transformation function,
and the rendering component. Name functions clearly by what they do.
Use descriptive variable names. No abbreviations except standard ones
(id, url, req, res). No variables named data, result, temp, or stuff.
Review the files you've edited in this session. Rename any unclear variables,
split any functions over 30 lines into smaller named functions,
and remove any dead code.
What happens:
You're 90 minutes into a Claude Code session building a complex feature. The AI starts making weird suggestions that contradict things it set up earlier. It re-imports a library it already imported. It suggests adding a function that already exists. The quality of output has degraded noticeably.
Why it happens:
AI models have context windows. After a long session with many file reads and writes, older context gets compressed or dropped. The AI is working with less information about what it built earlier.
The fix:
Summarise what we've built in this session: which files were created or modified,
what each does, and what still needs to be done.
I'll use this to brief the next session.
[Paste summary]
Continue from here. Read these files first: [list the key files].
The next task is: [specific next thing].
CONTEXT.md updated. After each session, update it with what was completed.What happens:
You ask the AI to "set up authentication." It chooses JWT with tokens stored in localStorage, a custom session table, and an expiry of 30 days. You ship it. Six months later you learn that storing JWTs in localStorage is a well-known XSS vulnerability, your token invalidation doesn't work, and you have to rebuild the whole auth system.
Why it happens:
The AI makes reasonable-sounding default choices. It doesn't know your security requirements, your user base, or what "good enough" means in your context. It optimised for something that works, not something that's right for your situation.
The fix:
For any foundational decision — auth, database schema, API design, billing — don't let the AI choose:
What are the security tradeoffs of the auth approach you just implemented?
What could go wrong and what would I need to add to make it production-safe?
Before going live with a vibe-coded project:
[ ] Secrets in .env, never in code
[ ] .env in .gitignore
[ ] API routes check authentication where needed
[ ] User input is validated before hitting the database
[ ] No user can access or modify another user's data
[ ] Database is backed up (or recreatable from migrations)
[ ] Error messages don't expose internal details to users
[ ] Tested at least one edge case per form (empty input, very long input, special chars)
[ ] Rate limiting on auth endpoints
[ ] Reviewed the git diff since last working commit
You don't have to do this for a prototype. You absolutely have to do it before real users touch it.
Every disaster in this list has the same root cause: treating the AI as if it knows what you know.
The AI doesn't know that "clean up" means test data, not all data. It doesn't know your security requirements. It doesn't know what "working" meant three sessions ago. It doesn't know that this user-facing endpoint needs auth.
The skill in vibe coding is specificity. The more explicitly you say what you want — and don't want — the fewer disasters you have. The disasters aren't the AI's fault. They're gaps between what you said and what you meant.