Where to start
A short orientation: what this is, what you need on day one, and which part of Vibeset to go to at each point. Pick your level and keep what is yours.
Your level
- I have never written code You are going to build something this week without understanding everything under the hood, and that is fine: you learn that part later, by building.
- I have dabbled You can find your way around files and you have copied code off the internet. What you are missing is not syntax, it is the working loop with an agent.
- I already code What changes is not the code, it is your job: you go from writing it to deciding it, reviewing it and testing it. Skip the basics and stay for the loop and where it breaks.
What vibe coding actually is
Building by describing what you want, and letting a model write the code. What it is not: giving up on knowing things. It is knowing different things, and those things are everything below: what you ask for, how you check it does what you said, and where you look when it does not.
The agent never says "I do not know". It says something with total confidence, and sometimes it is wrong. That is the one rule you actually have to internalize.
What you need on day one
Somewhere to write with an agent inside it, an account, and a folder for your project. That is all. You do not need to buy anything to start, install ten things, or pick right the first time: switching tools later costs you an afternoon.
Pick one and stay with it for a week. Trying five on day one is the fastest way to never start any of them.
The words everyone uses without explaining them
These are not hard concepts, they are vocabulary. With these you can follow almost any answer an agent gives you.
- Repository Your project folder, but with a memory: it saves every change and lets you go back. Everyone says "repo".
- Commit A snapshot of your project at one moment, with a line saying what you changed. It is the point you can return to when something breaks.
- Terminal The black window where you type commands instead of clicking buttons. Scary for three days, then faster than the mouse.
- Dependency Code written by someone else that your project uses. Saves you months and brings their problems into your house.
- Deploy Putting what you built somewhere the rest of the world can open it. These days it is usually free and usually takes a minute.
- Branch A separate line of work, so you can change things without breaking what already works. When it goes well, you merge it back.
- Framework A ready-made skeleton you build on, with the boring decisions already made. It saves you weeks and ties you to its way of doing things.
- API The door one program uses to talk to another. When something "connects to" something else, this is almost always how.
- Local and production Local is your machine, where you can break things. Production is where people see it. Working on the first guarantees nothing about the second.
The vocabulary of agents
This craft is three years old and already has its own jargon. Nobody knows it from having programmed a lot before, so here it is in full and with no mystery.
- Model The engine that writes the text. On its own it does not remember yesterday's conversation and cannot touch your files: it only generates what comes next after what is already there.
- Client The program you actually talk to: a chat app, an editor extension, a terminal window. It provides the interface and keeps the conversation.
- Harness The layer that wraps the model and gives it hands: it offers the tools, runs what the model asks for, hands back the result and decides when to stop. It is what turns a model that only writes into an agent that works.
- Agent Model plus harness plus tools, looping until the job is done. The word does not describe a technology, it describes that assembly.
- Tool Each concrete thing the harness lets it do: read a file, run a command, search the web. The model asks, the harness runs it and reports back.
- Context Everything it has in front of it right now: your messages, the files it has read, and what the commands returned. Outside of that, as far as it is concerned, nothing exists.
- Context window How much fits in that "in front of it". When it fills up, the old stuff gets summarized or falls off, which is why a very long conversation starts forgetting things you said at the beginning.
- Token The unit text is cut into so it can be counted and billed. Not letters, not words: pieces of words. It is the currency of all this.
- System prompt The fixed instructions the model gets before you, and that you never see. They set how it behaves by default.
- MCP A standard for plugging in outside tools (your database, your task tracker, a browser) without waiting for your client to ship them.
- Skill A manual the agent reads when that topic comes up, instead of you explaining it again. There is a whole section of them here.
- Hallucination When it invents something with total confidence: a function that does not exist, a fact it never checked. It is not a rare breakdown, it is a side effect of how it works, and it is why you check everything.
How to ask an agent for something
A good request has three parts: what you want, what to build it with, and the specific trap that anyone who does not name it walks into. The first two are easy; the third is what separates a result that works from one that looks like it works.
Tell it the why as well. An agent that knows what something is for makes better calls on the ten details you did not mention.
Your rules and your structure, written down once
An agent starts every conversation from scratch: it does not remember what you two decided yesterday. If you explain how you like things in every chat, you pay that toll daily and the result changes from day to day. You fix it by writing it once in a file at the root of the project that the agent reads before it works: AGENTS.md is the standard name and nearly every tool reads it already.
Structure does the same job without you writing anything: an agent decides where a new file goes by looking at where the others are. In a tidy project it gets it right; in a messy one it adds to the mess, and every request makes it slightly worse.
Short, checkable rules. "Copy lives in `src/i18n`, never inside the component" works; "write quality code" says nothing. And when you have to correct the same thing twice, that correction is already a rule: write it down instead of saying it again.
The loop: ask, look, fix
Ask for one small thing, run it and look at the screen, and only then ask for the next one. Compiling does not mean it does what you asked, and "it should work" is not "it works". This loop is the whole job, and skipping it leaves you with two hundred lines nobody has ever seen run.
- One change at a time, tested before you ask for the next. Slower for the first hour and faster for the rest of the day, because when something breaks you know exactly what broke it.
- Save before asking for anything big. A commit is your undo button: without it, "put it back how it was" is a conversation instead of a command.
- Tell it what not to touch. With no fences, an agent rewrites half the screen to fix one button.
- Read what changed before you accept it. If it is too big to read, the problem was the request, not the change.
- If something fails the same way twice, stop tweaking details. By the third try the problem is not your line of code: it is the approach, the library or the tool. Change roads, not decimals.
- Whatever you have to correct twice, write into your rules. Whatever you do by hand three times, automate.
Ask in small pieces. A huge request gives you a huge change you cannot review, and reviewing it is your side of the deal.
Where this breaks
The expensive mistakes here are not about syntax, they are about trust. These four cause almost every disaster: accepting changes without reading them, leaving a key written inside the code, pulling in dependencies nobody has looked at, and not using version control, which is working without a net and no way back.
A key that reaches a public repository is stolen even if you delete it a minute later: it stays in the history and there are bots hunting for them. You rotate it, you do not hide it.
What you write it in
With an agent in front of you the language matters less than it used to: you are not going to type most of it. But it still decides where your thing runs, which libraries you have at hand, and who can help you when you get stuck.
When you want it to show
Everything above gets you building. This part is what separates a site that works from one you actually enjoy using: techniques you know how to ask for, pieces you can copy, and manuals your agent reads so it gets it right without you explaining every time.
And that is it. The rest you learn by building, and the catalog is what you will need along the way.