Some mistakes in vibe coding cost you an afternoon. Others cost you your project, your users’ trust, or real money. This post covers the three practices that prevent the catastrophic kind: git discipline, secrets management, and testing.
These aren’t theoretical concerns. Every single one has documented real-world incidents.
Commit to Git Before Every Session
This is universally agreed upon and universally violated.
It’s easy to be in flow, shipping fast, feeling good — and then the AI takes a weird turn and you realize you have no clean restore point. Losing a week of work to a bad AI session has happened to almost everyone who vibe codes seriously.
Make it non-negotiable:
# Before every AI session — make this muscle memory
git add .
git commit -m "checkpoint: before [feature name]"
git push
Three rules:
- Every new feature gets a commit before the AI touches it. Not after it works — before the AI starts.
- Commit to a remote — not just local. Your laptop is not a backup.
- Commit messages don’t need to be poetry — they need to be breadcrumbs you can follow back.
If the AI goes off the rails:
# Discard everything since last commit
git reset --hard HEAD
# Or go back further
git log --oneline # find the commit you want
git reset --hard [hash]
The 10 seconds it takes to commit before a session is insurance against the worst hour of your coding life.
Keep Secrets Sacred
There have been documented, real incidents of AI coding assistants reading .env files and including API keys in test files, commits, or context uploads. One exposed Stripe key means someone can redirect your revenue. One exposed database credential means someone can wipe your users.
Every path a secret can take is shown above. The red paths are all avoidable.
The non-negotiable checklist — day one of every project:
# Before anything else
echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
echo ".env.production" >> .gitignore
# Commit a template — never the real file
cp .env .env.example
# Replace all values with placeholders
git add .env.example
git commit -m "add env template"
Block Claude Code from reading your .env:
// ~/.claude/settings.json
{
"permissions": {
"deny": ["Read(./.env*)", "Read(./.env.local)", "Read(./.env.production)"]
}
}
For production, graduate to a proper vault — Doppler, 1Password Secrets, or AWS Secrets Manager. Your .env is a good place to start. It’s not a good place to end.
Separate dev and prod keys. A dev Stripe key with no production access is a contained incident if it leaks. A production key is not.
If your
.envhas ever appeared in an AI conversation context, treat every secret in it as potentially compromised. Rotate immediately.
Test After Every Change
Testing in vibe coding isn’t dogma. It’s about not flying blind. Every change you make without testing is a change that might have broken something you won’t discover until it’s in front of a user.
A pragmatic testing progression:
Start with backend and data layer tests — command-line, no browser needed, immediate feedback. If your data behaves correctly, half your bugs are already prevented.
For frontend, calibrate to complexity. A landing page can be eyeballed. A multi-state UI with user interactions warrants automated tests on the critical paths.
The question to ask before each feature: If this breaks silently in production, how bad is it? The worse the answer, the more test coverage it needs.
The best prompt shift for AI-assisted testing:
Write tests first for [feature]. Then implement the code
to make them pass. Run the tests and fix until green.
Don't stop until all tests pass.
This forces the AI to reason about expected behavior before generating code. Output quality improves dramatically.
For projects with a database, a useful baseline:
async function smokeTest() {
const { data, error } = await supabase.from("your_table").select("*").limit(1);
if (error) throw new Error(`Data layer broken: ${error.message}`);
console.log("Data layer OK:", data);
}
Run this before building UI on top of your data layer. It takes 10 seconds and catches connection issues, permission problems, and schema drift before they cascade.
The Three Together
These three practices are interconnected:
- Git discipline gives you the safety net to move fast
- Secrets management prevents the kind of breach that kills projects overnight
- Testing catches the silent failures before users do
Skip one and the other two compensate less. Practice all three and you have a foundation that lets you ship with genuine confidence — fast and safe at the same time.
The projects that survive aren’t the ones built fastest. They’re the ones where someone cared enough about the fundamentals to do them every session, not just the first one.