What Is Vibe Coding?

Section 01

What Vibe Coding Actually Is

Picture the old way: you open an editor, and every feature is yours to type, character by character, in a language with strict rules. A missing semicolon stops everything. You spend years learning syntax before you can build anything real.

Now picture vibe coding: you write "build me a landing page for a coffee shop with a hero image, a menu section, and a contact form," and a working page appears. You look at it and say "make the hero taller and the buttons green," and it changes. You never touched the syntax. Karpathy's original description captured the feel of it: you see things, say things, run things, and the code recedes into the background.

That is the headline. But the headline hides the thing that actually determines whether you build a toy or a tool, and that is what the rest of this class is about. First, where this came from, because the story explains why the practice works the way it does.

Section 02

Where It Came From

What made the practice possible was a step change in how good AI models got at writing code. The practice did not appear because of a clever new tool; it appeared because the models crossed a threshold where, for a large class of everyday programming, describing the goal became more efficient than typing the solution. Karpathy named a thing that working developers had quietly been doing for months.

The reason the name stuck is that it described a real change in the relationship between a builder and a machine. For decades the machine was a strict interpreter that did exactly and only what you typed. Now it is a capable collaborator that fills in enormous amounts of detail from a short description. That is a different kind of work, and it deserved a different name.

Section 03

The 2026 Shift: From "Vibes" to Engineering

In February 2026, on the one-year anniversary of the term, Karpathy proposed a more precise name for professional work: agentic engineering. The distinction is exact. Vibe coding is describing what you want and accepting what comes back. Agentic engineering is designing the system, specifying the constraints, and using AI to accelerate implementation you have already reasoned through. One is expression; the other is engineering.

You will start in the first mode, and you should. Describing what you want and seeing it appear is the fastest way to learn what is possible and to feel the leverage. But the goal of this Academy is to walk you up into the second mode, where you keep the speed of AI implementation without giving up the quality that real software demands. The bridge between them is a single mindset, which is the next section.

Section 04

The One Mindset That Changes Everything

A prompter types a wish and accepts whatever the AI returns. An architect decides the structure, names the constraints, defines what "done" looks like, and verifies the result against that definition. The same AI, given the same task, produces wildly different software depending on which one is driving. This single distinction is the difference between a demo that breaks and a product that holds.

Here is the trap that catches almost everyone. AI-generated code reads as authoritative. The structure is clean, the names are sensible, the comments are present. It looks like it was written by someone who knew exactly what they were doing, even when the underlying logic quietly assumes something that will not always be true. A prompter sees clean code and ships it. An architect asks: what did I not specify, and what will the AI have guessed?

The architect's secret is not more technical knowledge at the start. It is understanding that the agent cannot surface what you did not know to require. The gaps in your specification become the gaps in your software. That is not a flaw in the AI; it is the nature of delegating to something that does precisely what you ask. Understanding becomes the real bottleneck, and therefore the real leverage.

Section 05

What Vibe Coding Is Genuinely Good At

Vibe coding excels at the first roughly 80 percent of an application: the implementation that flows naturally from a clear description. Industry analysis suggests it compresses 60 to 70 percent of typical web-development work. Prototypes, standard features, layouts, and well-trodden patterns come together in minutes instead of days, which is exactly why a beginner can build something real on day one.

Concretely, it shines at: turning an idea into a working prototype fast; building standard features that have been written a million times before, like forms, lists, and dashboards; producing layouts and styling from a description; explaining unfamiliar code in plain language; and handling the tedious, boilerplate-heavy parts of a build that used to eat hours. If you can describe it clearly and it resembles something that has been built before, AI will likely implement it well.

Section 06

Where It Breaks (Be Honest About This)

Vibe coding struggles with the last roughly 20 percent of an application: edge cases, error paths, failure recovery, and scaling constraints. Vibe-coded work consistently arrives missing these, not because the AI forgot them, but because the developer never specified them.

There is a memorable way to think about this. In a working system, the happy path is where things go right. The unhappy paths — the wrong password, the empty cart, the dropped connection, the flood of traffic — are where you find out what your software is actually made of. AI is purpose-built for the happy path that flows from a clear description. The unhappy paths require someone who has thought through the system, which is to say, an architect.

None of this is a reason to avoid vibe coding. It is a reason to learn it properly. Knowing the boundary — the 80 that flows and the 20 that must be specified — is what lets you use the speed without shipping the bugs. Most of the Academy's craft lives in mastering that 20 percent.

Section 07

The DDS Vibe Coding Method

The DDS method is intent-based engineering: the architect defines the architecture and the constraints, and AI handles the implementation. It is the agentic-engineering mode applied with discipline. Not a special tool you buy — a way of working you can start practicing in your very first session, and the method every page and system in this Academy was built with.

The method has a simple shape that you will see again in every Foundation class. You decide what to build and the rules it must obey. You describe that intent to the AI as a specification, not a wish. The AI implements. You read, verify, and direct corrections. Repeat until the result meets your specification. The skill is not in the typing; it is in the deciding, the describing, and the judging.

What makes it powerful is that it scales. The same loop that builds a single landing page builds a multi-page store, and then a system of automated agents. You are not learning a beginner trick you will outgrow. You are learning the actual method used to build the storefront, the academy, and the advanced systems you saw in the showcase below.

Section 08

Your First Intent (Copy These)

You do not need any software installed to understand the difference a good intent makes. Below are two descriptions of the same project: a weak one a prompter would write, and a strong one an architect would write. Copy them, compare them, and keep the architect version as a template. The structure — goal then constraints then definition of done — is the whole lesson.

First, the weak version. This is what most people type, and it is why most people get software that breaks at the first edge case:

Build me a to-do list app.

Now the architect version of the exact same request. Notice it states the goal, the constraints, and what "done" looks like — the things the AI would otherwise have to guess:

Build a single-page to-do list app.

Goal: let one person add, complete, and delete tasks in the browser.

Constraints:
- Plain HTML, CSS, and JavaScript in one file. No frameworks, no build step.
- Tasks persist in the browser so they survive a page refresh.
- Show a count of remaining (incomplete) tasks.
- Handle the empty state: when there are no tasks, show a friendly message,
  not a blank screen.
- Handle bad input: ignore an empty task, and trim extra spaces.

Done looks like:
- I can add a task, mark it complete (with a visible strikethrough),
  and delete it.
- Refreshing the page keeps my tasks.
- Adding nothing does not create a blank task.

Build it as one complete file I can paste and run. Then tell me, in plain
language, what each part does.

That is not more technical, it is more specified. Every line you added is a decision the AI no longer has to guess. This is the architect mindset compressed into one prompt: you did the thinking about what the software must do, and you let the AI do the typing. When you have a tool installed in the next class, paste the strong version and watch what comes back. Then read it like an architect, and find what is still missing.

Section 09

How to Start

Start by changing how you think before you touch any tool. Decide what you want to build, write it as an architect's specification with goal, constraints, and a definition of done, and plan to read and verify whatever the AI produces. The next Foundation class gets you a working environment; this class gets you the mindset that makes the environment worth having.

Three concrete first moves:

1. Take the strong intent template above and rewrite it for a tiny project of your own. A habit tracker, a tip calculator, a personal homepage. Keep the structure: goal, constraints, done looks like.
2. Get honest about the unhappy paths. For each thing you want, ask what should happen when it goes wrong. Write that down. This is the 20 percent.
3. Continue to the next Foundation class to set up your first AI coding environment so you can run your intent and see real software appear.

You now have the accurate mental model that most people skip. You know vibe coding is describing, not typing; that the mindset decides the outcome; that the tool is a fast literal builder, not a mind reader; and that the craft is in specifying the 20 percent it cannot guess. That is the foundation. Everything else in the Academy builds on it.

FAQ

Frequently Asked Questions

The questions newcomers ask most about vibe coding, answered plainly. Each answer matches this page's structured data exactly, so a person reading the page and an AI engine extracting the schema get the same canonical response.