What Is Vibe Coding (Now)?

Vibe Coding: Where the vibes are immaculate, and the code is… only half the story.

The other day I was talking to a business executive about AI, as one does in 2026. Vibe coding came up, as it does in 2026. He nodded very confidently, the way people do when they recognize a phrase from a deck they’ve seen more than once.

Then it became obvious he thought vibe coding meant “developers using Copilot instead of typing everything by hand.”

Which is fair. That was the vibe, briefly. It just hasn’t been the whole story for a while. Vibe coding isn’t “developers type less.” It’s “more people build software they don’t fully understand.”

I’ve vibe coded. I’ve put the results into the world. Every single one carries some amount of technical debt, like a little IOU tucked into the codebase—some charming, some less so. So this isn’t an abstract explainer; it’s a field note from someone who has stared at a working app she built in an afternoon and thought, “I really hope nobody ever looks at the inside of this. Or asks about the authentication. Or checks what happens if two people submit the same form at the same time.”

The Thing People Think It Is

In most boardrooms, conference rooms, and Zoom rooms, “vibe coding” currently means some soft version of: engineers get autocomplete on steroids, they ship faster, we save money, and also “democratization” (said with a straight face).

In that mental model, the important thing hasn’t really changed. There are still Developers (capital D) and everyone else. The AI is just a power tool. You wouldn’t rebuild your org chart over a nail gun. This is where a lot of non-technical leadership still is on the topic.

A Brief Origin Story

The term comes from Andrej Karpathy—founding member of OpenAI, former AI director at Tesla, person who very much knows how to code the traditional way. In February 2025, he described a new way he’d been working: “fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

By March, Merriam-Webster had added it to their “slang & trending” list. By the end of the year, it was the Collins English Dictionary Word of the Year.

The velocity of adoption tells you something. This wasn’t a new tool. It was a name for something people were already doing.

What It Has Quietly Become

If you’ve actually vibe coded, you know the center of gravity has already moved.

These days, it looks something like this: you open a tool—Cursor, Claude, Replit, Bolt, whatever you like—and describe what you want in plain English. “Build me a small web app where sales reps can log calls and see a leaderboard.” The AI generates code, creates files, builds components and endpoints inside whatever framework you’ve pointed it at. You react to behavior, not implementation: “This button shouldn’t reload the page.” “This query is slow.” “Why does this form lose its data?” You iterate until it works “well enough,” and then you ship it and quietly hope Future You is feeling brave.

There’s a useful distinction here, via programmer Simon Willison: if you’ve reviewed and understood every line the AI wrote, that’s not vibe coding—that’s using an LLM as a typing assistant. Vibe coding means you’re accepting code you haven’t fully vetted because the result works.

The important shift: the person in the driver’s seat doesn’t have to be a traditional engineer anymore. They can be a founder, a PM, an ops lead, a marketer—whoever has the problem and the patience to talk to the model. But that doesn’t mean the Capital D Developer has left the story. They can vibe code the whole thing start to finish—and get further, faster, because they already know where the gaps are. Or they can come in after someone else has built the first version and make sure it actually holds up once real people, real money, and real data are involved. The developers aren’t gone. The surface area of software has expanded. Someone still owns the parts that don’t demo well.

And the results can be genuinely impressive. Vibe coding is fantastic for prototypes—you can go from “idea” to “clickable, slightly janky thing” in an afternoon. It’s great for glue work: transforming data, basic forms, internal dashboards, automating workflows nobody wants to do by hand. Y Combinator reported that 25% of startups in their Winter 2025 batch had codebases that were 95% AI-generated. Linus Torvalds—yes, that Linus Torvalds—vibe coded a Python visualization tool in January 2026.

A couple of things worth noting about what the tools don’t do, though. They don’t magically pick the right tech stack. Experienced coders typically choose the framework and let the AI operate within it. And when things get weird—routing conventions change, a migration goes sideways—you’re still the escalation path. Within the box you give them, they’ll generate a surprising amount of working scaffolding. It’s not “coding, but faster.” It’s building software by conversation, with a very opinionated autocomplete.

If you treat the outputs as disposable prototypes—proof-of-concept, internal utilities, things you’re willing to throw away—it’s genuinely delightful.

The problem is that we are terrible at throwing away things that kind of work.

The Part Where the Sharp Edges Live

From the outside, it looks like: “The AI builds the whole app!” From the inside, it feels more like: “The AI builds almost the whole app, and the remaining part is where all the sharp edges live.”

There’s a pattern to where vibe coding falls short, and it’s worth naming: it gets you surprisingly far, surprisingly fast, but not all the way there. The structural parts of software—the security, the integrations, the things that need to talk to each other reliably—don’t just assemble themselves because you asked nicely. And the connections the AI does wire up aren’t free—every one is a meter running. At some point, you’re the one bridging the remaining gaps and opening your wallet. The question is whether you knew that going in.

There’s a structural reason for this. These models are probability engines—they’re excellent at guessing what code looks like based on patterns they’ve seen, but much worse at managing rigid state, enforcing strict security protocols, or handling the unpredictable edge cases of external systems. The more a task depends on being exactly right rather than plausibly right, the more the AI needs a human backstop.

Authentication. Getting a login screen to appear is trivial. Getting login that’s actually secure is not. The AI will happily hand you something that works in a demo and skip the parts a security person would catch immediately. Wiz Research found vibe-coded apps with credentials and secrets hardcoded in client-side JavaScript—visible to anyone who right-clicks and hits “inspect.” That’s not a subtle vulnerability. That’s a front door with a sign that says “key is under the mat.”

Secrets. Real apps need API keys and credentials stored securely—not baked into the code. AI is extremely cheerful about hardcoding them into source files “just to get you unblocked.” One person documented losing $300 when an API key leaked from a vibe-coded project. This doesn’t announce itself as an error message. It shows up as a strange invoice.

API integrations. Models are great at calling clean, textbook APIs. Real vendor APIs have rate limits, pagination quirks, and cryptic error messages. You can vibe code 80% of the integration. The other 20% is exactly where non-technical people hit a wall.

Payments. Vibe-coded payment flows almost always handle the happy path—card goes through, everyone’s thrilled—and quietly ignore the “what happens when something goes wrong and a regulator reads this” path.

The Bill That Arrives Later

Then there’s the cost that doesn’t appear in the demo. Once you vibe code something into existence, you haven’t just created an app. You’ve created an ongoing relationship with several billing meters.

Every time your app calls a model, that’s a paid API request. Vibe-coded flows tend to be chatty—extra retries, verbose prompts, generous logging—because the goal during building is “make it work,” not “make it efficient.” Part of why the numbers add up so fast: every time you ask the AI to fix a bug, it’s re-reading the entire codebase and its own previous errors to figure out what went wrong. Every prompt is a massive payload, and debugging is where most of the prompts happen. One developer reported burning through 170 million tokens in two days. Another posted about unexpected charges north of $200 in a single billing cycle on a tool with a $20/month base plan. Cursor has since clarified that its subscription includes a set number of requests, after which users are billed per request at the underlying model’s API rate. The pricing is transparent—but if you’re vibe coding fast and loose, the meter runs faster than you think.

Then there are the third-party APIs, the databases, the cloud storage, the monitoring—most metered per request, all quietly accumulating. The default pattern AI tends to generate is log everything, keep everything, store everything. Excellent for debugging. Less excellent for your invoice six months in.

The models will quite happily wire you up to every API in sight. They will not be the ones staring at the credit card statement when your “little internal tool” turns out to be extremely enthusiastic about external services. I once built a “simple” internal dashboard that, left unattended for a month, quietly ran up a cloud bill that could have taken me to dinner somewhere with a wine list.

Technical Debt, but as a Lifestyle

Every vibe-coded thing I’ve built has technical debt. Some of it is charming. Some of it is… educational. None of this is unique to AI—humans have been creating messes for decades—but the shape of the mess is different.

Studies are starting to quantify it. One analysis of nearly 500 open-source pull requests found that AI co-authored code contained 1.7 times more major issues than human-written code—significantly more logic errors and more security vulnerabilities. Another study of 211 million lines of code changes found that refactoring and code movement dropped from roughly 25% of changes to under 10%, while copy-pasted code rose from about 8% to over 12%. The trend lines aren’t subtle.

With vibe coding specifically, the pattern is almost predictable: you hit “good enough” very quickly, which is the most dangerous place in software for the same reason it’s the most dangerous place in relationships—it’s just pleasant enough that you don’t fix anything until something breaks badly. The person who built it might not have the skills or the time to harden it. And by the time an experienced engineer gets involved, the app is already “business critical” and politically expensive to rework.

From the outside, this reads as agility: “We built this in a weekend!” From the inside, it’s closer to shoving boxes into a storage unit and deciding that owning the unit is being organized.

At small scale, this is fine. At organizational scale, it quietly becomes culture: we move fast now and mail the bill to Future Us.

A Non-Coder Tries It (and Documents Everything)

A writer at Stack Overflow—not a developer, by her own repeated admission—vibe coded a Reddit app for a hackathon using Bolt. Her account is worth reading because it’s honest about the ratio of magic to confusion.

The foundation took ten minutes. Then “it also didn’t work at all.” She spent 45 minutes copy-pasting error messages she didn’t understand into the chat. It eventually worked.

When a developer reviewed it, the problems were visible without even looking at the code—just from hitting “inspect” in the browser. No security features. Messy components. No tests. Inlined styling everywhere.

Her summary: “For a technology that is supposedly going to make junior developers obsolete, it needed a lot of help from my friends—all of whom are junior developers.”

Which is one of the most precise descriptions of the current state of things I’ve read.

When to Vibe Code (and When to Squint)

If you’re trying to decide whether vibe coding is the right move for a particular project, the heuristic is simpler than it looks: how much does it cost if this breaks, and who notices?

Prototypes, internal tools, data transformation scripts, automation glue, splashy demos—vibe code all day. This is where it genuinely shines.

Things get risky and pricey when payments are involved, when personal data is being stored, when regulators might read the code, or when the thing you built in a weekend quietly becomes something nobody can afford to rewrite. You can still vibe code your way in. Just know that the last mile will cost you—in time, in money, or in someone who knows where the sharp edges are.

What I Wish That Executive Had on the Slide

If I could rewrite the deck that was clearly in his head, it would say something like this: The barrier to building software just dropped dramatically. That’s great news for speed and experimentation. It’s less great news if nobody’s asking who owns what happens next. More people can create more software, more quickly, with less understanding of what’s under the hood. That is excellent for experiments, prototypes, and low-risk internal tools. It’s risky for anything that touches money, sensitive data, security, or regulation. The hard parts—auth, secrets, payments, rate limits, cost controls—did not go away. They just got easier to gloss over.

It’s not an engineering side quest. It’s a product, governance, and budgeting question wearing a very charming name.

When the marginal cost of building drops, the marginal cost of not thinking rises.

So What Is Vibe Coding, Really?

If I strip away the hype, my working definition is:

Vibe coding is building software by describing what you want to an AI, accepting code you don’t fully understand, and deciding that the speed and convenience are worth the IOUs you’re writing to the future.

Sometimes they are. Sometimes they’re very much not. The practice is here either way.

If you’ve vibe coded, you already know the feeling: that mix of “I can’t believe this works” and “I really hope I never have to debug this.” If you haven’t yet, you probably will. When you do, just remember: the real decision isn’t whether the thing runs. It’s what you’re comfortable not understanding—and who you expect to meet those unknowns later, when the vibes have worn off and the bills start arriving.

Share your experiences with vibe coding below.

Leave a comment

Thanks for reading Opinions & Conditions May Apply!

Share