Andrej Karpathy — one of the original researchers behind Tesla's self-driving system and a founding member of OpenAI — coined the term "vibe coding" in early 2025. His description was deliberately casual: you describe what you want, the AI writes the code, and you just… go with the vibe. You don't really understand what's happening under the hood. You just keep prompting until it works.
A lot of developers found this horrifying. And a lot of non-developers found it liberating. Both reactions make sense. Because vibe coding is genuinely useful for a significant category of tasks — and genuinely problematic for another. Understanding which is which is the whole game.
What Vibe Coding Actually Is
Vibe coding, stripped of the brand, is just using AI to build software through conversation rather than through writing code by hand. You describe what you want in plain English. The AI generates the code. You look at whether it works — not whether the code is well-written — and iterate from there.
The crucial part is the last bit: you're evaluating the output, not the code. A traditional developer reads the code to understand what it's doing. A vibe coder runs it, sees if it behaves correctly, and if not, describes the problem back to the AI. The code is almost beside the point.
"You're evaluating the output, not the code. That's the whole shift — from writing software to directing it."
This turns out to be enough for a surprisingly large number of things. Not all things. But a lot.
What It's Actually Good For
The honest answer is: tools for yourself, scripts that solve a specific problem once, internal dashboards, prototypes, and small web apps where the stakes are low and the scope is contained.
A marketing manager building a tool that pulls their campaign data from three different sources and displays it in one dashboard — that's a great vibe coding project. A consultant building a spreadsheet automation that processes a specific type of report their clients send every month — perfect. A small business owner building a simple booking form that emails them when someone fills it out — absolutely.
The best vibe coding projects are ones where you're the main user, the scope is narrow, and if something breaks you'll notice immediately. You know exactly what "working" looks like because you're the person using it. That combination — clear success criteria, low stakes, known user — is where AI-assisted building shines.
In 2026, the tools for this have become genuinely impressive. Cursor and Windsurf are AI-first code editors that handle the heavy lifting while giving you enough visibility to course-correct. Replit lets you build and deploy directly in the browser with no local setup. Lovable specialises in turning conversational descriptions into working web apps with a few iterations. Claude Code handles the full software engineering loop — writing, testing, debugging — autonomously in your terminal.
What People Are Actually Building
The range of things being built by non-developers using these tools in 2026 is genuinely remarkable. A few real categories that come up repeatedly:
Internal dashboards. Teams pulling data from their CRM, their ad platform, and their accounting software into a single view — built by the ops person who knew what they needed but not how to code it. Projects that would have required a developer and a sprint cycle now take a Friday afternoon.
Workflow automation scripts. Accountants building tools that process a specific type of client export and transform it into the format their software expects. HR managers building scripts that generate offer letters from a template with the right variables filled in. The kind of task that previously required knowing Python — now handled conversationally.
Customer-facing tools. Calculators, quote generators, interactive forms, simple configurators. The kind of single-purpose web tool that used to require a developer to scope, build, and maintain. Now built and iterated on by the person who actually understands the business problem.
Personal productivity tools. This is where some of the most interesting experimentation is happening. People building exactly the tool they want — with their own logic, their own edge cases handled — rather than adapting to whatever a SaaS product offers.
Where It Still Falls Short
The case against vibe coding is real, and it's worth taking seriously. The core problem is that AI-generated code is often subtly wrong in ways that aren't immediately visible. It might work in the happy path and break on edge cases. It might handle data correctly most of the time and silently corrupt it in specific circumstances. It might have security vulnerabilities that would be obvious to a developer reading the code and completely invisible to someone who isn't.
For software that handles sensitive data, money, or anything with significant consequences if it breaks, vibe coding is not the right tool. The inability to read and reason about the code isn't just an aesthetic limitation — it means you can't verify that what's running is actually what you think is running.
Vibe code tools where a bug is annoying. Don't vibe code tools where a bug is costly. If the software touches real money, stores personal data, or affects decisions that matter — you need someone who can read the code, not just observe whether it seems to work.
There's also a maintenance problem. AI-generated codebases tend to accumulate technical debt faster than hand-written ones, because each new feature gets bolted on conversationally without anyone stepping back to think about how it fits the overall structure. Projects that stay small are fine. Projects that grow can become hard to change without breaking something.
The Bigger Picture
The interesting thing about vibe coding isn't that it's replacing software developers — it largely isn't, for the reasons above. What it's doing is something more nuanced: it's collapsing the gap between having a problem and being able to build a solution to it.
For most of the history of software, building something required either learning to code (a multi-year investment) or convincing someone who could to do it for you (a negotiation, a budget, a timeline). That friction shaped which problems got solved. Lots of genuinely useful tools never got built because they weren't worth hiring a developer for, and the person who needed them couldn't build it themselves.
That's what's changing. The marketing manager with a data problem, the consultant with a workflow they want to automate, the small business owner who wants exactly this specific tool — they can now just build it. Not perfectly, not at production scale, not with enterprise security. But they can build something that works, that solves their actual problem, without asking anyone's permission or budget.
That's a meaningful shift. And it's only going to get easier from here.
Start at AI.actually Academy
Free lessons on using AI for real work — including how to use Claude to build tools, automate workflows, and actually get things done.
Go to the Academy