Can You Use Vibe Coding in Production? Yes, If You Stop Calling Every Commit the Same Kind of Risk

The first thing an AI coding agent gets right is usually visible.

You ask for a settings page and there it is. Fields, empty states, validation messages, maybe even the little animation you would have skipped. The feature runs. It looks close enough. You get the particular kind of optimism that makes the word “production-ready” feel like an objective observation instead of a bet.

Then you read the diff.

The agent invented a permission check, accepted input you never meant to accept, duplicated an existing component, and added a database query inside a loop. The UI still looks good. That is the problem with judging generated code only by whether it renders.

Vibe coding is useful in production. It is also a terrible name for the approach you want in production, because the useful practice is not vibes. It is delegation with clear boundaries and review proportional to the damage a mistake can cause.

What is vibe coding?

The term generally means describing an outcome to an AI in natural language, accepting a substantial amount of generated code, and judging the result mainly by whether it works when run.

That workflow is powerful for a prototype. It becomes risky when the running result can charge a card, expose private data, delete records, or make decisions that are hard to reverse.

A recent research review describes vibe coding as a real emerging practice with both productivity evidence and a growing body of risk research. Separate work on vibe-coded applications found recurring patterns such as placeholder logic, unfiltered input, secret exposure, and agents losing context across the development lifecycle.

That is not an argument to stop using AI. It is an argument to separate low-consequence code from high-consequence code before you hand either to an agent.

Can you use AI-generated code in production?

Yes. The standard is not who typed the code. The standard is whether you understand, test, and can safely operate the change.

I would happily use an agent to draft a presentational component, map a repetitive data shape, create test cases, explain an unfamiliar error, or turn a clear acceptance criterion into a first pass. Those are tasks where a human review can see most of the risk and the rollback is obvious.

I would not give the same agent unreviewed authority over authentication, permissions, payment fulfillment, production database writes, secret handling, rate limiting, or a third-party integration that can act on a customer's behalf.

The distinction is not “frontend good, backend bad.” A frontend page can leak private data. A backend script can be low-risk. The distinction is blast radius.

Which vibe coding tasks are safe for production?

Safe is too strong a word. Lower-risk is better.

| Task | Why it is lower-risk | Minimum human check | | --- | --- | --- | | Static marketing UI | Failure is usually visual and reversible | Check responsive layouts, accessibility, and source content | | Test scaffolding | Tests can be reviewed against user behavior | Confirm the test would fail for a real regression | | Repetitive refactors | The desired transformation is explicit | Inspect the diff and run type checks and tests | | Internal admin tooling with limited data | Scope can be narrowed and access controlled | Confirm permissions and use non-production data first | | Documentation and code explanations | Output does not directly change production behavior | Verify claims against the code or official docs | | Drafting integrations in a sandbox | A provider test environment limits damage | Exercise failure paths before live credentials exist |

These are good fits because the prompt can describe the boundary. “Build this card from these fields” gives an agent a bounded problem. “Make billing work” does not.

The best prompt is not the cleverest prompt. It contains the constraints a careful engineer would ask for: existing files to reuse, data that must not leave the boundary, tests that define success, and actions that require confirmation.

Which AI coding tasks should never be unreviewed?

Anything that changes a customer's security, money, data, or access.

That includes:

• Authentication and authorization.
• Payment webhooks, refunds, entitlements, and pricing.
• Destructive database migrations and bulk updates.
• File uploads and URL fetching.
• Secrets, API keys, and deployment configuration.
• Input validation at a public boundary.
• Rate limits and abuse prevention.
• Compliance-sensitive workflows.

The reason is not that agents always make these mistakes. It is that an occasional mistake has an asymmetric cost. A missing loading state is embarrassing. A missing authorization condition is an incident.

The Cloud Security Alliance's 2026 research note puts the concern in practical terms: AI-assisted development can reproduce secrets and security flaws at the speed it produces code. More output means more review surface, not a smaller need for review.

How do you review AI-generated code?

Start with the diff, not the rendered page.

Ask four questions:

1. What changed besides what I asked for? Extra abstractions and unexpected dependencies are a sign the agent was optimizing for a local pattern, not your system.
2. What data crosses a boundary? Inspect user input, database calls, remote requests, credentials, and logs.
3. What happens when the happy path fails? Expired sessions, duplicate events, slow APIs, empty data, partial writes, and rejected payment all deserve an answer.
4. How do we undo this? A feature flag, a migration plan, a backup, or a clear rollback makes experimentation responsible.

Then run the ordinary checks. Type checking. Linting. Behavior tests. A manual flow using an account with the wrong permissions. A test payment. A non-production environment. AI did not make these steps obsolete. It made them faster to skip.

This is one reason I prefer a clear TypeScript and Postgres stack for a small product. Strong types, migrations, and a predictable deployment path give you a way to question the agent's output. The stack is not the product, but it can make a risky diff legible.

Does vibe coding replace software engineering?

It replaces some typing. It does not replace the work that makes code part of a product.

Software engineering includes deciding what should happen when two systems disagree, keeping a schema compatible with yesterday's data, understanding a customer's permissions, and knowing when an error is recoverable. An agent can offer suggestions inside those decisions. It does not acquire the operational context merely because it has read the repository.

The context problem gets worse in a large or old codebase. The agent sees files. It does not see the conversation where a weird-looking condition was added after a customer lost access, unless that history is written down and surfaced. It does not see your production metrics or know which integration has a contractual edge case. That is why code can be technically clean and still wrong for the system.

This is also why model selection is not the whole story. A more capable agent can finish a coding task with fewer tokens and fewer interventions. It can still make a confident, context-blind mistake. I went through the cost and benchmark math in my GPT-6 Astra analysis. Better coding output is real. So is the human responsibility at the boundary.

A practical production workflow for AI coding

Use this sequence:

1. Describe the user outcome and the non-negotiable constraints.
2. Ask the agent for a plan and affected files before asking it to edit.
3. Keep the change small enough to review in one sitting.
4. Inspect the diff line by line, especially data access and error paths.
5. Run automated checks and test the critical path as the wrong kind of user.
6. Deploy behind a reversible boundary when the blast radius is meaningful.
7. Watch errors and customer behavior after release.

The agent can help at every stage. It can summarize the existing flow, draft tests, write a migration, and explain an error. The accountable person still needs to be able to say why the change is safe enough to ship.

That is not anti-AI. It is the condition that lets you use AI without becoming the person who shipped a beautiful feature and spent the next day figuring out whose data it exposed.

Use vibe coding to make prototypes and low-risk changes faster. Use engineering judgment to decide when a prompt has become a production decision. The code will be better for the distinction, and so will your sleep.