Vibe Coding Best Practices: 12 Rules for Shipping AI-Generated Code

Why Best Practices Matter More for Vibe Coding

When you write code yourself, best practices are habits you build over years. You learn to add error handling because you have been burned by silent failures. You learn to validate inputs because you have seen SQL injection in production. You learn to write tests because you have shipped bugs that a test would have caught.

Vibe coding compresses the timeline. You go from idea to deployed app in hours instead of months. There is no time to build those habits through experience. The AI generates code that works but skips the defensive patterns that experienced developers add instinctively.

These 12 rules are the habits you do not have time to learn the hard way. Each one addresses a specific pattern that shows up repeatedly in AI-generated code across Cursor, Bolt, Lovable, Claude Code, and every other AI coding tool.

Rule 1: Scan After Every AI Coding Session

Before you close your laptop, run a diagnostic scan on what the AI just built. Not tomorrow. Not before launch. After every session.

AI tools make dozens of changes across multiple files in a single session. Some of those changes introduce security vulnerabilities, performance issues, or broken patterns that are invisible until you look for them. A scan takes under 5 minutes and tells you exactly what needs attention while the context is still fresh in your mind.

VibeDoctor runs 129+ checks in a single scan. The free tier gives you 1 scan per day - enough for a productive coding day. On paid plans, scans run automatically on every git push.

Rule 2: Never Ship Without Reviewing the Diff

Before you commit, look at the actual changes. Not just the files the AI said it changed - the full diff.

AI tools sometimes modify files you did not ask them to touch. They refactor imports, add utility functions, change configuration files, or restructure code in ways that look helpful but introduce subtle bugs. The diff is your last line of defense.

Run git diff before every commit. If the diff is too large to read (more than a few hundred lines), that is a signal to break your prompts into smaller steps next time.

Rule 3: Check for Hallucinated Imports

AI coding tools sometimes import npm packages that do not exist. The AI invents a plausible-sounding package name based on its training data, adds an import statement, and your code references a library that was never published.

This is more than a build failure. If an attacker registers the hallucinated package name on npm, your next npm install downloads and executes their malicious code. This is a real supply chain attack vector called dependency confusion.

After every session, check your new imports against the npm registry. Or let VibeDoctor's hallucinated import detection do it automatically - it cross-references every import in your codebase against the actual npm registry.

Rule 4: Pin Your Dependencies

AI-generated package.json files often use loose version ranges like ^, ~, or even *. This means your next install might pull a completely different version than the one the AI tested against.

Pin your dependencies to exact versions. Use a lockfile (package-lock.json, yarn.lock, or pnpm-lock.yaml) and commit it to your repository. Never use * or latest as a version specifier.

Run npm audit regularly to check for known vulnerabilities in your pinned versions. When a patch is available, update deliberately - do not let it happen automatically through loose ranges.

Rule 5: Add Authentication to Every API Route

AI coding tools generate API routes without authentication more often than any other security gap. The AI focuses on making the endpoint work - it handles the request, queries the database, and returns the response. It does not add middleware to verify who is making the request.

Every API route that reads or writes user data needs authentication. Every route that performs a mutation (create, update, delete) needs authentication. The only routes that should be public are health checks, login endpoints, and genuinely public content.

Check your route definitions. If you see app.get('/api/users', handler) without auth middleware between the path and the handler, that endpoint is accessible to anyone on the internet.

Rule 6: Validate All Inputs

AI-generated API routes trust whatever the client sends. The AI reads req.body.email and uses it directly without checking if it is actually an email, if it is the right length, or if it contains malicious content.

Add schema validation to every endpoint that accepts input. Libraries like Zod (TypeScript), Joi (JavaScript), or Pydantic (Python) let you define what valid input looks like and reject everything else. This prevents injection attacks, type errors, and unexpected data from reaching your business logic.

Rule 7: Remove Hardcoded Secrets

AI tools hardcode API keys, database passwords, and secret tokens directly in source code. Sometimes it is obvious (const API_KEY = "sk-..."). Sometimes it is hidden in configuration files, environment variable defaults, or test fixtures.

Search your codebase for strings that look like credentials: anything starting with sk-, pk_, ghp_, or containing password, secret, token, or key followed by a string value. Move every secret to environment variables and add .env to your .gitignore.

If a secret has already been committed to git history, rotating it is the only safe option. Removing it from the current code does not remove it from the git log.

Rule 8: Add Error Handling

AI-generated code has a consistent pattern: the happy path works, the error path does not exist. Database queries run without try/catch. API calls use .then() without .catch(). File operations assume the file always exists.

Every async operation needs error handling. Every database query needs a try/catch. Every external API call needs a timeout and a fallback. The goal is not to prevent errors - it is to prevent silent failures that leave your users staring at a blank screen with no explanation.

Pay special attention to operations that affect money or user data. A failed payment webhook handler that silently swallows errors can charge a user without delivering the product.

Rule 9: Write At Least One Real Test

Most AI-generated projects have zero tests. When they do have tests, the test files are often empty shells - it('should work', () => {}) with no actual assertions.

You do not need 100% coverage. You need at least one real test that exercises your most critical path. If your app processes payments, write a test for the payment flow. If it authenticates users, write a test for the auth flow. If it stores data, write a test that verifies data is stored and retrieved correctly.

One real test with assertions is infinitely more valuable than a test suite full of empty bodies.

Rule 10: Check Your Live URL

Your code might be clean, but your deployed app is what users experience. Run a performance check against your live URL before sharing it publicly.

Check for:

• Performance score - if your Lighthouse score is below 50, your app is noticeably slow
• SSL certificate - make sure HTTPS is working and the certificate is not expired
• Security headers - missing headers like HSTS, CSP, and X-Frame-Options leave your app exposed
• Console errors - JavaScript errors on the live site that do not show up in development
• Broken links - 404s from incorrect routes or missing assets

VibeDoctor scans both your codebase and your live URL in a single pass, covering all of these in one report.

Rule 11: Set Up Monitoring Before Launch

If your app goes down at 3 AM, you want to know before your users do. Set up basic monitoring before you share your app with anyone.

At minimum, you need:

• Uptime monitoring - a service that pings your URL every few minutes and alerts you when it goes down
• SSL expiry alerts - so your certificate does not expire without warning
• Error tracking - a way to see runtime errors from real users (Sentry, LogRocket, or even a simple error logging endpoint)

This is not something you add later. By the time you realize you need monitoring, you have already missed the downtime you needed it for.

Rule 12: Run a Full Diagnostic Before Going Public

Before you post on Product Hunt, share on social media, or send the link to your first users, run one final comprehensive diagnostic.

This is your pre-launch checkpoint. It catches everything that slipped through during development - the secret you forgot to rotate, the API route you forgot to protect, the dependency with a known CVE, the missing meta tags that make your app invisible to search engines.

A full VibeDoctor scan covers 129+ checks across security, code quality, dependencies, performance, SEO, SSL, and AI-specific patterns. Fix the critical and high findings. Address the medium ones when you can. Ship with confidence that you have checked what matters.

The Rules in Practice

These 12 rules do not change how you vibe code. You still use Cursor, Bolt, Lovable, or whatever tool works for you. You still move fast. You still ship in hours instead of months.

What changes is the 10 minutes between "it works" and "it is live." That is when you scan, review the diff, check for the patterns that AI tools consistently miss, and fix the critical issues before your users find them.

The developers who adopt these practices ship just as fast but sleep better. Their apps do not get hacked two weeks after launch. Their APIs do not leak user data. Their dependencies do not contain known vulnerabilities with patches available.

Vibe coding is a superpower. These rules make sure you do not accidentally hurt yourself with it.

FAQ