Start here

Vibe coding means you describe what you want in ordinary language and an AI writes and changes the software. You stay responsible for the goal, the decisions, and the checking. It is not a shortcut past thinking. It is a shortcut past syntax.

What you need before you begin

Three things. You almost certainly have two of them already.

1. Something to talk to

   A general chat assistant is enough for your first weeks: ChatGPT, Claude, or whatever you already use. Tools that can see and edit your files (a coding agent) become more useful later, once you have a project worth editing. Do not begin by assembling a stack. The toolkit page is there for when you want more.

2. One folder for the project

   One folder per project, somewhere you can find it again, not mixed into your main documents. Everything the project needs lives inside it: notes, sample data, the code itself. Folder discipline sounds trivial and saves hours later.

3. A way to keep a history

   Git, in plain terms, remembers every version of the folder. It lets you look back, compare two versions, and go back to the one that worked when a change makes things worse. GitHub is where a copy can live online. If this is new to you, ask your AI to set it up and explain each command as it goes. That is a legitimate way to learn it.

The workshop's practical rule still applies: start with one hosted model, one place to work, and one revision-control habit. Add complexity only when it earns its place.

Your first session, step by step

1. Pick a problem you already have

   Small, low stakes, and not sensitive. Good first problems: a form you fill in on your phone and lose; a spreadsheet you rebuild every month; a list you keep emailing to yourself; notes you take all season and can never find again. If the problem is not real, you will not care enough to finish, and you will not know whether the result is any good.

2. Write the goal in one sentence

   In your own words, before you type anything into an AI. For example: "I want one page where I can type a field note and see every note I have saved for that field." If you cannot say it in a sentence, the thing is still two or three things.

3. Ask for a plan before you ask for code

   This is the single most useful habit on the page. You are checking that the goal was understood, not testing whether the AI knows how to write code.

   A first message that worksI want to build a small tool: a single page where I can type a note about a field and see every note I have saved for that field. Plan it first. Do not write any code yet. Ask me anything that is unclear about what I actually need. Keep the plan to the smallest version that would be useful to me, and tell me what that version will not do.

4. Ask for the smallest version that works

   One file, one screen, no accounts, no database, no design work. Oversized first builds are the main reason beginners stall: there is too much to understand and no moment where anything works.

   ThenNow build the smallest version of that plan. One file if you can. No accounts, no database, no styling beyond what is readable. Tell me how to run it.

5. Run it yourself, with your own input

   Not a screenshot, not a description of what it would do if you ran it. You type something real and you look at the result. This is where most of the learning happens, and it is the step people skip when they are in a hurry.

6. Say what is wrong, specifically

   "It works, but the notes are not sorted, and I cannot see which field they belong to." Specific corrections teach the tool what you mean. "It does not work" gives it nothing to work with, and you will get a guess back.

7. Write one line before you stop

   What you tried, what happened, what you will do next. One line, in a file in the project folder. It takes twenty seconds and it is the reason tomorrow can start without re-reading anything.

Two habits to build now, while the project is small

Save every version that works

Save the moment something works, before you ask for the next change. Then when a later change breaks it, you have somewhere to go back to. This is what version control is for, and the habit matters more than the tool. Ask your AI to walk you through saving a version the first time.

Keep the notes with the project

A README file with five lines: what this is, how to run it, what it does not do yet, what you tried and abandoned, what is next. When you come back in a fortnight you will have forgotten why you made half your decisions, and the README is cheaper than re-deciding.

Three first projects

Each small enough for one or two sessions. Pick the one attached to a real annoyance.

• A note keeper

  Type a note, see all your notes, search them by word. Nothing leaves your computer.

  Good for: field notes, meeting notes, ideas you lose

• A checklist from a document

  Paste a policy, a regulation, or a long email, and get back a short checklist of what you have to do.

  Good for: programs, applications, compliance work

• A single number, tracked

  One page where you record one number a day and see it as a line. Rain, price, weight, hours.

  Good for: building the habit of looking at your own data

The honest part

The first session rarely ends with a finished tool. It usually ends with something small, slightly broken, that you understand much better than you did an hour ago. That is the normal shape of this work. The next page is about why, and about the rest of what the first weeks are like: What to expect.