Vibe Coding Live-Saving Tips and Tricks

How not to delete your database and other things I have seen

It’s official. Vibe coding is just coding now, ask Andrej Karpathy. It’s not a trend or a fad. It turns out that the persnickety ‘alpha’ dev who sneered at anyone who had no interest in the most elegant sorting algorithm or inverting binary trees, were actually the ones in the Cargo Cult.

Nobody gives a single shit who designed the lifters on the Chevy 427 big block. They want to hear the glug glug and roar of that engine in a 69 Camaro.

The future belongs to the builders with vision.

Write It All Down First

This is product management 101 but it applies directly here. Before you touch Claude Code or Cursor or whatever, write out what you actually want. I mean really write it out. Your user context. The story. The use case. The job to be done. Include acceptance criteria like you would for any ticket you’d hand to a developer. Because that’s what you’re doing. You’re handing a ticket to a developer. The developer just happens to be an LLM.

Then, have the AI spit back out a step by step implementation guide as to what it is going to do. It’s probably going to do this anyway because that’s how these tools work, but if you provide clear context upfront it will be much more likely to give you what you actually want instead of what it thinks you want. This back and forth takes five minutes and will save you hours of frustration and rework.

Context Management is Everything

Turn off auto-compress. I know it’s on by default at 70% context usage and it seems helpful. It’s not. That context window is precious real estate and you need it for the things that actually matter: your markdown files, your coding standards, your current task context. Don’t let the tool decide what to forget.

Here’s my workflow. I keep markdown docs for architecture decisions, data models, current task lists, and the state of whatever I’m working on. When I start a new chat, and I always start a new chat for a new task, I have Claude read the relevant context files first. The to-do list. The files from the previous session. Whatever it needs to understand where we are. Then I make it tell me exactly what it’s going to do before it writes a single line of code. Every single time.

This sounds tedious, but it takes about two minutes. The alternative is Claude making reasonable assumptions that are wrong because it doesn’t have context, and you spending an hour debugging code that never should have existed.

Always start fresh chats for new tasks. Always load the relevant files from previous work. Always make it explain the plan before executing. This is non-negotiable.

Coding Standards That Actually Work

I have a detailed, language-and-framework-specific coding standards file that lives in claude.md. This isn’t vague stuff like “write clean code.” It’s specific and contains thing like how long functions should be. How big a file can get before you break it up? When to create a new file versus adding to an existing one. Naming conventions. Error handling patterns. Readability rules. Conciseness rules. Debuggability rules.

These standards came from actual developers I’ve worked with over the years. They’re opinionated and specific. Claude follows them reasonably well when you tell it to.

The key insight here is this: write code as though one person wrote it, and write it so an LLM can debug it later. Those are the two rules. Because here’s what happens if you don’t. Claude gets creative. It has little clever code-genius boners where it writes something elegant and compact that works great until it doesn’t, and then neither you nor Claude can figure out what the hell it was trying to do. Debugging becomes a nightmare because every file looks like a different person wrote it.

Boring, consistent, readable code is what you want. The kind of code a junior developer could follow. The kind of code an LLM can parse when something breaks at 2am. Save the cleverness for the product itself.

Security Audit Prompts

Don’t just vaguely ask Claude to check for security issues. Have a specific security audit prompt with the common vulnerabilities enumerated. (SQL injection. XSS. CSRF. Auth bypass. Exposed secrets. Insecure direct object references. All of it, listed out explicitly.)

Then add a section where you tell Claude to act as a security researcher. Have it think deeply about edge cases specific to your application. Have it do a web search for vulnerabilities related to whatever stack you’re using. Make it produce a prioritized implementation plan for everything it finds.

This isn’t a five-second check. It’s a dedicated audit pass that you run regularly. Build it into your workflow like you would any other quality gate. Set this up once, and never do it again. Just run it periodically to make sure that your application is secure.

Just Use an IDE

Don’t use Replit. Don’t use v0. Don’t use whatever web-based vibe coding toy launched this week. Use Claude Code (or Codex, or Gemini) in a real IDE. Or Cursor. Or Windsurf. Something that runs locally, has access to your actual file system, and isn’t trying to abstract away the things you need to control.

The web-based tools are fine for throwaway experiments. They are not fine for building anything real. You need to see your project structure. You need proper version control. You need to be able to manage context and environment variables and all the other stuff that matters. The shiny browser tools optimize for getting you to a demo fast. They do not optimize for building maintainable software.

Key Separation: Claude Never Touches Production

This is the one that will save you from actual disaster. Set up two complete sets of keys and credentials for everything. One set for development that lives in .env and that Claude has access to. One set for production that Claude never sees.

I use Neon for databases, Firebase, Vercel, Render. Every single one has separate dev and prod credentials. I clone the database. I run migrations twice, once for each environment. Claude operates entirely in the dev sandbox. It literally cannot access production data. It cannot delete real users. It cannot expose production API keys because it doesn’t have them.

Yes, this means you have to do work manually in production when you launch. Migrations, testing, configuration. That’s fine. That’s a feature, not a bug. The vibe coding tools don’t enforce any of this yet, but if you set it up yourself you can never make an irreparable mistake. Claude can trash your dev database six times a day and it doesn’t matter. Your actual users and their data are behind a wall it can’t climb.

I learned this the hard way. Claude has exposed my .env keys multiple times. These are not edge cases, they’re normal behavior when you’re moving fast. The only solution is architectural: production credentials exist in a place the LLM cannot reach.

Data Backups: Another Firewall

I have a GitHub action that backs up my database and storage buckets on a schedule. I have a disaster recovery plan documented. And critically, the keys for the backup system are never in .env. They’re never shared with Claude. This is another firewall.

If somehow everything goes wrong, if Claude does something catastrophic in dev, if I do something catastrophic manually in prod, there’s a backup that was created by a system the LLM has no access to. Belt and suspenders. You will be grateful for this the first time you need it.

The Point

There’s still a lot of detail to manage here. I’m not going to pretend vibe coding is just talking to your computer and magic happens. It requires discipline and setup and good habits.

But here’s the thing: this is the worst these tools will ever be. Right now, in late 2024, we’re in the early jank phase where you have to manually enforce key separation and context management and coding standards. All of this stuff will get abstracted away. Probably within months. The tools will get better at not exposing your secrets. They’ll get better at maintaining context. They’ll get better at consistent code style.

The “real developers” who declare vibe coding dead are doing the same thing they always do. They see the current limitations, they see people making amateur mistakes, and they assume this is the ceiling. Meanwhile they don’t apply the same rigor to AI-assisted development that they would to any other professional software project, and then act surprised when it produces unprofessional results.

The fundamentals haven’t changed. You still need to think about architecture. You still need to manage your environments. You still need security hygiene and backups and consistent standards. The part that changed is that the mechanical act of typing code is no longer the bottleneck. And, you can actually ask Claude exactly how to do the manual steps, at any level of technical ability.

Back to my car analogy, the lifter engineers are still necessary. But there’s a lot more room now for people who can envision the whole car.