Vibe coding for people who never wrote code: where to start
Vibe coding for beginners: what you can build in one evening without coding, a first project in Claude Code step by step, and the usual failure modes.
Vibe coding sounds like magic and turns out to be boring mechanics: you describe the task in plain words, the AI writes the code and runs it, you look at the result and say what's wrong. The code is real and sits in files on your machine, you're just not the one typing.
What it actually is
The unit of work is a description, and the typing is somebody else's job. You say "build a page where I paste a bank export and it shows spending by category" instead of writing a CSV parser.
The responsibility stays with you. The AI always sounds confident, including when it's wrong. Only the person holding the goal can tell whether the result is right, and that's you.
Mistakes are cheap while the project is small. A bad attempt costs nothing to throw away, so keep the first project small.
Vibe coding for beginners: what you need to start
Claude Code works directly with files on your computer: it reads, edits, runs commands. Per Anthropic's official documentation it requires a paid account: Pro, Max, Team, Enterprise, or Console. The free claude.ai plan doesn't include Claude Code access.
Check the second condition before you pay: Claude has to be available where you live. That's a documented requirement like the OS version, Anthropic doesn't support every country, and the list sits at anthropic.com/supported-countries.
The rest is modest: macOS 13.0+, Windows 10 1809+, or Ubuntu 20.04+, 4 GB of RAM, internet.
Desktop app. Download Claude for macOS or Windows (the Linux build is still in beta and installs via apt or a .deb on Ubuntu and Debian), open the Code tab, pick the Local environment, click Select folder, and choose your project. No terminal, and the default is Manual mode: Claude shows a diff of what it wants to change and you click Accept or Reject.
Terminal. One command. On macOS, Linux, WSL:
``
curl -fsSL https://claude.ai/install.sh | bash
``
Windows PowerShell:
``
irm https://claude.ai/install.ps1 | iex
``
claude --version prints a version number followed by (Claude Code), so you know it worked. Then open your project folder and type claude; the first run sends you to a browser login. If something behaves oddly, claude doctor prints install diagnostics without starting a session.
There are no Accept and Reject buttons in the terminal, but the confirmation still happens: by default Claude Code asks permission before editing a file or running a command, and Shift+Tab cycles the modes (manual, auto-accept edits, plan). In the rename-400-files story, that prompt is all that stands between you and a wiped folder.
If the command line makes you nervous, start with the app: same engine, just with buttons. More: Claude Code without coding.
What you can build without coding in an evening, and what you cannot
| Realistic in one evening | Not in one evening |
|---|---|
| A small app for yourself: a calculator page, a form with a summary | A service that takes card payments and handles refunds |
| A landing page with no payments and no accounts | User accounts, roles, access rules |
| A script: rename 400 files, roll ten CSVs into one summary | Storing customers' personal data |
| A prototype to show the team what you mean | Anything that must live and be maintained for years |
The line is drawn by the cost of a mistake, not by code complexity. While a mistake costs ten minutes of your time, this works fine. Once it costs a customer's money or a data leak, you need an engineer who owns the result.
Your first project, step by step
1. Pick a task with a checkable result
A good first task is phrased so you know when it's done. "A page where I paste a brief and get three headlines" is verifiable in a minute, "automate marketing" never is.
2. Write it up like a tiny spec
Forget "make it nice". Spell out: what goes in, what comes out, what happens on empty input, where I'll open it. The official guidance is blunt: the more precise the instruction, the fewer corrections later. And give Claude a way to check itself, a test or a screenshot, otherwise "looks done" is the only signal you'll get. In full:
``
Build an index.html page that opens locally in a browser.
Input: I drag a bank CSV onto it, columns are date, description, amount.
Output: a category and total table, plus the grand total for the period.
Match categories by keywords in the description, put the rule list at the top of the file.
Empty file or wrong columns: show an error message, the page must not crash.
Verification: generate a 20-row test CSV, compute the total in a comment, and compare with the page.
``
That takes a minute and saves an hour of back and forth. If phrasing is the hard part, fix the prompt first.
3. Plan before code
Claude Code has a planning mode where it proposes an approach without editing files. In the app it's the Plan permission mode; in the terminal, the same Shift+Tab. Read the plan, argue, adjust, and only then let it build.
4. Small steps, verified one at a time
One step equals one change you can check with your own eyes. Make it, open it, click around, confirm it works, then ask for the next. Six changes in a row end with something broken in the middle and no way to tell where.
5. Give the project a memory
The /init command creates a CLAUDE.md file Claude reads at the start of every conversation: how to run things, what not to touch. Keep it short, a bloated file gets ignored.
6. Clean up after yourself
Run /clear between unrelated tasks to start on empty context. A long but still useful conversation gets summarized by /compact.
Three real examples
A report. A bank export in CSV plus half an hour of manual sorting every week turns into a page showing totals by category. Verify on last month, where you know the answer.
A landing page. The copy is written, so you ask for a one-pager on your structure, then open it on your phone and fix what shifted.
A chore. 400 files with messy names and a script that renames them by a rule, on a copy of the folder always.
Common failures and what to check by hand
The AI confidently breaks what already worked. The classic: you ask for one button fix and half the page gets rewritten. The cure is small steps plus undo. Every prompt creates a checkpoint; /rewind, or Esc twice on an empty input box, restores code, conversation, or both.
Don't trust undo blindly. The docs list the limits: checkpoints don't track file changes made by bash commands, don't restore edits applied by subagents, and usually don't capture edits you made outside the session (those show up only when they touch the same files). This is local undo, not version history. Hence the rule about copies: before a big rework, duplicate the folder with a date in its name, or ask for a git commit.
"Done" with no evidence. The docs call this one out directly: a plausible-looking implementation nobody checked. Ask for proof: the test output, the exact command and what it returned, a screenshot.
Correction loops. You fix it, it's still wrong, you fix it again, it gets worse. Working rule: if two fixes in a row didn't help, run /clear and start over with a sharper prompt.
Before calling the evening a success:
- Walk the whole flow yourself, don't trust the summary.
- Check it on a phone if it's a page.
- Feed it bad input: an empty field, text where a number goes, a wrong file type.
- Confirm the originals are intact and the work happened on a copy.
Honest limits
Money and data. Payments, personal data, user access. A slip here lands as an incident: a customer's money, a fine, a call with lawyers.
Reliability under load. What works for you alone and what holds a hundred people are built differently.
Long life. Code nobody understands becomes a problem in six months. If people use it daily, someone who reads code should look at it.
The workable strategy: build internal tools and prototypes yourself, then come to an engineer for the paid public product, prototype in hand. This path won't suit people who won't verify by hand (the result will look plausible and lie), people expecting production on evening one, or people with nothing to automate.
The short version
Describe the task in words, give it a way to verify the result, move in small steps, keep copies, and never treat "looks done" as done. An evening buys internal tools, landing pages, and routine automation; money, personal data, and load stay engineer territory.
At AGINE Academy this is a dedicated part of the program: a game-style online academy for Claude, 81 lessons, 12 blocks, 7 tracks, missions inside real Claude, and every lesson ends with something that works. The program goes all the way to Claude Code and shipping your own products, no technical background required. The first four lessons are open with no signup.
See also
Questions
You describe the task in ordinary words, the AI writes the code, runs it, and shows you the result. You look, say what's wrong, it fixes. The code is real and lives in files on your machine, you're just not the one typing it. Verifying the result stays a human job.
Yes, and the plan alone isn't enough. Per the official documentation, Claude Code requires a Pro, Max, Team, Enterprise, or Console account, and the free claude.ai plan doesn't include access. The second requirement is location: Claude has to be available in your country, and Anthropic keeps the current list at anthropic.com/supported-countries. Check both before you pay. The install itself is one command, covered in the getting-started section.
An internal tool for yourself (a calculator page, a form that rolls entries into a summary), a landing page with no payments or accounts, and small scripts for chores like renaming hundreds of files or turning CSVs into a report. One condition: you verify by hand after every step, otherwise the evening goes into something that looks plausible and doesn't work. What doesn't fit in an evening: anything with payments, user logins, or stored personal data, where the cost of a mistake is completely different.
Every prompt in Claude Code creates a checkpoint: run /rewind, or press Esc twice with an empty input box, to restore code, conversation, or both. Checkpoints don't track file changes made by bash commands, don't restore edits applied by subagents, and usually don't capture edits you made outside the session, so before a big rework keep a copy of the folder or ask Claude to make a git commit.
Yes. The Claude desktop app for macOS and Windows (the Linux build is still in beta) has a Code tab: pick the Local environment, click Select folder, and choose your project. It starts in Manual mode, where Claude shows a diff and waits for you to click Accept or Reject, so no file changes without your approval.