Secrets, API keys, and vibe coding
How to use env vars and good habits so AI-assisted development stays fast without leaking credentials.
The fastest way to lose a weekend is pasting a production API key into a chat or a committed file. Good vibe coding keeps flow and safety at the same time.
Never put real secrets in the prompt
Describe what integrates (e.g. “email via Resend,” “database via Neon”) without pasting tokens. Point the model at environment variable names you will set locally and in production: RESEND_API_KEY, DATABASE_URL, and so on.
Use .env.local (or your host’s secrets UI)
- Local: keep secrets in env files that are gitignored; load them per your framework’s docs.
- Production: set the same variable names in Vercel, Railway, or your host — not in the repo.
If the AI generates a .env.example with placeholder values only, that’s ideal: it documents names without real secrets.
Rotate if something leaked
If a key ever hit chat history, a screenshot, or a public repo, assume it’s compromised. Revoke it in the provider’s dashboard, create a new key, update env vars, and move on — then tighten habits so it does not repeat.
Teach the model your rules once
Many tools support project rules or README snippets: “Never commit secrets; use env vars only.” That nudge reduces how often you have to fix the same mistake.
You’re building something worth sharing — when it’s live, submit it to VibeShare so others can discover it. For definitions of terms like blueprint and AI-assisted development, see the glossary.