What "vibe Coding" Actually Means (defined On Our Terms)
"Vibe coding" gets thrown around to mean ten different things. Here's what it means in this curriculum.
Vibe coding, as we use it: building software by describing what you want to a coding agent in natural language, reviewing what it produces, and iterating until the software does what you wanted.
That's it. That's the whole definition.
What vibe coding is NOT:
It is NOT "I don't have to understand anything." You have to understand the problem domain (what your software is supposed to do), the data domain (what shape your data is in), and enough of the technical domain to review the output. Vibe coding lowers the bar for typing skill, not for thinking skill.
It is NOT "I press a button and software appears." Vibe coding is a loop: describe → generate → review → correct → describe again. The loop is where the work happens. People who skip the review step ship broken software.
It is NOT "the agent decides what to build." YOU decide what to build. The agent is a faster typist. If you don't know what you want, the agent will build something, and that something will not be what you needed.
The vibe coder's job, in order:
- Decide what you're building and why.
- Specify it in writing, in enough detail that someone who has never spoken to you could build it.
- Hand the spec to an agent.
- Review the output. Run it. Test it.
- Correct the spec when the output isn't what you wanted. (The bug is almost always in your spec, not in the agent.)
- Repeat until done.
If you're doing all six steps, you're vibe coding. If you're doing only step 3, you're cosplaying.
Something wrong on this page? →
Curriculum last updated 2026-04-30