What Is Vibe Coding? What It Means for Building an App

Last updated: August 2026.

Andrej Karpathy coined "vibe coding" in a post on X on February 2, 2025, describing a workflow where you describe what you want in plain language, accept the AI's output without reading every diff, and, in his words, largely forget the code exists underneath. The post reached over 4.5 million views, Collins Dictionary named it the 2025 Word of the Year, and search interest for the term reportedly jumped more than 6,700 percent that spring. What most people mean by "vibe coding" today has drifted a fair distance from what Karpathy originally described.

Where the term came from

Karpathy's original framing was specific: working in Cursor with Claude Sonnet, using voice input to minimize typing, accepting AI-generated changes without inspecting them, and pasting error messages back without comment. He was explicit that this was for throwaway weekend projects and demos, not production software, at a point where model capability was good enough to make that fun but not yet reliable enough to trust with anything serious. The term spread because it named something a lot of developers were already doing, even outside the narrow, prototype-only context Karpathy meant it for.

The definition already split in two directions

One reading stays close to Karpathy's original sense: never reading the generated code, accepting everything, reserved for low-stakes experimentation. The other, more common usage today, is looser, any workflow where you describe intent in natural language and an AI generates the code, including professional, production-facing work with real review and oversight attached. Karpathy himself has since moved past his own term: in February 2026, a year after the original post, he described vibe coding as already outdated, introducing "agentic engineering" for the more scrutinized, professional version of AI-assisted development that emerged as models got noticeably more capable over that year.

The ambiguity that matters if you're building an app

"I vibe coded an app" doesn't tell you what got built. Lovable, Bolt.new, and v0 all let you vibe code your way to a working web app, real code, a real working product, but not something you can submit to the App Store. Huxly, Rork, and FlutterFlow let you vibe code your way to a real native mobile app instead, Expo, Flutter, or Swift, compiled and signed the same way an app built by hand would be. Both are legitimately "vibe coding" by the term's current, looser usage. Only one of them ends with something installable from the App Store or Google Play. For the fuller breakdown of which tools land in which category, see our best AI app builders for mobile apps in 2026 roundup.

Karpathy's own caution still applies past the weekend-project stage

Skipping code review works fine for a throwaway prototype, which is exactly the context Karpathy built the term around. It's a real risk once an app handles actual user data, payment information, or production traffic, the exact point where security and correctness stop being optional. That's not an argument against vibe coding an app, most of this blog exists because building that way works now, it's an argument for knowing when you've moved past the context the term was originally scoped for. For a starting point on getting from a first prompt to something you can actually ship, see how to build a mobile app without knowing how to code.

FAQ