Minimum vocabulary
If LLM, agent, MCP, and harness all sound like the same thing, you are not alone. Before vibe coding, align on the words the rest of this curriculum uses.
LLM (Large Language Model): a large language model. It predicts the next stretch of text from what it has read. Chatbots and coding agents usually run on LLMs underneath.
Model: the “brain” that generates text, code, or decisions. It is not the screen you type into. The same product can swap models without you noticing.
Inference: running the model to produce an answer. Training is a different story. In day-to-day product work, almost everything you see is inference.
Token: a chunk of text the model processes. Long words can become several tokens. Context windows and cost are usually measured in tokens.
Context: what the model “sees” in that turn: prompt, files, history, rules. More context helps; noisy context hurts.
Prompt: the request in natural language (or close to it). It can be short or a long brief.
System prompt: base instructions that shape model behavior before the user request. In products, it is often hidden.
Autocomplete: inline suggestions while you type. Great for speed, but it cannot make architecture decisions for you.
Code context: repository slices (open files, diffs, symbols) the tool attaches so the answer fits your code.
IDE: a development environment with editor, terminal, and integrations. With AI, the IDE becomes a surface where the agent edits beside you.
CLI: command-line interface. CLI agents read files, run commands, and change the repo directly in the terminal.
Agent: a program that pursues a goal in a loop: observe, act with tools, check, decide the next step. Different from a chat that only answers.
Coding agent (code agent): an agent specialized in software. It reads the repo, edits, tests, and iterates until the task passes validation.
MCP (Model Context Protocol): a standard for connecting models to tools and context sources in a structured way. Useful, but a connected tool without governance also widens the risk surface.
Harness: the environment around the model (instructions, tools, limits, validation). It turns “a model that answers” into “a system that operates”.
This site uses harness and SDD (Spec-Driven Development) practically, not as market dogma. Not every team uses these names. What matters is the pattern: a clear contract plus an environment that gives the agent rails.
Made an app via prompts. Now what?
You open Lovable, Bolt, v0, Replit Agent, or a similar platform. You type: “create an app to organize my study routine, with login, a dashboard, and a task list”. The tool thinks, installs things, generates screens, writes code, opens a preview, and suddenly it looks like software.
That moment is addictive because it feels like you skipped months of learning. And to be fair, there is real value there. For the first time, PMs, designers, founders, QAs, and junior devs can turn an idea into something clickable without starting with project setup, boilerplate, or terminal anxiety.
But this is the most important line in this lesson: preview is not production.
An app that opens in the browser can still have broken access rules, exposed secrets, fragile flows, unmaintainable code, odd dependencies, no tests, and an architecture that only works while the project is tiny.
What vibe coding is
Vibe coding means creating software by describing intent in natural language and letting AI generate a large part of the code. The term became popular after Andrej Karpathy described a way of programming where you follow the “vibe”, talk to the agent, accept changes, paste errors back, and let the code grow without manually writing every line.
Plain English version: you say what you want, AI tries to build it, you inspect the result, ask for changes, run it again. It is less “I write every line” and more “I direct the outcome”.
That is not automatically bad. Vibe coding is great for:
- getting an idea out of your head and onto the screen;
- creating clickable prototypes for user conversations;
- learning by reading generated code and asking for explanations;
- testing product flows before spending engineering sprint time;
- building simple internal or disposable tools.
If you do not understand the code, have not reviewed data access, have not tested permissions, and do not know how to roll back, you do not own the software yet. You have a prototype, and a prototype will not survive production.
Why it feels like it works so well
Because prototypes have a different bar. A prototype needs to show intent. It does not need to survive traffic, audits, payments, privacy requirements, fine-grained permissions, and two years of maintenance.
It also works because many apps repeat patterns: login screen, list, form, dashboard, CRUD, filters, sidebar, table. Models have seen a lot of similar code and can recombine those patterns quickly.
You do not need to wait until you “know everything” to play with product ideas. You can build, break, ask, compare, and learn in the loop. Just do not skip understanding. AI accelerates feedback. It does not replace fundamentals.
How this connects to the next lessons
In this lesson, you got the minimum vocabulary and saw where vibe coding shines and where it lies. Next:
- Lesson 2: Tools and models shows how to choose between AI IDEs, CLIs, cloud agents, and task-fit models.
- Lesson 3: SDD and Harness Design shows how to turn intent into a verifiable contract and operate agents with context, validation, and governance.