What Vibe Coding Is (and Isn't)
On 2 February 2025, Andrej Karpathy, whom Collins calls an "AI pioneer", posted a short note about a new way he was building software: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He said he clicked "Accept All" on every change and didn't read the code. Within a year the phrase was the Collins Dictionary Word of the Year. Now ask yourself: if you build DayBoard that way, and a stranger signs up and saves their home location, who checked that the stranger's data is safe? This lesson explains what the term originally meant and how it spread to mean almost any AI-written code. It then sets out a spectrum from "forget the code exists" to fully reviewed engineering, and a simple rule for where each project belongs on it. By the end you'll know where DayBoard sits on that spectrum, and why this course keeps the speed but adds checks.
The tweet that named it: Karpathy, February 2025
Karpathy's post is short, and every sentence describes a habit. Read it as a list of things he stopped doing:
| What Karpathy wrote | What it means in practice |
|---|---|
| "I 'Accept All' always, I don't read the diffs anymore." | A diff is the list of lines the AI added or removed. He approved every change without looking at it. |
| "When I get error messages I just copy paste them in with no comment, usually that fixes it." | Errors go straight back to the AI. He didn't try to understand them. |
| "The code grows beyond my usual comprehension" | After a while, he couldn't explain his own project without a long read. |
| "Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away." | Some bugs were never fixed, only hidden. |
He also wrote that he talked to his editor by voice and barely touched the keyboard. His summary: "I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."
The part people forget is his own warning label. In the same post he wrote that this approach is "not too bad for throwaway weekend projects". He was describing a fun way to make a toy, not a way to run a business.
You've already met the modern version of "Accept All". In the lab-setup lesson you saw permission modes: the settings that decide whether your agent asks before it acts. A mode that never asks is the tool doing what Karpathy did by hand. That can be fine. It depends on what you're building, which is the rest of this lesson.
From throwaway tweet to Word of the Year
The word spread fast. On 6 November 2025, Collins named "vibe coding" its Word of the Year for 2025. Its announcement explains the term as "the use of artificial intelligence prompted by natural language to write computer code". It also notes that "tech experts debate whether it's revolutionary or reckless".
Compare that definition with the original post. Collins describes any code written by AI from plain-English instructions. Karpathy described something narrower: not reading the code at all. Both uses are now common, and that causes real confusion. Someone who reviews every line the AI writes and someone who never looks at it can both say "I vibe coded it", yet their apps carry very different risks.
Karpathy himself returned to the term a year later. In February 2026 he wrote that back then, "you'd mostly use vibe coding for fun throwaway projects, demos and explorations". By 2026, he said, "programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny." His favourite name for that careful version was agentic engineering: "agentic" because "you are orchestrating agents who do and acting as oversight", and "engineering" because it is "something you can learn and become better at".
Not all AI-assisted programming is vibe coding
The clearest line between the two was drawn by programmer and writer Simon Willison in March 2025. He noticed people "apply the term 'vibe coding' to all forms of code written with the assistance of AI", and argued that this blurs a useful idea. His definition: "building software with an LLM without reviewing the code it writes." (An LLM, or large language model, is the AI model behind tools like Claude and ChatGPT.)
The test is review, not authorship. Willison writes that if an LLM wrote the code "and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that's not vibe coding, it's software development." His own rule for code he relies on: "I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else."
Willison isn't against vibe coding, though. The post's title ends "(but vibe coding rocks)", and he writes: "If vibe coding grants millions of new people the ability to build their own custom tools, I could not be happier about it."
Here are the three definitions side by side:
| Source | What counts as vibe coding | Does reviewing the code change the answer? |
|---|---|---|
| Karpathy, Feb 2025 | Accept every change, don't read diffs, forget the code exists | Yes: reviewing is the opposite of what he described |
| Collins, Nov 2025 | Using AI prompted by natural language to write code | No: any AI-written code qualifies |
| Willison, Mar 2025 | Building with an LLM without reviewing its code | Yes: reviewed, tested and explainable code is "software development" |
This course uses the strict sense (Karpathy's and Willison's). When a lesson says "pure vibing", it means nobody reviewed the code.
The spectrum: from "forget the code exists" to agentic engineering
It helps to stop treating this as yes-or-no and picture a dial. The question at each point is the same: how much of the agent's work does a human check before it matters? Karpathy's 2025 post sits at one end and his 2026 "agentic engineering" at the other. Willison's line (reviewed, tested, explainable) marks where vibe coding stops.
Read the four points like this:
- Pure vibe coding. You never look at the code. You judge the app only by whether it seems to work. This is the original post.
- Vibing with checks. You still don't read every line. But you run the app yourself, you test the parts that could hurt someone, and you keep save points so a bad change takes seconds to undo.
- Reviewed AI-assisted development. You read each diff and can explain it. By Willison's test, this is no longer vibe coding.
- Agentic engineering. Agents do almost all the typing, and your job is direction and oversight, which Karpathy calls a skill you can learn.
Points 1, 3 and 4 come straight from the sources. Point 2 is this course's own label for the middle ground a beginner can actually reach. You can't yet review code like a professional, but you can check outcomes that matter. Moving right costs time, so you choose a position based on what's at stake.
When pure vibing is fine
Pure vibing is a good choice more often than its critics admit. Karpathy called it "not too bad for throwaway weekend projects". Willison's first point is that projects "should be low stakes", and he adds: "Think about how much harm the code you are writing could cause if it has bugs or security vulnerabilities."
Two kinds of project usually pass that test:
- Throwaway prototypes. A clickable mock-up to show a teammate, or a quick experiment to see if an idea feels right. If it breaks, you delete it. The point is learning fast, not shipping.
- Personal tools that only you use. A page that turns your notes into a checklist, or a script that renames your photos. The only person who can be hurt is you, and you can see when it breaks.
Even in those cases, Willison's list adds a few caveats worth keeping in mind. Watch out for secrets: "anything that looks similar in shape to a password, such as the API key used to access an online tool". Be careful with tools that touch private data, even your own. And anything that calls another company's service can cost money or add load to that service.
For DayBoard, a pure vibe session is a reasonable way to answer a design question. For example: "Show me three different layouts for the weather card, with fake data." Nothing real is at stake, and you'll throw two of the three away. Pure vibing becomes a problem the moment a real person's data reaches the app.
When vibing isn't fine: data, money and security
The same Willison post lists the situations where you should slow down. Each one turns a private toy into something that can hurt someone:
- Other people's data. "If you are building a tool that has access to private data", he says to approach it with caution. For anything "that might be used by other people", he recommends asking someone more experienced to check it before you share it.
- Money. "Be very careful about using vibe coding against anything that's charged based on usage." A bug that loops on a paid service can turn into a bill.
- Security. Secrets such as passwords and keys, and code whose bugs or vulnerabilities could cause harm, both fall under his "how much harm" test.
You've already seen the real-world version in the syllabus: CVE-2025-48757, recorded against apps generated by the AI app builder Lovable. The NVD entry describes an insufficient database security policy that let unauthenticated attackers read or write the data of generated sites. Lovable disputes the record, saying each customer is responsible for protecting their own app's data. The lesson for you is the same either way: an app can look finished and still leave every user's data open. You only find out by checking. Lesson 05-04 covers that failure and how to test for it.
Pick a project type below to see which review level fits it.
App with users: review the outcomes that protect people
Example: DayBoard once strangers can sign up. It stores other people's tasks and home locations, so pure vibing is off the table. Have the agent work fast, then check what matters: test that one user can't see another's data, keep secrets out of the code, review changes before they go live, and know what it costs. That is the level this course teaches.
Where this course sits: fast agent-driven building with checks
DayBoard starts as a toy and ends as an app with users. Once it's live, it will hold other people's task lists and home locations, and it will call an outside weather service. By Willison's criteria, that rules out pure vibing. It's private data that will be "used by other people".
But the course doesn't ask you to become a professional code reviewer first. It places you at point 2 on the spectrum, moving toward point 4. The agent does the typing at full speed. You add a small set of checks, each at the moment it starts to matter:
| Check | What it protects | Where you learn it |
|---|---|---|
| A one-page spec and project rules file | The agent builds the right thing | Module 02 |
| Reading diffs, errors and the running app | You notice when the agent goes wrong | Module 03 |
| Git commits as save points | Any bad change can be undone in seconds | Module 04 |
| Database rules tested as a second user | Strangers can't read each other's data | Module 05 |
| Preview deploys before going live | You see changes before users do | Module 06 |
| Security checklist, smoke test, cost cap | Secrets, "done" and the bill | Module 07 |
This matches what Karpathy described for 2026: agents writing the code, with "more oversight and scrutiny". You can still have the fun part of vibe coding. The checks just make sure you find problems before your users do.
Do it now: ask your agent where DayBoard sits
Open your agent in the dayboard folder you made in the lab-setup lesson. Paste this prompt. It only asks for an answer, so the agent shouldn't change any files. If it asks to, say no.
I'm about to build DayBoard: a web app where people sign in by email,
save a home location, see the local weather forecast and manage a task list.
Don't write any code or create any files. Just answer:
1. What personal data will this app store about other people?
2. Which outside services will it call, and could any of them cost money?
3. Name two things that could go wrong if nobody ever reviewed the code you write for it.
Read the answer critically. Did it mention the home location as personal data? Did it say whether the weather service is free? If something looks wrong or vague, ask a follow-up. Questioning the agent's answer instead of accepting it is the first habit that moves you right on the spectrum.
Check your understanding: what vibe coding is (and isn't)
4 questions1.By Simon Willison's definition, what makes something vibe coding?
2.An agent wrote every line of your app. You read each change, tested it, and could explain how it works to a friend. Is that vibe coding in the strict sense?
3.Which project is the best fit for pure vibing, with no code review?
4.Where on the spectrum does this course place you when building DayBoard?
Practice
- Add a vibe check to your notes. Ask your agent to add a section called
## Vibe checktodayboard/SETUP-NOTES.md. It should be a three-row table (throwaway prototype, personal tool, app with users), with one DayBoard example per row and the review level that fits. Read the table before you accept it. Does the "app with users" row mention other people's data? - Save the agent's answer. Paste the agent's answer from the "Do it now" step into the same section. Underneath, write one sentence of your own on anything it missed or got wrong.
- Start your build journal. Create
dayboard/JOURNAL.md, the build journal you'll add to throughout the course, and write a first dated entry: one line on where you'd put your own app idea on the spectrum, and why. - Stretch: read Willison's full post (linked below). Find one of his "when is it OK" points that this lesson didn't cover in depth, and note how it might apply to DayBoard.
Sources
- Andrej Karpathy — the post that coined "vibe coding" (2 Feb 2025)
- Andrej Karpathy — one-year retrospective proposing "agentic engineering" (4 Feb 2026)
- Collins Dictionary — Collins' Word of the Year 2025: AI meets authenticity as society shifts (6 Nov 2025)
- Simon Willison — Not all AI-assisted programming is vibe coding (but vibe coding rocks) (19 Mar 2025)
- NIST NVD — CVE-2025-48757