What is 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 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

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 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 — 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 — 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.

// 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.

// 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

The spectrum, and the graduation rule

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 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, access rules, API keys pasted into client code, absent rate limits. 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 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.
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 below.

Should you vibe code it? A decision matrix

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 from the platform; ACLs and class-level permissions enforced server-side on every request, deny-by-default; publishable client keys with the master key held server-side; 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.