What vibe coding is

You describe what you want. Something else writes the code. You look at what came back, say what is wrong with it, and go again.

That is vibe coding. It is not a product and not a specific app. It is a way of working.

Where the term comes from

The phrase was coined by the AI researcher Andrej Karpathy, describing a mode of building where you talk to the model, accept what it writes, and stop thinking about the code as code at all.

He was describing it for throwaway weekend projects — small things where nothing bad happens if the code underneath is a mess.

Then people started using the phrase for everything: side projects, internal tools, products with real users and real data. The name spread. The “throwaway weekend project” part quietly got dropped.

This course teaches the version that survives contact with reality. Same core move — describe, steer, repeat — plus the judgement that keeps it from falling over.

What actually changed

Building software used to have a hard entry gate: you could not make a thing until you could write the syntax for it. Not the idea, not the design — the literal characters.

An AI coding agent removes that gate. It can produce a working page in about the time it takes you to explain what you want.

What it cannot do is know what you meant, decide what “good enough” means for your situation, or notice that it just solved a slightly different problem from the one you actually have.

So the work splits into three parts:

1. Describing — saying what you want precisely enough that a machine can act on it.
2. Judging — looking at what came back and deciding whether it is right.
3. Deciding — knowing what to cut, when it is finished, and whether to ship it at all.

Only the first one is new. Two and three are the same skills a good editor or a good product person has always needed. Vibe coding does not delete them. It deletes the excuse that you could not build anything because you could not type code.

It is deliberately tool-agnostic

You will hear names — Claude Code, Codex, Gemini CLI, Cursor, and others. They differ in where they run and how they show you their work. A few live in your terminal, a few live inside a code editor, a few live in a browser tab.

None of that changes the skill. A good description is a good description everywhere. A vague one fails everywhere.

This course names tools only as examples. If your tool is not mentioned, nothing here stops working.

What this course refuses to tell you

That you no longer need to understand anything. That is the version of the pitch that gets people burned.

Here is the honest shape of it:

• You do not need to be able to write the code.
• You do need to be able to judge the code — at a level this course will teach you, which is much lower than “software engineer”.
• The gap between those two is where every bad vibe-coding story lives.

You will build real things. You will also, at some point, get a confident, well-formatted, completely wrong answer. Both are normal. The whole point of the next fourteen lessons is that the second one stops being expensive.

The loop you are actually learning

Everything in this course is one loop, run over and over:

Describe → Run → Read → Steer.

You describe what you want. Something runs. You read what happened — the screen, the error, the code. You steer: correct one thing and go again.

Beginners tend to do one giant Describe and then hope. Experienced people do the loop twenty times, small each time. That difference is most of the skill, and you will practise it for the rest of the course.