HOT OFFERINGSVibe coding is becoming the “pineapple on pizza” of software engineering. The Internet does not seem to agree on whether it’s a powerful trend or an insanity designed to create a generation of responsible coders.
The opinions swing towards both extremes of the spectrum, from “If your CEO is not vibe coding, then you are working for the wrong company” to “VIBE CODING IS A SCAM”.
The Xenoss team has been building AI products since the early days of machine learning, so we have a fairly good grasp of what AI can and cannot do.
So here’s our reality check: a clear-eyed look at vibe coding that avoids both elitist gatekeeping and hype-driven hustle culture.
What is vibe coding, and why is it trending?
When Andrej Karpathy casually mentioned “vibe coding” in a tweet, he may not have realized he was coining the next big buzzword in machine learning. If he had, he might’ve defined it more clearly.
Karpathy’s original definition is fairly free-form.
It can be summarized in the following way:
- Vibe coders don’t code at all (or as much as touch the keyboard, if they prefer talking to LLMs in voice mode).
- Vibe coders don’t need to know what they are doing: when an error occurs, they “copy-paste the error message” and ask the LLM for “random changes until it goes away.”
- A vibe coder’s process is to “see stuff, say stuff, run stuff, and copy paste stuff – and it mostly works”.
The core idea isn’t entirely new. Anyone following tech trends will recognize echoes of the no-code movement, which has been promising software without software engineers for over a decade.
Is vibe coding different from no-code?
No-code tools promised software without writing code. They relied on stitching together premade interface blocks via APIs, with clear limits on how those parts could connect.
Vibe coding takes a different path: it turns thoughts into code.
That’s the real distinction. No-coders don’t code at all. Vibe coders do, but they don’t write the code themselves, and often don’t fully understand the output.
Why some say vibe coding has already killed no-code
Keneth Auchenberg, partner at AlleyCorp, a New York-based VC fund, believes that vibe coding has unbundled, if not altogether killed, no-code.
The last decade of no- and low-code abstractions promised a revolution — they would democratize software creation. But let’s be honest: none of them broke through. No-code didn’t replace code or traditional programming. It didn’t even come close.
Now, a decade later, we’re watching something else emerge: vibe coding — a new breed of tools powered by AI and LLMs that can write real, production-grade code from natural language. Tools like Bolt, Lovable, v0, and others are showing that prompt-to-code workflows are not only possible — they’re better.
Is all LLM-assisted coding “vibe coding”?
Machine learning experts beg to differ on calling all AI-assisted coding “vibe-coding”.
Putting all LLM-assisted coding under the vibe-coding umbrella would not meet the “forget that code even exists” principle of Karpathy’s definition.
In a post titled “Not all AI-assisted programming is vibe-coding,” Sam Willison points out that proficient software developers need to read the code.” According to Willison, if a developer carefully analyzes, reviews, and debugs LLM code and, most importantly, understands it, he is just a regular engineer, not a vibe coder. Vibe coding is about intentionally not reading the blueprint, not digging into the code, and reducing the human involvement in pure software development to a minimum.
If the only programming language you use to build your app is English, you may be a vibe coder.
Early successes of vibe coding
Currently, no fully vibe-coded product has closed a major VC round.
Most are indie-built, bootstrapped, and far from enterprise-grade, but that doesn’t mean they aren’t generating value (and revenue).
Here are a few examples:
- Fly is a multiplayer browser-based flight simulator created almost entirely through AI-generated code. It was built in just a few hours and features microtransactions and in-game advertising for monetization. The team behind Fly has reported reaching $12,000 in MRR.
- ChatIQ is an AI-powered chatbot and ticketing system designed to streamline customer support by learning from your company’s data. It’s currently generating $2,000 in monthly recurring revenue.
- TrendFeed is an AI-driven content discovery platform that helps creators find viral trends across various industries. Approximately 75% of its code is generated by AI tools. As of March 2025, it earned around $10,000.
None of these apps are high-stakes products in highly regulated industries like finance or healthcare. None are adopted by global enterprise clients, where security and performance requirements are much less forgiving.
Vibe coding can successfully deliver value that users would be willing to pay for, which is why it’s becoming a number-one source of passive income for thousands of beginner programmers.
Vibe coding tools: What your stack might look like
Initially, vibe-coding was marketed as a “lean and clean” way to build software within a single platform like Cursor, Vercel, or Bolt.
But like any evolving ecosystem, it quickly fragmented. More tools appeared, more stacks emerged, and complexity crept in.
Or, to put it in meme language:
This is an exaggeration of how “bloated” a vibe coder’s stack can get.
While the market now offers many options, when these tools are broken down by category (version control, front-end, back-end, database, etc.), the list is rather modest.
Here is an example of a fully functional vibe coding tech stack.
In this framework, there are just a few tool categories to consider:
- Text-to-app platforms do most of the work by turning abstract ideas into code. Examples: Bolt, Vercel, Cursor AI, Replit.
- Database/back-end tools like Supabase (also takes care of authorization) or PocketBase.
- Data editors like Airtable, Retool, or Smartsheet.
Each category has alternatives, giving vibe coders the freedom to choose based on budget, preference, or familiarity.
Does vibe coding cut time to market? Likely, yes. If some developers say they’re building four projects in the time it used to take to ship one, that’s worth paying attention to.
Still, the internet is split, with some calling vibe coding the future, and others treating the term like a punchline.
So what’s the opposition worried about?
The mess of the vibe code deployment
Andrej Karpathy’s experiment in “vibe coding,” an app that generates images of confusing restaurant menu items, does a great job of showing the process’s limitations.
The full post deserves a read. For the sake of time efficiency, here is a recap of all the roadblocks Karpathy’s vibe coding tools hit before MenuGen became usable.
- Early local demo felt “80 % done” but was only about 20 % complete once backend/infra work surfaced.
- The app struggled to grab OpenAI keys and fought Claude’s hallucinated, deprecated OpenAI API names & conventions.
- Andrej hit OpenAI rate-limits (just a few OCR calls every 10 min), throttling iteration.
- Replicate API had moved to a streaming response; outdated docs + LLM knowledge tanked first image-gen attempts.
- Replicate’s rate limits further slowed debugging
- The first Vercel build died on lint errors visible only in remote logs.
- The website kept failing until Andrej realised Vercel lacked the .env API keys ignored by Git.
- Vercel auto-published a private repo at a public URL.
- Clerk auth code hallucinated thousands of deprecated API calls, demanding manual untangling.
- Clerk demanded buying a custom domain, as well as setting up DNS and Google OAuth.
- Multi-step Vercel ↔ Clerk ↔ Google approval dance sapped hours and motivation.
- Stripe’s “Next.js” JS snippets clashed with a TypeScript codebase, tripping linters.
- Claude initially linked payments to user email instead of stable IDs—credits could vanish.
- Promoting Stripe from dev to prod meant recreating products/prices and recopying keys.
- With no DB or queue, long menus timed out, and all results evaporated on refresh.
In Andrej’s words,
Vibe coding menugen was an exhilarating and fun escapade as a local demo, but a bit of a painful slog as a deployed, real app.
If an ex-OpenAI and ex-Tesla engineer had a hard time navigating vibe coding, it’s safe to say that coding neophytes won’t have it much easier.
Deploying a fully vibe-coded app is not easy because no single tool would bring an idea to a prototype and a prototype to production.
Also, even if there was an easier production pipeline, vibe-coded apps are often simply not ready for deployment.
Vibe code debugging: Why it gets messy fast
Vincent Vanderdam, an ML engineer and blogger, shared how he tried to vibe code a Flask app to automate a few repetitive work tasks. Things were going well until they were not.
The app’s pytest fixture tweaked app.config after SQLAlchemy had already been initialised, so any lingering SQLALCHEMY_DATABASE_URI (or DATABASE_URL) pointing at production meant tests unknowingly connected to, and then, in teardown, dropped tables, from the live database.
After LLM’s attention was brought to the problem, it offered a shallow fix that prevented the loss of database data but completely missed the root cause, the lack of separation between testing and production environments.
Vanderdam’s reaction to the final code was “Imagine debugging this”.
The problem in fixing AI code is in having to work with something you don’t understand.
On a scale of day-to-day apps that automate simple tasks like creating custom recipes based on photos of the fridge, not understanding under-the-hood tech is not a problem. But, when more users start trying the app in different environments or when new features are added, having no grasp of under-the-hood tech is a ticking time bomb of technical debt.
In his blog, Namanyay Goel calls Karpathy’s vibe coding movement irresponsible because over time, “a vibed solution becomes a black box, and these black boxes multiply. Soon, you’re building on top of foundations you don’t comprehend.”
Why vibe-coded apps can be security nightmares
Many machine learning engineers have raised the alarm: vibe-coded apps can become security liabilities, especially when their creators don’t understand what’s happening under the hood.
Today’s internet is a web of interconnected APIs. Platforms constantly exchange data.
So what happens when that ecosystem includes apps built by vibe coders with little grasp of syntax, architecture, or basic security principles?
Sam Willison points out that it’s now possible to “vibe code personal tools that you paste personal information into,” without realizing how that data might leave the machine, or who might intercept it.
And that’s the danger: unseen vulnerabilities written by people who don’t even know they’ve created them.
How to “not ruin the vibe” of vibe coding (and make sure it does not ruin you)
The name “vibe coding” suggests freedom: relax, have fun, and build production-ready apps on a whim. That vibe might work for seasoned engineers like Andrej Karpathy or Andrew Ng. But for beginners, it should be less about vibes and more about discipline.
Vibe coding tools empower anyone with a PC to become a citizen developer, building apps that automate tasks, boost productivity, and change how we interact with the web.
But with that power comes responsibility.
To keep the vibe alive and ship something safe and sound, here are some ground rules:
- Writing highly detailed project requirements outlining the purpose of the project, its key features, and the third-party components it uses. AI should have all possible context about the app before it starts coding.
- Assess maintenance costs. There are plenty of horror stories of people racking up massive cloud or API bills, and vibe coding can make those worse. Beginner engineers should think twice before vibe-coding anything with usage-based billing.
- Learn testing fundamentals. AI is still bad at debugging itself. Humans need to verify edge cases and ensure system behavior is safe before hitting deploy.
- Don’t depend on your tools; start learning the fundamentals. Vibe coding is a great dopamine hit, but it should be a launchpad, not the destination. Learn syntax, logic, and software fundamentals to avoid building on shaky ground.
The bottom line: vibe coding is something the tech world loves to hate. Its potential is real, but so are its risks.
As Karpathy quipped, “How are we supposed to automate society with this by 2027?”
Professional engineers aren’t going anywhere. But expect a growing crowd of vibe coders to join the build party, ideally with their eyes open.
