Vibe Coding for Beginners: From Zero to a Working App

Vibe coding is building software by describing it to an AI assistant, running what it produces, describing what is wrong, and repeating — without reading most of the code. For a small personal tool it works, and it is the fastest a beginner has ever been able to go from idea to something running. It also has a hard ceiling that arrives sooner than the enthusiasm suggests. This guide gets you to a working app and shows you where the ceiling is before you hit it.

What it is good for#

• Personal tools nobody else will run: a habit tracker, a script that renames files, a page that calculates something for you.
• Prototypes: something to look at and click through before deciding whether to build it properly.
• Learning what is possible: seeing how an app is structured before you could write one.

It is not good for anything that holds other people’s data, takes payments, or has to keep working for years. Those need someone who understands the code, and the whole premise here is that you do not, yet.

Pick the right first project#

Small, single-purpose, visible. Good first projects:

• A web page that converts units, with a nice layout.
• A daily journal that saves to the browser.
• A countdown to a date, with a background that changes.
• A script that sorts your Downloads folder by file type.

Bad first projects: anything with user accounts, anything that needs a database server, anything described as “like X but better”. The assistant will happily start those; you will not be able to finish them.

The loop#

1. Describe the app in a paragraph: what it does, what it looks like, what happens when you click things. Specify the technology only if you have a reason; otherwise ask for “a single HTML file with the JavaScript and CSS inside it”, which is the easiest thing to run.
2. Run it. Open the file in a browser, or run the script. Do not skip this to ask for more features.
3. Report exactly what happened, in the words a user would use: “the Add button does nothing”, “the total shows NaN”, “the layout breaks on my phone”. Paste any error from the browser console.
4. Repeat, one change at a time.

A single-page web app in one HTML file. A text box and an Add button.
When I add an item it appears in a list below with a checkbox and a delete button.
Checking the box crosses the item out. Items are saved so they are still there
when I reload. Clean, simple design, works on a phone.

That description produces a working app from any current assistant. Notice it says what happens, not how.

Descriptions that work#

• One feature per request once the first version exists. “Add a filter for completed items” beats a list of five changes, because when one breaks you know which.
• Describe behaviour, not code. You are the user; let the assistant be the programmer.
• Paste errors verbatim. The exact text of an error is worth more than any description of it.
• Say what you tried. “I clicked Add with an empty box and it added a blank item” is a bug report the assistant can act on.
• Ask for the whole file when the app is small. Partial edits you have to place yourself are where beginners break things.

Where it stops working#

Around the tenth feature, or the second file, something changes. The assistant starts breaking things it fixed earlier. A change in one place causes an error somewhere else. You paste the error, it fixes that, and a different error appears. This is the ceiling, and it arrives because the app has become larger than can be reasoned about from descriptions alone. Nobody — not you, not the assistant — is holding the whole structure in mind.

Signs you have reached it:

• Fixes that undo previous fixes.
• You cannot describe what a change should do without describing the code.
• The file has grown past a few hundred lines and you have never read it.
• “It worked yesterday” and you do not know what changed.

Three habits that raise the ceiling#

Read the code, a little. Ask the assistant to explain the file in plain words, section by section. You do not need to write it; you need to know roughly where things are, so your bug reports can say “the part that saves items” instead of “somewhere”.

Ask for structure early. Once the app works, ask it to “reorganise into clearly named functions with a comment on each”. Then keep it that way. Structured code survives many more changes than a single tangled block.

Learn one thing per session. Each time the assistant explains a fix, ask why. Over a few weeks you stop being a pure vibe coder, which is the point: the people who get the most out of these tools are the ones who can read what they produce.

Choosing a tool#

Any of the current assistants works for this. A chat interface where you paste code back and forth is enough for a single file. An editor-integrated tool such as Cursor, or a terminal agent such as Claude Code or Codex, handles multi-file projects and runs things for you, at the cost of more setup. Start with chat and a single HTML file; move to a proper tool when the project needs more than one file.

Where to go next#

• How to check AI-generated code — the reading habit, in detail.
• Common problems with AI-generated code — what to look for.
• Git and GitHub explained — the three commands that save you.