Vibe coding is bad when the AI is the only one making decisions. It is perfectly good for prototypes, and it can be production-safe when a human engineer owns the specification, the tests, the security review and the merge button. This guide explains where vibe coding breaks, and the eight guardrails we run on production software at Atlas.
What vibe coding actually means
Vibe coding is building software by describing what you want to an AI coding agent and accepting what it writes, often without reading the code line by line. The term caught on in 2025 because it works astonishingly well for a first demo and astonishingly badly for the hundredth user.
The useful question for a business owner is not "is vibe coding good or bad?" It is "who is accountable for what the AI wrote?" If the answer is "nobody," you have a liability. If the answer is "an engineer with a process," you have a very fast development team.
Why did vibe coding fail?
When vibe coding fails, it is rarely because the AI wrote bad syntax. It fails because nobody defined what "done" means, nobody tested the edge cases, and nobody reviewed the change before it shipped.
The failure stories that circulate on Reddit and in the trade press share the same pattern:
- No specification. The AI fills gaps with plausible guesses. Plausible is not the same as what your accountant or your customer expects.
- No tests, or tests written after the code. An AI agent will happily write a test that confirms its own bug.
- Secrets and permissions handled casually. API keys in the code, database rules left open, admin routes without a check.
- Silent dependency sprawl. Packages added to solve a two-line problem, some of them unmaintained.
- A green light that is not really green. The pipeline reports success because a check was skipped or cancelled, not because it passed.
That last one is not hypothetical. On one of our own SaaS products, we found in September 2026 that a cancelled end-to-end test job was being read as "not failed" by the merge command. Over one week, 7 of 21 merged pull requests went to production without an end-to-end verdict. Nothing broke, but nothing guaranteed it wouldn't. We fixed the process, not just the symptom: a merge gate now re-reads every check at merge time and blocks anything that is not an explicit pass, including cancelled, timed-out or still-running jobs.
Can vibe coding be good?
Yes. Vibe coding is good for prototypes, internal tools with low stakes, and any project where an engineer wraps the AI's speed in a process that catches its mistakes.
The speed is real. AI coding agents write boilerplate, migrations, tests and UI faster than any human. What they do not do on their own is decide what matters, notice that a requirement is ambiguous, or refuse to ship something that "mostly works." Those are engineering decisions, and they stay with the engineer.
| Use case | Vibe coding alone | Vibe coding with guardrails |
|---|---|---|
| Clickable prototype to test an idea | Good fit | Overkill |
| Internal tool used by 3 people, no sensitive data | Acceptable with backups | Good fit |
| Customer-facing app with logins and payments | Risky | Good fit |
| Software that handles legal, financial or health data | Not acceptable | Good fit, with human review of every release |
| Replacing a legacy system the business runs on | Not acceptable | Good fit, with regression tests first |
The eight guardrails we run before AI-written code ships
This is the chain we run on our four SaaS products in production and on the client business application we are currently building. AI coding agents write most of the code; each step below is either done by a human or enforced by a machine the agent cannot override. Quick prototypes get a lighter version, and we say so up front.
- 1
Spec
Acceptance criteria approved first
- 2
Failing test
Seen red before the code
- 3
AI writes code
Under the engineer’s direction
- 4
Reviews
Code, then a blocking security pass
- 5
Green CI
Cancelled counts as red
- 6
Production check
Revert first if it breaks
- A written specification first. Acceptance criteria are agreed with the client before any code exists. On new products, an interactive mockup is validated first, so the AI builds the right thing.
- A failing test before the fix. Every bug fix starts with a test that reproduces it, and we watch it fail. Every new feature goes acceptance criteria → tests → code. The test checks the data in the database or the document produced, not a toast message on screen.
- A fresh test database on every run. Tests run against a database rebuilt from the branch's migrations, never against the database the app serves.
- Code review. A dedicated review pass looks for correctness bugs in the diff before a pull request is opened.
- A blocking security review. A separate pass checks for exposed secrets, injection, broken access control and open redirects. A security finding stops the pull request; it is not a suggestion.
- Simplification. A last pass removes duplication and dead code without changing behavior, so the next person (or the next AI) can read it.
- A fully green CI before merge. Lint, type checking, unit tests, a dependency audit, the production build and end-to-end browser tests. "Cancelled" counts as red. No auto-merge, no admin override.
- Production checked after merge, with an automatic way back. After each merge we check the deployed version and the key pages. If production breaks, the change is reverted through its own pull request and CI before anyone tries to fix forward.
This is the same chain described on How we work. The guardrails are what make AI speed safe to sell: without them, you are buying a demo.
Is vibe coding ethical?
Vibe coding is ethical when the people who rely on the software know how it was built and someone qualified is accountable for it. It becomes an ethical problem when AI-written code that nobody reviewed handles other people's money, data or safety.
For a small business, the practical version of that question is about disclosure and ownership. Ask any developer you hire three things: will you tell me which parts the AI wrote, will I own the code, and who fixes it if it breaks? At Atlas the answers are yes, yes, and us.
Do vibe coders get jobs?
People who can only prompt an AI rarely get hired as software engineers. Engineers who use AI agents with discipline are in high demand, because they ship several times more than they could alone.
For a buyer, the distinction matters more than the label. If you are hiring an AI developer, ask to see their test suite and their CI configuration, not just a demo.
Is vibe coding the future?
AI-written code is already the present: on our projects, AI coding agents write most of the lines. What is not going away is engineering judgment, which is why we expect the future to look like vibe coding with guardrails rather than vibe coding alone.
If you want the speed without the risk, an AI MVP built this way is the easiest place to start.
Talk it through
If you are weighing an AI-built project, or you inherited one and are not sure it is safe, book a 30-minute call. We will tell you honestly what it would take to put it under guardrails.