Vibe Coding in Production: A Risk-Tiered Framework for When It's Acceptable

Andrej Karpathy coined “vibe coding” in February 2025. By February 2026, he declared the term obsolete - absorbed into normal software development. That timeline tells you something: what started as a fringe experiment is now just how a lot of code gets written.

And a lot of that code is dangerous.

40-62% of AI-generated code contains vulnerabilities. 86% fails cross-site scripting tests. 88% is vulnerable to log injection. In March 2026, 35 CVEs were directly attributed to AI-generated code - up from 6 in January. GitGuardian found 28.65 million new hardcoded secrets in public GitHub repos in 2025, a 34% year-over-year increase, with AI-assisted commits exposing secrets at 3.2% versus 1.5% for human-only commits.

The Cloud Security Alliance published formal research titled “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” That’s not a blog post. That’s institutional acknowledgment.

But here’s what those numbers don’t tell you: vibe coding itself isn’t the problem. Shipping AI-generated code without appropriate gates is the problem. The two things are different, and conflating them leads to bad decisions in both directions - either blanket rejection of a genuinely useful tool, or reckless deployment of code that hasn’t been reviewed for a category of risk humans rarely introduce.

I’ve been building with Claude Code daily for over a year. Here’s the framework I actually use.

The Productivity Paradox (And Why It Matters)

Before getting into tiers, one number worth sitting with: organizations report only 10% improvement in overall delivery velocity despite dramatic individual productivity gains from AI tools. Individual developers feel faster. Shipping velocity barely moved.

The bottleneck was never code-writing. It was review, deployment, coordination, and trust. Adding AI-generated code to a slow review pipeline doesn’t help much. Adding AI-generated code without a review pipeline creates debt that eventually blocks everything.

The framework below isn’t just about security. It’s about matching the gate intensity to the actual risk so you don’t either over-invest in reviewing low-stakes code or under-invest in reviewing high-stakes code.

The Four Tiers

Tier 1 - Acceptable with No Gates

Throwaway prototypes. Personal scripts. Internal tooling with zero external users. One-off data migrations that run once and get deleted.

The defining characteristic: if this code misbehaves, the blast radius is you. No user data. No external attack surface. No production system that depends on it after the run.

For this category, vibe all you want. The point of AI coding tools is speed, and speed is all that matters here. I regularly use Claude Code to write bash scripts, one-off API clients, and data exploration notebooks without reviewing a single line. The economics are right: the cost of a security review exceeds the cost of any conceivable incident.

One caveat: “internal tooling with no external users” means exactly that. If the script writes to a shared database that production depends on, it’s not Tier 1. The blast radius matters, not just the audience.

Tier 2 - Acceptable with Review Gates

Internal tools with real users. Non-security-critical API endpoints. Frontend code with no auth flows.

This is the category most people get wrong in one direction or the other. The code has real users, so it matters. But it’s not customer-facing, not touching payment flows, not handling regulated data. The risk is real but bounded.

Gates needed here: human review of the diff, automated linting, basic test coverage. The human review doesn’t need to be a full security audit. It needs to be a developer who understands the system looking at the code and asking “does this make sense?”

Practically, this means treating AI-generated code the same as you’d treat code from a junior developer you trust but don’t rubber-stamp. Read it. Ask questions about the pieces that look odd. Merge it when it looks right.

Tier 3 - Acceptable with Strict Gates

Customer-facing features. Payment-adjacent flows. Anything that touches user data.

This is where the vulnerability statistics start to bite. AI models are genuinely bad at certain security patterns - input sanitization, output encoding, parameterized queries, proper secret handling. Not because they don’t know the concepts, but because they optimize for making code work rather than making code secure, and those two things diverge more often than developers expect. This is where AI governance and clear team practices become critical.

The gates here are non-negotiable:

Run Semgrep in CI with security rules enabled. It catches a large percentage of the injection, XSS, and secret patterns that AI models introduce. It’s fast enough to run on every commit and noisy enough to catch things a human review misses when tired.

Add Snyk or equivalent for dependency auditing. AI models reach for packages that are outdated, abandoned, or contain known CVEs. They don’t have a model of “this package stopped being maintained in 2022.”

Add a secrets scanner on every commit. I use trufflehog, wired into Claude Code hooks so commits fail before they land if secrets are detected. The config is simple:

# .claude/hooks/pre-commit
trufflehog filesystem . --only-verified --fail

This isn’t optional. AI models will hardcode credentials when they’re trying to make something work quickly, especially in test files and scripts. The GitGuardian data makes this concrete: 3.2% secret exposure rate for AI-assisted commits. At any real commit volume, that’s a lot of credentials.

For auth flows and input handling specifically: always require explicit human review. Not just “looks fine in the diff” review. Actually read the validation logic, trace the data flow from input to output, and confirm that every user-supplied value is treated as untrusted. AI models will frequently validate the format of input without validating the semantics, and that gap is where most injection vulnerabilities live.

Tier 4 - Not Acceptable Without Complete Rewrite

Auth systems. Cryptographic implementations. Anything processing regulated data (HIPAA, PCI-DSS). Systems with direct database access from user input.

The CVE attribution data is instructive here. In March 2026, 27 CVEs were attributed to Claude Code, 4 to GitHub Copilot, 2 to Devin, 1 to Cursor. Claude Code’s dominance isn’t because it’s worse - it’s because it’s more widely used and more capable of generating complex systems end-to-end. Capability and risk scale together.

In Tier 4 territory, AI-generated code can be a starting point for understanding the problem or generating a skeleton. It cannot be the implementation. Authentication middleware needs to be written, reviewed, and signed off by a developer who understands the specific security model - not because AI can’t write auth code, but because auth code that’s 95% right is worse than no auth code. The 5% is where sessions get hijacked.

For cryptographic code: never use AI-generated implementations of crypto primitives. Use battle-tested libraries and let AI help you use them correctly. Generating a custom HMAC implementation or rolling your own JWT validation is how you get a CVE with your name on it.

For regulated data: the compliance requirement itself mandates human review and audit trail. Vibe coding’s entire model - move fast, iterate, accept imperfection - is structurally incompatible with HIPAA and PCI-DSS requirements. This isn’t a philosophical objection; it’s a compliance one.

The Practical Hooks

Beyond the tier framework, a few specific practices worth implementing regardless of tier:

Shell scripts and environment variables: Always use unset VARIABLE_NAME rather than VARIABLE= (empty string assignment). AI models frequently use empty string to “clear” environment variables, which doesn’t actually remove them from the environment. One line in your AI coding context file fixes this pattern.

Commit hooks for secrets: Wire trufflehog into your pre-commit hook or Claude Code’s hooks configuration. Catching secrets before they land in git history is orders of magnitude cheaper than rotating credentials after an exposure.

Semgrep in CI: The free ruleset catches a meaningful fraction of the vulnerability patterns that appear repeatedly in AI-generated code. Run it on every pull request, not just scheduled scans.

Explicitly exclude AI from auth middleware: In your Claude Code project instructions, call out authentication and authorization code explicitly. Something like “Do not modify auth middleware or JWT handling without my explicit direction” changes the behavior reliably. This matters even more as you’re hiring AI-native engineers who will be working within these constraints.

The Honest Assessment

I ship AI-generated code daily. Some of it goes to production. The framework above isn’t theoretical - it’s what I actually apply.

The mistake I see most often is treating all AI-generated code as equivalent. A throwaway migration script and a customer authentication handler are not the same risk profile. Applying full security review to the migration script wastes time. Skipping security review on the auth handler creates liability.

The second mistake is treating the review gate as bureaucratic overhead. It isn’t. It’s the mechanism that makes the productivity gain real rather than borrowed. Code that creates incidents, exposures, or compliance findings consumes time at a rate that erases the productivity benefit many times over.

Vibe coding works. It also produces vulnerable code at a measurable rate. Those two facts coexist fine once you accept that the tool is powerful enough to require judgment about where to apply it.

Tier the work. Apply the gates. Ship fast where fast is safe.