Safer Vibe Coding: Six Habits That Actually Work

Six practical habits for developers using AI coding assistants to avoid common security mistakes without slowing down development velocity.

You Can Vibe Code Without Shipping Vulnerabilities

A post on Hacker News this week asked whether you could make vibe coding slightly safer by adopting old hacker habits. The answer is yes, and the habits are not glamorous. They are the same disciplines that security engineers have been recommending for twenty years, applied to the specific failure modes that LLMs introduce.

None of these habits require you to stop using Copilot, Cursor, or ChatGPT. They add friction at the right moments without grinding your workflow to a halt.

Habit 1: Review the Diff, Not the Conversation

When an AI assistant generates a change, it is tempting to read the explanation in the chat window and accept the code. Do not do this. Read the actual diff in your editor.

AI explanations describe intent. The diff shows what actually changed. These are frequently not the same thing. A refactor that "cleans up the auth middleware" might also quietly remove a permission check three files away from the one you were looking at.

Habit 2: Grep Every New Dependency

When an AI assistant adds a require() or import, it will often pull in a package you have not vetted:


# After any AI-generated code addition, run:
git diff --name-only | xargs grep -h 'require\|import' | sort -u

# Then cross-check new packages against your known-good list:
npm ls --depth=0  # Node
pip list         # Python

Before April 2024, the package node-fetch-plus on npm had the same name as a common AI hallucination. Anyone who installed it got a credential harvester. This class of attack is specifically effective against vibe-coded projects because the developer never explicitly chose the dependency.

Habit 3: Prompt for the Attack Surface First

Before asking an AI to implement a feature, ask it to describe the security implications of the approach:

> "Before you write the code: what are the three most likely ways this implementation could be abused by a malicious user or a compromised dependency?"

This is not magic. The model will sometimes miss things. But it forces the security context into the conversation before the code is written, rather than after, when the instinct is to ship rather than revisit.

Habit 4: Set a No-Inline-SQL Rule in Your System Prompt

SQL injection is almost never introduced intentionally. It appears because an AI assistant constructs a query using string interpolation because that is what the surrounding code pattern suggested:


# AI-generated: classic injection vector
query = f"SELECT * FROM users WHERE email = '{email}'"

# What you want:
query = "SELECT * FROM users WHERE email = %s"
cursor.execute(query, (email,))

Add a rule to your system prompt or .cursorrules file: "Never construct SQL queries using string formatting or f-strings. Always use parameterized queries."

Habit 5: Run a Security Scan Before Every Commit

This is the habit most developers skip because it feels like it belongs to a different workflow. It does not need to be slow:


# Python: ~3 seconds on a medium-sized project
pip install bandit --break-system-packages -q
bandit -r . -ll -q

# JavaScript: ~5 seconds
npx audit-ci --moderate

Integrate this into your pre-commit hook so it is automatic. The goal is not a zero-finding baseline. The goal is catching regressions introduced by the most recent AI-generated change.

Habit 6: Never Let AI Touch Your Auth Logic Unsupervised

AI assistants are weakest on authentication and session management because the correct behavior is highly context-dependent. A stateless JWT pattern that is correct in one architecture is a vulnerability in another.

Set a personal policy: any change to auth, session handling, or permission checks gets a full manual review, regardless of whether you generated it yourself or asked an AI to do it.

Key Takeaways

Reading the diff rather than the AI's explanation catches the most serious silent regressions, especially in files the AI touched as side effects of the requested change
Prompting for attack surface before writing code shifts security thinking to the design phase, where it is far cheaper to fix
A pre-commit security scan costing a few seconds per commit prevents the class of vulnerabilities most commonly introduced by AI code generation