Vibe Coding With Cursor: A Practical Guide

Vibe coding is building software by conversation: you describe the outcome, an AI agent writes the code, you run it, and you steer with follow-ups instead of editing the code yourself. Andrej Karpathy coined the term in early 2025, and Cursor's own help page adopts his framing: "describe what you want in plain language, let an AI agent write the code, then run it and refine by feel."

The important part of the definition is what you don't do: read every line. That is what separates vibe coding from ordinary AI-assisted engineering, where the diff review is the job. It is also exactly why the approach has a ceiling. The trade is speed for understanding, and that trade is only safe when the stakes are low.

Cursor pitches vibe coding at people whose job is not writing code: designers, product managers and data scientists who need something working more than they need something maintainable. For that audience it removes the biggest barrier: you no longer need an engineer's time to test an idea.

The designer row is asking for more than it looks like. Handing over the idea instead of the repo means somebody rebuilds a thing that already runs, which is a hard sell while the prototype is demoing fine. Prototype code carries decisions nobody made on purpose. The agent chose a folder layout and a data shape while you were judging whether the screen felt right, and whoever inherits the repo reads all of that as intent.

Team size changes the calculus more than I expected. On a team of five, a vibe-coded internal tool can sit in near-daily use for months without hurting anyone, because whoever prompted it is two desks away and could rebuild it in an afternoon. At fifty it gets pasted into a channel, someone builds a weekly report on top of it, and it becomes infrastructure with no owner. Say the expiry date out loud when you share the link.

The loop is short: describe, run, react. Cursor gives you three features that make the loop tighter than a plain chat window.

1. 1Describe the outcome, not the implementation. Say what the tool should do, who uses it and what data it touches. Constraints beat instructions: "single page, no login, reads this CSV" steers better than framework names.
2. 2Run it immediately and react to what you see. The agent can run the app and iterate. Your feedback loop is the running product: say what looks wrong on screen, not what to change in the code.
3. 3Point at the interface with Design ModeA way to point at an element in Cursor's built-in browser and change it directly, instead of describing it in words. Press Enter for the full definition.. Instead of describing a button in prose, select the element and tell the agent what to change. Cursor applies the edit without you touching code.
4. 4Pull in real data with MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition.. MCP integrations connect services and data sources, so a prototype can demo against something real instead of lorem ipsum.
5. 5Let BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. catch what you can't see. A review agent that flags and fixes issues gives non-engineers a safety net that reading the diff would normally provide.

The sequence matters, though the list does not say why. Running it comes second because everything after that needs a running app to aim at.

Design ModeA way to point at an element in Cursor's built-in browser and change it directly, instead of describing it in words. Press Enter for the full definition. only does anything once your app is open in the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. browser (open the browser first, then ⌘/Ctrl+⇧+D toggles Design Mode), and real data is only informative once you can see where it lands. Wire up the data source first and you are debugging two unknowns at once, with no way to tell whether an empty table means a bad query or a component that never rendered.

You review the plan instead of the diff, judge the running app against something you can verify independently, and let BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. read the code you are not going to read. Cursor's help page points non-engineers at Bugbot for that last part. A clean run means nothing obvious was wrong in the diff it read.

My first instinct was to say read the diff anyway. That does not survive contact with this audience, since skimming a diff you cannot evaluate mostly buys false confidence, so read the plan instead. Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. reads like a tool for engineers scoping a refactor. What it hands you is a plan in markdown you can edit before anything is built, and Cursor's own list of cases for plan mode includes unclear requirements, where you have to explore before you know the scope. That is most prototypes.

For the running app, the useful check is the one where you already know the answer. Point the tool at last month's closed numbers, or a customer record you can recite, and see whether it agrees. Agent-written aggregations tend to fail quietly, since a dropped null returns a number that looks entirely plausible. Check the slice you can verify by hand first.

Cursor's help page is unusually blunt for vendor documentation: "We don't recommend shipping software you don't understand to production." The methodology excels where speed matters and stakes are low; production software still requires review, tests and engineering judgment.

• Real users or real data. The moment either shows up, unreviewed code is a liability: security, privacy and correctness all need eyes on the diff.
• Long-lived codebases. Vibe-coded layers accumulate contradictions nobody understands; maintenance is where the unread-code debt comes due.
• Anything regulated. Compliance reviews assume a human can explain the code. "The agent wrote it" is not an audit answer.
• Performance and scale. Feel-based iteration finds what looks right, not what holds up under load.

None of those four is how it falls over most often, though. The everyday version is smaller. Something works, you ask for one more feature, that breaks the working one, you ask the agent to fix it, and the fix breaks something else. Three rounds in, the app is worse than it was an hour ago and there is no version to go back to, because nobody committed anything. Long threads degrade past roughly half the context window as well.

Cursor's documented fix is to revert and re-plan, and it assumes there is a clean state to revert to. Three prompts deep with nothing committed, there is not one. Save the version that works before you ask for the next thing. Copying the whole folder into a dated backup counts as a save if git is not part of your day.

Vibe coding rewards the same fundamentals as every other Cursor surface: scoping, context and knowing which mode you are in. If you are starting from zero, the Cursor first hour track walks the setup and first change; writing good prompts covers the describe-and-constrain skill; and Ask vs Agent vs ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. explains which surface fits which job.

Improving also means diagnosing faster. When a prototype starts misbehaving, the first thing I check is whether the screen is showing current code at all. Changes appear in the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. browser as agents finish and the app hot reloads, so a page that looks identical after a supposedly successful edit usually means the edit went elsewhere, or the dev server fell over. After that, read the agent's own summary. The list of files it names tells you where to look, and "updated the mock data" explains a lot of otherwise mysterious behaviour.

There is a ceiling on prompting skill alone, and at some point the next improvement is reading the code. Not all of it. Mostly the one file the agent keeps returning to when something breaks.