Cursor Vibe Coding: A Practical Setup

Cursor suits vibe coding if you are willing to glance at the code: it is a full editor with an agent, so you describe a change, watch the diff and accept or reject it file by file. Plans run from $8 to $200 a month. Start with Plan mode, a rules file and Git. Facts checked 31 October 2026.

What Cursor is, in one paragraph

The Cursor docs call it a coding agent for building ambitious software. It began as an editor with AI in it, and the current docs describe three surfaces that share the same ideas: the desktop app, a command-line tool and cloud agents that run in isolated virtual machines. For vibe coding, the desktop app is where you will spend your time. It has Agent and Chat, a Plan mode, a debug mode and a browser tool. Our Cursor page has the full fact sheet, and the pricing page the plan details.

Why people vibe code in Cursor

The trade-off is the mirror image of the strengths. Cursor shows you code, so someone who never wants to see code may prefer a hosted builder. Our best vibe coding tools page sorts those options by who is building.

Plans, and what each buys

Cursor is now sold as part of the X Subscription, one subscription covering Grok, Cursor and X. The pricing page says subscriptions are sold only directly through X Subscription Corp, with no authorized resellers.

Teams run $30, $100 or $200 per seat. The older Pro at $20, Pro+ at $60 and Teams at $40 and $120 are labelled legacy on the pricing page, so you may still see those numbers in older articles.

The practical point for vibe coders: Plus is a cheap way to try the editor, but it limits you to Cursor's own models. If you want to pick Claude or GPT models, you need Premium or above, and those models bill at API list price from a prepaid credit rather than from a flat allowance. Check what you will actually run before buying, and see AI coding agent pricing compared for the other tools' meters.

Install and first run

Download the desktop app from cursor.com/downloads, sign in, open a folder and start with a small task. The quickstart lists macOS 12 or later on Apple Silicon or Intel, Windows 10 or later, and Debian, Ubuntu, RHEL and Fedora repositories on Linux.

For the terminal, the CLI installs with a one-line script and runs as agent, not cursor.

# macOS, Linux, WSL
curl https://cursor.com/install -fsS | bash

agent --version
agent "add a dark mode toggle to the settings page"

If agent is not found, add ~/.local/bin to your PATH. Read an install script before you run it, as with any script piped to a shell.

A vibe coding workflow that holds up

1. Start with Git

Before the first prompt, put the folder under Git and commit. Cursor edits many files quickly, and Git is how you step back.

git init
git add .
git commit -m "Empty project"

2. Write the idea in a paragraph

State who uses the app, what they do, and what done looks like. A model with a clear target needs fewer corrections.

3. Use Plan mode for anything bigger than a tweak

Plan mode has the agent study the project and propose a plan before it edits. Read the plan. Fixing a wrong approach in a paragraph costs almost nothing, and fixing it after twenty files have changed costs a lot.

4. Ask for the smallest working version

"Build a page with a form that takes a name and an email and shows a confirmation. Nothing else." Then open it and click through.

5. Commit after every working step

Make the commit message plain: "Add signup form". If the next prompt wrecks things, you return to the last good state.

6. Change one thing per prompt

Small prompts give small diffs. A small diff is easy to read, and reading diffs is the habit that separates a safe vibe coding session from a reckless one.

7. Read the diff for risky files

You do not need to read everything. Do read anything that touches sign-in, payments, database queries or environment files. Ask the agent to explain a change you do not follow.

8. Ask for a check, not a promise

"Run the tests and show me the output" beats "make sure it works". If there are no tests, ask it to write three, then run them.

Prompts that work in Cursor

Cursor's agent reads your files, so prompts can be short, but they still need a target.

A feature. "Add a notes page. A signed-in user can add a note, see their own notes in a list and delete one. Use the existing layout. Do not change the sign-in code."

A bug. "On the notes page, deleting the last note leaves the list blank with no message. Show 'No notes yet' instead. Here is the console error: [paste the exact text]."

A review. "Read the diff of my last commit. List anything that could fail with empty input, long text or a user who is not signed in. Do not change any files yet."

A plan. Switch to Plan mode and ask: "Plan a change that adds email reminders. List the files you would touch, the new settings, and the risks."

Each prompt names the user, the finish line and what must not change. That is the pattern to copy. If the agent drifts, do not argue with it for ten messages. Revert to your last commit and re-ask with the missing constraint.

A worked session, with example numbers

Say you are building a small notes app. Here is how a first evening might look, with the counts labelled as an example.

Six commits in an evening means five places to go back to. Without that habit, one bad prompt at step four could mean starting over. With it, you lose ten minutes.

When to stop prompting and read the code

Vibe coding has a natural ceiling. When you notice any of these, slow down and read the files.

• The same bug comes back after three different fixes.
• A prompt for a small change produces a large diff.
• The app works, but you cannot say where the data is stored.
• Sign-in, payments or user data are involved and you have not seen the code that handles them.
• The agent suggests installing a package you have never heard of.

Reading code is a skill, and an editor is a good place to learn it, because you can ask the agent to explain any line you do not understand. Ten minutes of reading at the right moment saves hours of confused prompting later.

Rules: teach Cursor your project once

Cursor gives the agent standing instructions in four ways.

For a first project, a short AGENTS.md is the simplest choice, because other tools read it too. See how to write a good AGENTS.md.

# AGENTS.md

## Commands
- Run the app: `npm run dev`
- Run tests: `npm test`

## Rules
- Make one change at a time and say which files you touched
- Never put secret keys in front-end code
- Do not edit `.env` files

Keep it short. A few rules you maintain beat a long file nobody reads.

Extend it with MCP

Cursor supports MCP over stdio, SSE and streamable HTTP, and you configure servers on the Customize page or in mcp.json. For vibe coding, two kinds of server pay off. A browser server such as Playwright MCP lets the agent open your app and check that it works. A docs server such as Context7 keeps it from guessing at a library's current API. Add servers one at a time, and remove any you stop using. Our Cursor and Supabase stack shows a database pairing. Cursor's MCP docs state no plan restriction, but check your plan before you rely on it.

Safety and privacy

An agent in your editor can change files and run commands. Three habits keep that safe. Keep secrets out of chat and out of the repository. Review a diff before you accept anything that touches authentication or money. And check Privacy Mode: Cursor's security page says that with Privacy Mode enabled it will not train on your data, and that Privacy Mode is available to anyone and can be set by a team admin. Some models need data-retention approval when Privacy Mode is on, per the models docs, so read the note beside a model before you pick it for private code.

For the full pre-launch check on whatever you build, use our security guide, and for publishing see how to deploy a vibe coded app.

Common problems

Cursor compared with the other routes

For a head-to-head, see Cursor vs Claude Code, and for similar editors the Cursor alternatives page. If you are weighing Claude directly, read Claude vibe coding.

Our take

Cursor is the middle path. It gives you more control than a hosted builder and less ceremony than a terminal agent. If you are curious about code and willing to read diffs, it is a good place to vibe code, and the files you end up with are yours.

Start on Free or Plus to learn the loop, and move up only when a limit gets in your way. Write a four-line rules file on day one, commit after each working step, and read the diff on anything that touches sign-in or money. Those three habits do more for the quality of the app than the choice of plan.

Checklist

• Project is in Git with a first commit
• A short AGENTS.md or .cursor/rules file exists
• Plan mode used for anything larger than a small change
• One change per prompt, a commit after each working step
• Diffs read for sign-in, payments, database and env files
• Privacy Mode checked for private code
• Secrets kept out of chat and the repository
• Security and deploy guides read before launch

Related pages

• Cursor
• Cursor pricing
• Cursor tutorial
• Claude vibe coding
• Best vibe coding tools