---
term: 'Vibe Coding'
seoTitle: 'Vibe Coding: Definition, Origin, Risks, Guardrails'
headline: 'What is Vibe Coding?'
slug: vibe-coding
category: ai-modern-stack
shortDefinition: 'Vibe coding is a workflow where you build software by prompting an AI and accepting its generated code largely without review.'
relatedTerms:
  - no-ops-development
  - backend-boilerplate-code
  - api-key-security
  - access-control-lists-acl
contrastsWith:
  - ai-agent
aboutTerms:
  - 'AI-Assisted Development'
  - 'Prompt-to-App Builders'
  - 'Agentic Coding'
faq:
  - question: 'What is vibe coding?'
    answer: 'Building software by describing what you want to an AI in natural language and accepting the generated code largely without line-by-line review — iterating by running, testing, and re-prompting rather than editing. The not-reviewing part is the defining trait, per the term''s strictest readings.'
  - question: 'Who coined the term vibe coding?'
    answer: 'Andrej Karpathy, in an X post in February 2025 — "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Collins made it Word of the Year for 2025, and dictionaries tracked it as slang within weeks of the coinage.'
  - question: 'Is vibe coding the same as AI-assisted development?'
    answer: 'No, and the distinction matters. In vibe coding you don''t review or fully understand the output. In AI-assisted engineering the human keeps architectural control and reviews everything — Simon Willison''s rule: if you reviewed, tested, and could explain every line, that isn''t vibe coding; that''s software development.'
  - question: 'Is vibe coding real programming?'
    answer: 'It produces real, working software — and it is not engineering. What''s missing is accountability: review, understanding, and the ability to reason about failure. For throwaway scopes that''s fine, which was Karpathy''s own framing; for anything with users and data, the missing parts are the load-bearing ones.'
  - question: 'Can non-programmers vibe code?'
    answer: 'Yes — a majority of users on prompt-to-app platforms have no programming background, and they genuinely ship working tools. The walls they hit are predictable: authentication, data modeling, security, and debugging — precisely the parts where not understanding the code is most expensive.'
  - question: 'Is vibe-coded software safe for production?'
    answer: 'Not without review. Industry scans put security flaws in roughly 45% of AI-generated code, and the incident record is concrete: apps shipped with database access rules disabled, broken authentication letting any user read others'' data, and secrets embedded in client code. The pattern in every case was backend security accepted unreviewed.'
  - question: 'What tools are used for vibe coding?'
    answer: 'Two families: agentic coding IDEs and CLIs aimed at developers — Cursor was named in the original coinage — and prompt-to-app builders aimed at non-developers, which generate and host the whole application. The families differ mainly in how much of the result you''re expected to look at.'
  - question: 'Will vibe coding replace developers?'
    answer: 'The consensus is no — it moves the work rather than removing it: toward specification, review, and architecture. Vibe-coded prototypes that succeed typically get rebuilt or heavily hardened by engineers before scaling, and the coiner himself now distinguishes casual vibe coding from serious "agentic engineering."'
  - question: 'Where does vibe coding shine?'
    answer: 'Exactly where its coiner put it: throwaway weekend projects — plus prototypes, MVPs, hackathons, internal tools, and learning. Anywhere iteration speed matters more than correctness, and where the blast radius of unreviewed code is deliberately small.'
  - question: 'What are vibe coding best practices?'
    answer: 'Small, scoped prompts; one task at a time; version-control checkpoints before "accept all"; tests as the safety net; human review of anything touching auth, data, or money; secrets kept out of prompts and client code; and a hardened, managed backend under the generated frontend.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Andrej Karpathy — the original post (February 2025)'
    url: 'https://x.com/karpathy/status/1886192184808149383'
  - name: 'Not all AI-assisted programming is vibe coding — Simon Willison'
    url: 'https://simonwillison.net/2025/Mar/19/vibe-coding/'
  - name: 'Vibe coding — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Vibe_coding'
  - name: 'The (In)Security of Vibe-Coded Applications — arXiv'
    url: 'https://arxiv.org/abs/2506.23130'
cta:
  title: 'Vibe the frontend. Not the backend.'
  text: 'Point your AI-generated app at Back4app and the load-bearing parts arrive hardened: auth, ACLs, rate limits, and server-side logic the generated code cannot disable — so the vibe-coded surface stays low-stakes.'
  linkText: 'Start building free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-30'
translationKey: vibe-coding
---

**Vibe coding is a workflow where you build software by prompting an AI and accepting its generated code largely without review.** [Andrej Karpathy coined it](https://x.com/karpathy/status/1886192184808149383) in February 2025 — "fully give in to the vibes, embrace exponentials, and forget that the code even exists" — describing accepting all changes without reading diffs and pasting errors back in until things worked, for what he himself scoped as "throwaway weekend projects." Within a year the term drifted into shorthand for *any* AI coding; this entry keeps the precise meaning, because the precision is where the engineering judgment lives: **the defining trait is not using AI — it's not reviewing what the AI wrote.**

## Key takeaways

| Question | Answer |
| --- | --- |
| The definition | Prompt → generate → run → re-prompt — without reading the code |
| The origin | Karpathy, Feb 2025 · Collins Word of the Year 2025 |
| The line | Reviewed, tested, understood = AI-assisted engineering, not vibe coding |
| The record | ~45% of AI-generated code carries security flaws; real breaches followed |
| The rule | Vibe the low-stakes surface; never the auth, data, or money paths |

## The loop, and the definitional line

The workflow is a tight loop: describe → the AI generates → run it → paste errors or new wishes back → repeat, treating the codebase as the AI's problem. [Simon Willison](https://simonwillison.net/2025/Mar/19/vibe-coding/) drew the line that keeps the term useful: if you reviewed every change, tested it, and could explain it to someone else, "that's not vibe coding — that's software development." The distinction isn't gatekeeping; it's a risk label. The same loop *with* review is AI-assisted engineering — the AI as a fast, unsupervised-never junior — and which mode you're in should be a decision, not an accident. What that decision looks like in practice:

**JavaScript:**

```javascript
// JavaScript — Cloud Code (cloud/main.js)
// The guardrail under a vibe-coded frontend: rules the AI can't skip
Parse.Cloud.beforeSave('Note', (req) => {
  // Whatever the generated client sends, ownership is enforced HERE
  if (!req.user) throw 'Sign in required';
  const acl = new Parse.ACL(req.user); // private by default
  req.object.setACL(acl);
});
// Client keys are publishable; the Master Key stays server-side.
// The vibe-coded UI can be rewritten nightly — these rules survive.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The vibe-coded client can be sloppy — the backend isn't
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The vibe-coded client can be sloppy — the backend isn't
var note = Note()
note.text = draft
_ = try await note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The vibe-coded client can be sloppy — the backend isn't
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Whatever the generated UI does, the platform enforced:
//   session auth → beforeSave validation → owner-only ACL → rate limits
// The AI wrote this screen in minutes; it could NOT disable the rules.
```

## Vibe coding vs. AI-assisted engineering vs. traditional development

| | Vibe coding | AI-assisted engineering | Traditional |
| --- | --- | --- | --- |
| Who writes code | The AI | The AI + the human | The human |
| Review | Skipped — that's the definition | Every change | Every change |
| Human owns | The prompt and the vibe | Architecture, correctness | Everything |
| Speed | Fastest | Fast | Baseline |
| Fit | Throwaways, prototypes | Real products | Real products |
| Failure mode | Shipped code nobody understands | AI-scale mistakes, human-caught | Human-scale mistakes |

## The spectrum, and the graduation rule

```mermaid
flowchart LR
  accTitle: The vibe coding to production spectrum
  accDescr: Software moves along a spectrum from vibe-coded throwaway prototypes through reviewed AI-assisted development to production engineering. Code graduates from one stage to the next only through human review and tests, and the failure mode is skipping the graduation by shipping a prototype directly to users.
  V["Vibe-coded prototype<br/>unreviewed, fast, disposable"] -->|"graduation: review<br/>+ tests + hardening"| A["AI-assisted development<br/>human owns correctness"]
  A -->|"same gate, higher bar"| P["Production engineering<br/>accountability + operations"]
  V -.->|"the failure mode:<br/>ship it as-is to users"| X["Incident"]
```

The framing that resolves most vibe-coding arguments: it's a *stage*, not an identity. Prototypes deserve the vibes — that's the point of prototypes. The rule the incident record teaches: **code graduates between stages only via review and tests.** Notably, Karpathy himself moved on within the year, distinguishing casual vibe coding from "agentic engineering" for serious work — the coiner agreeing with his critics about scope.

## What actually breaks: the incident record

The honest section vendor explainers soften. Industry scans put OWASP-class flaws in roughly **45% of AI-generated code**, and independent review tooling measured AI code carrying ~1.7× more major issues than human-written baselines ([the academic treatment](https://arxiv.org/abs/2506.23130) reaches similar conclusions). The named incidents share one anatomy: in 2025, a scan of apps built on a popular prompt-to-app builder found **170 of 1,645 leaking user data** — the generated stack shipped with the database's row-level security disabled (logged as a CVE); a prompt-to-app platform's own auth layer allowed **any user into any private app** via a guessable ID; and a viral consumer app was breached when its **unsecured mobile-backend database** let any authenticated user pull other users' IDs and private messages. None of these were exotic attacks. All were backend basics — access rules, authentication, credentials — generated permissive and accepted unreviewed.

## The backend is where it bites

Read the incident list again and the pattern names itself: the danger isn't that AI writes a clumsy UI — a broken button is a refresh. The danger concentrates where the *data* lives: [authentication](/glossary/authentication-vs-authorization/), [access rules](/glossary/access-control-lists-acl/), [API keys](/glossary/api-key-security/) pasted into client code, absent [rate limits](/glossary/api-rate-limiting-throttling/). Unreviewed code is most dangerous exactly where review matters most — and that's the architectural answer: **make the vibe-coded part the low-stakes part.** A generated frontend over a managed backend inverts the risk: the platform supplies hardened auth, deny-by-default ACLs enforced server-side, publishable client keys with the real secrets held elsewhere, and [server-side functions](/glossary/cloud-code-serverless-functions/) for the logic that must not live in generated client code. The AI can rewrite the UI nightly; it cannot disable rules it doesn't control.

## The guardrails checklist

1. **Review anything touching auth, data, or money** — the graduation gate, non-negotiable.
2. **Checkpoint in version control before "accept all"** — cheap undo for expensive suggestions.
3. **Keep secrets out of prompts and client code** — treat both as public.
4. **Deny-by-default access rules** — the generated app gets the permissions you chose, not the permissive ones it suggested.
5. **Server-side validation for every invariant** — [hooks the client can't skip](/glossary/database-triggers-beforesave-aftersave/).
6. **Tests before trust** — the loop's only honest feedback beyond "it seems to run."
7. **Small scopes, one task per prompt** — review-sized diffs stay reviewable.
8. **Cap spend** — API keys with quotas; agent loops have burned real budgets.
9. **Sandbox experiments** — separate app, separate keys, disposable data.
10. **Know which mode you're in** — vibing or engineering, chosen on purpose.

## Common use cases

- **Prototypes and MVPs** — the founding use case: test the idea this weekend, not this quarter.
- **Personal and internal tools** — small audience, known users, low blast radius.
- **Hackathons and demos** — speed is the entire rubric.
- **Learning by building** — the loop as a tutor, with the caveat that unread code teaches less.
- **UI iteration over a stable backend** — the inverted-risk architecture: vibes above, [contracts](/glossary/api/) below.

## Should you vibe code it? A decision matrix

| The thing you're building | Verdict |
| --- | --- |
| Weekend throwaway, demo, experiment | Vibe freely — that's the habitat |
| Internal tool, real but small | Vibe, then review the data paths |
| Anything with user accounts | The backend comes from a hardened platform, not the prompt |
| Anything handling payments or PII | Full review — this is engineering now |
| A startup's actual product | AI-assisted with ownership; prototypes graduate, never ship as-is |
| The frontend over a managed backend | The sweet spot — speed where it's safe |

## Limitations and trade-offs

- **Debugging unread code is archaeology.** When the loop stalls, someone must finally read everything at once — the review you skipped, with interest.
- **Comprehension debt compounds.** Every accepted-unread change widens the gap between what the app does and what anyone can explain; the gap is the risk.
- **AI defaults are permissive.** Generated configs favor "it works" over "it's safe" — open access rules, embedded keys — and the user who most needs to notice is least equipped to.
- **The term is drifting.** "Vibe coding" increasingly means any AI coding, which launders prototype-grade practices into production conversations; precision about which mode you're in is the defense.
- **Skill atrophy is real but misframed.** The skill that matters shifts from writing code to specifying, reviewing, and judging it — atrophy happens only if review is skipped too.

## Vibe coding with Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The pairing is the inverted-risk architecture made practical: point the generated frontend at a backend where the load-bearing parts are already engineered — signup, sessions, and [social login](/glossary/oauth-2-social-login/) from the platform; [ACLs and class-level permissions](/glossary/access-control-lists-acl/) enforced server-side on every request, deny-by-default; publishable client keys with the [master key held server-side](/glossary/api-key-security/); and the code tabs' `beforeSave` guard as the pattern for every invariant the AI-written client must not be trusted with. The vibe-coded surface stays what Karpathy meant it to be — fast, fun, disposable — while the parts that end up in incident reports come from a platform, reviewed once, enforced always.