Guide

Your first vibe coding project, start to ship

Andrew Mercer June 15, 2026 · 7 min read

Most people's first vibe coding session dies the same way: they open the agent, type a huge ambitious prompt, watch it generate a wall of files, can't tell what's right, lose the thread, and quietly close the window. The tool wasn't the problem. The scope was. Vibe coding rewards small, finishable ideas and punishes big vague ones, and almost nobody tells you that on day one.

So here's the honest walkthrough — the actual sequence that gets a first project from "idea" to "it runs, and I shipped it." None of it is hard. The trick is doing the boring setup steps before you type a single instruction, then keeping every step after that small enough to judge.

The outer path is once-per-project; the dashed inner loop — one small change, run, check — is where you'll spend most of your time.

Step 1: pick something almost embarrassingly small

Your first project is not the place for "an app." It's the place for one self-contained thing you can describe in a sentence and finish in an afternoon. The test: can you say what "done" looks like before you start? Good first ideas:

A CLI tool — a script that renames files in a folder, converts a CSV to JSON, or pulls today's weather and prints it.
A one-page site — a personal landing page, a countdown timer, a tiny calculator that does one calculation.
A small automation — a script that backs up a folder, or watches a directory and sorts new files by type.

Notice what these have in common: you can see whether they work in seconds. That's the real selection rule. Vibe coding works because you judge the result instead of reading every line, so pick something whose result is obvious. If you can't tell good output from plausible-but-wrong output, the loop has no brake — more on that in what vibe coding actually is.

Step 2: make a folder and run git init first

Before the agent touches anything, give it a clean room with an undo button. Make a folder, move into it, and initialize a repo:

mkdir my-first-thing
cd my-first-thing
git init

Then open the agent inside that folder. Git is not optional here, and it's not just for "real" projects. It's your safety net. When the agent makes a change you don't like — and it will, a few times — git diff shows you exactly what changed, and git checkout . throws it away. Commit every time something works, even something tiny. A clean working tree before each new instruction means every step is reversible, which is what lets you move fast without fear.

If you haven't installed an agent yet, the quickest paths are installing Claude Code or the Cursor CLI — both are roughly a single command and a sign-in.

Step 3: give it the goal in plain words

Now describe what you want — the outcome, not the implementation. You don't need to know the framework or the file names. Say what "done" looks like and let the agent pick the how:

Build a command-line tool in Python that takes a folder path
and renames every image in it to the date it was taken.
Print what it renamed. Don't touch files that aren't images.

That's a good first prompt because it names the goal, the output ("print what it renamed"), and a guardrail ("don't touch files that aren't images"). You'll get better at this fast. A few habits that help from day one:

One outcome per prompt. "Build the renamer" is a task. "Build the renamer and add a web UI and package it" is three tasks pretending to be one.
Say what you don't want. Guardrails ("no external libraries," "keep it in one file") save you from cleanup later.
Ask it to run the thing. Tell the agent to actually execute the script on a test folder so you both see it work, not just that it compiled.

Most agents ask before editing files or running commands the first few times, so you approve each step until you trust it. If you're unsure whether to let it plan before it builds, the trade-off is worth a read: build mode vs plan mode.

Step 4: iterate in small steps

This is the part that separates "it shipped" from "it shipped a mess." Resist the urge to pile on. After the first version runs, change one thing, run it, look at the result, then change the next thing:

Run after every change. If something breaks, you know exactly which change broke it because it's the only thing that changed.
Commit the moment it works. Each working state becomes a checkpoint you can return to.
Keep diffs readable. The bigger the change, the harder it is to judge — and judging the result is your whole job in this loop.

When the agent goes sideways — wrong approach, weird dependency, a fix that breaks two other things — don't fight it across ten messages. Roll back to your last good commit and re-describe the goal more clearly. A clean restart from a known-good state beats debugging a tangle you didn't write. This is also where running more than one agent at once starts to make sense later, but for your first project, one is plenty.

Step 5: keep secrets and .env out of it

The one thing you must get right before you push anything public: keep credentials out of the repo. If your project needs an API key, put it in a .env file and make sure git ignores it. Add a .gitignore before your first commit:

.env
.env.local
node_modules/
*.key

Then sanity-check that git is actually ignoring it with git status — your .env should not appear in the list of files to commit. This matters more with an agent in the loop than without one: an agent can read, edit, and sometimes echo file contents into its output, so a key sitting loose in the working directory is a key that can end up in a log or a commit you didn't scrutinize. Be explicit with it — tell the agent your secrets live in .env and it should never print or commit them. Protecting those files is exactly the kind of guardrail that should be on by default, not something you remember at the end.

Step 6: ship it

"Ship" is smaller than it sounds. For a first project it might just mean: it runs, you committed it, and you pushed it to a repo so it exists somewhere other than your laptop. Create a repo on your host of choice, then:

git add .
git commit -m "first working version"
git push

That's a finished project. Not impressive, not large — finished. Which is the entire goal of a first project. You learned the loop, you have something that runs, and the next idea will be a little less embarrassing. The honest pitfall to expect: your first project will take longer than you think and feel messier than you'd like, and that's normal. The loop gets smooth around the third or fourth thing you build, not the first.

Where Backgrind fits

The slow part of that whole loop is the waiting — the agent runs for a minute or two, stops to ask permission, finishes while you've tabbed away. Backgrind runs your agent — your own Claude Code or Cursor, or Grindy, our hosted model — in an always-on-top overlay with a vibe code mode that protects your dotfiles and keeps your .env off-limits, so you can describe a step, get back to whatever you were doing, and let it flash you when it needs a decision instead of babysitting the terminal. There's a live demo if you want to see the loop running.