Explainer

What is vibe coding, really?

"Vibe coding" is one of those phrases that went from a single post to an industry term in about a month — Andrej Karpathy popularized it in early 2025 to describe a way of building software where you mostly describe what you want and let an AI model write and run the code. A year on, it's used for everything from weekend hacks to production work, which has muddied what it actually means. So here's the honest version: what vibe coding is, what it isn't, and how to do it without shipping a mess.

The actual definition

Vibe coding is coding by intent. Instead of writing each line yourself, you tell an agent the outcome you want in plain language, it generates and executes the code, you look at the result — not the source — and you refine by describing the next change. You stay in the loop on what should happen; the agent owns how it happens.

The biggest misconception

The loudest myth is that vibe coding is a beginner thing — a crutch for people who can't write the code themselves. That's wrong, and it matters. Describing intent instead of typing every line is a way of working, not a skill level. A first-timer uses it to ship something they couldn't have built alone; a staff engineer uses it to delegate the boring 80% and run three agents at once while reviewing the diffs. Same technique, different leverage.

What actually changes with experience isn't whether you vibe code — it's how much you let the agent explain versus how much it just does, and how closely you read what it ships. The skill is in knowing which parts you can wave through and which parts you have to check.

Where it shines, and where it bites

It's a great fit when the cost of a wrong line is low and you can see the result quickly:

• Prototypes and one-offs — scripts, scrapers, internal tools, throwaway UIs.
• Boilerplate and glue — wiring, migrations, test scaffolding, the stuff you've written a hundred times.
• Unfamiliar stacks — a language or framework you don't know well, where the agent's defaults beat your guesses.

It bites when you can't easily evaluate the output:

• Security- and money-critical paths — auth, payments, anything where a subtle bug is expensive.
• Code you can't read — if you can't tell good output from plausible-looking-but-wrong output, the loop has no brake.
• Large, tangled changes — the bigger the diff, the harder it is to judge, so keep steps small.

How to vibe code well

The difference between "it shipped" and "it shipped something I regret" is a few habits:

• Keep a tight loop. Small asks, frequent runs, look at the result each time. Don't hand it a ten-part task and walk away.
• Stay in version control. A clean git tree means you can always git diff what changed and undo it.
• Protect your secrets. Make sure the agent can't touch your .env or keys — the things that shouldn't end up in an edit or a log.
• Match the explanation to your level. If you're learning, make it explain; if you're delegating, let it just go.
• Don't lose track of it. Agents run for minutes and stop to ask permission — so you want to know the moment one needs you instead of watching a terminal.

Where Backgrind fits

Backgrind is built around that last habit. It runs your coding agent — your own Claude Code or Cursor, or Grindy, our hosted model — in an always-on-top overlay, with a vibe code mode that hides the source, runs hands-off, and protects your dotfiles, plus a coding-level setting that dials how much it explains. It flashes and chimes only when the agent needs a decision or finishes, so you can describe a task and get back to your day instead of babysitting the terminal. There's a live demo if you want to see the loop in motion.