What Is Vibe Coding?

A person with no programming background, no computer science degree, and no idea what a “database schema” is sat down on a Saturday morning with an idea for a simple SaaS tool (software as a service, the kind of web app people pay a monthly fee to use). By Sunday evening, they had a live product: a real URL, a working sign-up flow, a Stripe integration (Stripe is a service that handles credit card payments) collecting real money, and three paying users.

This was not a prototype held together with duct tape. It was not a no-code mockup that couldn’t scale past ten users. It was functional software, built by someone who had never written a line of code in their life.

That was not possible two years ago. This lesson covers what changed and what it means for you: what vibe coding actually is, and why the timing matters now.

What does “vibe coding” actually mean?

The term comes from Andrej Karpathy, one of the founding members of OpenAI and the former head of AI at Tesla, who used it in early 2025 to describe a new way of building software: you describe what you want in plain English, and an AI writes the code that makes it happen. There is no syntax to learn, no function names to memorize. You are having a conversation with a system that translates your intent into working software.

The name is intentionally casual, and that casualness is part of the point. You are not engineering. You are steering.

In practice, this looks like typing “I want a button that lets users upload a photo, resize it to 400 pixels wide, and download the result” into a chat interface, and watching the AI produce the code that does exactly that. Your job is to know what you want, evaluate whether the output is right, and tell the AI when it needs to adjust.

This is a real skill. It is just a different skill than traditional programming.

How is this different from learning to code?

Traditional coding asks you to operate at the level of implementation. You decide that a character walks across a room, and then you specify every footstep in a language the computer understands. That takes years of practice before the writing stops getting in the way of the thinking.

Vibe coding is closer to directing a movie. You still need to know what story you want to tell. You still make the decisions that matter: what the thing does, who it is for, what the experience feels like, whether the output is actually right. But you are not operating the camera yourself. You have a crew that handles the technical execution, and your job is to communicate clearly and catch problems before they make it into the final cut.

The two approaches below accomplish the exact same thing. Toggle between them to see what changes and what stays the same. One requires you to understand databases, async JavaScript, and DOM manipulation. The other requires you to describe what you want.

This analogy matters because it clarifies both what you gain and what you still have to bring. A director who does not know what they want, or who cannot tell a good scene from a bad one, will not get good results just because they have a talented crew. Vibe coding gives you the crew. You still have to direct.

The other thing this framing clarifies: directing is a skill. The best vibe coders are not the ones who found a magic shortcut past competence. They are the ones who got good at describing what they want, reading AI output critically, and knowing when to push back.

Why is this possible now?

AI models learned to write code by training on an enormous amount of it. Examples of correct code, patterns of how code is structured, how problems are decomposed, how different pieces fit together. These systems are called large language models, or LLMs: systems trained on massive amounts of text and code to predict what should come next. We will cover the mechanics in detail later on, but for now, the name is enough.

At some point in the last few years, these models crossed a threshold where they could produce code that actually runs, handles real cases, and solves problems that were not in their training data. The gap between “AI that writes toy examples” and “AI that writes production code” closed faster than most people expected. That gap is still not fully closed. But it closed enough.

The prompt below is real. Toggle between the two years to see what the same question returned in 2022 versus what it returns in 2026.

The AI is doing something real: applying patterns it has internalized across millions of codebases to generate plausible, often correct solutions to problems you describe. It also makes mistakes, misunderstands you, and occasionally produces code that looks right but has subtle bugs. Knowing that this is the failure mode, and building a habit of testing and verifying output, is more useful than either blind trust or reflexive skepticism.

Won’t all of this change next week?

There is a new AI model or tool announcement practically every other day. A new version of Claude, a new coding agent from OpenAI, a startup claiming to build entire apps from a single sentence. If you follow the news, it feels like anything you learn today will be outdated by Thursday.

It will not. The tools change. The fundamentals do not.

Knowing how to write a clear specification, how to break a problem into parts the AI can handle, how to evaluate output and catch mistakes, how to debug when something fails: none of that expires when a new model drops. A better model makes those skills more effective, not less relevant. The person who can describe what they want precisely and verify the result carefully will get better output from every model, current and future.

What can you actually build with this?

This is worth being direct about, because the hype around AI tools has a way of making people either wildly overconfident or dismissively skeptical, and both stances will cost you.

• Strong territory: Prototypes, MVPs (a minimum viable product, meaning the simplest version of your idea that real users can actually use), internal tools that a small team needs but no one wants to spend engineering time on, personal projects, and simple web apps with standard features like user accounts, dashboards, forms, and basic data storage. If your idea lives in this category, a focused person with no prior coding experience can realistically build and ship it.

• Where it struggles: Complex enterprise software that needs to integrate with dozens of existing systems, safety-critical applications where a bug has real consequences, performance-sensitive infrastructure, and financial or medical systems where regulatory requirements shape the architecture. Vibe coding can still help with parts of these, but you need engineers who can evaluate and own the output.

The practical test: if a bug in your app means a user gets an error message and has to refresh, you are probably in safe territory. If a bug means someone gets the wrong medication dose, you are not.

What tools will you be using?

Vibe coding tools fall into two categories that work at different levels of abstraction.

• Lovable (lovable.dev) is a browser-based builder. You open a website, type a description of what you want, and the tool generates a working application. No installation, no visible code, no setup. This is where the course starts.

• Claude Code is a terminal-based tool that runs on your computer, with direct access to your actual project files. Instead of working inside a browser sandbox, you are operating on a real codebase. More control, more visibility, steeper initial setup. This is where the course goes once your projects need it.

The course starts with Lovable because the on-ramp is immediate. You will be looking at a working app before you have had a chance to get intimidated. Once you have built intuition for describing what you want and evaluating what you get, Claude Code will feel like a natural step up rather than a leap into the unknown.

What comes next?

Before you open any tool, it helps to have a basic mental map of what software actually is. Not to become a programmer. Just so that when the AI hands you something back and says "I set up a React frontend with an Express backend," you have some idea what those words refer to. That map is what the next lesson covers.