2 Years in Cursor IDE: How I Build Projects from Scratch, and Where Claude Code Actually WinsAI

When I first opened Cursor, the term “vibe coding” did not exist yet. It was just a tool that felt smarter than anything I had tried before. I had no idea I would still be using it 2+ years later.

In that time I went through GitHub Copilot, Windsurf, and a phase where I kept Claude open in the browser alongside VS Code. I kept coming back to Cursor. Not out of habit — out of results.

I now have a clear picture of how to use it properly, and where it genuinely loses to Claude Code. That is what this article is about.

Let’s set the record straight: I’m not a Vibe coder. Here’s why that matters

When “vibe coding” became a thing, I felt a quiet irritation. Not because the term is wrong. Because it started describing two completely different things as if they were the same.

Vibe coding in its pure form is when someone with no technical background describes what they want to an AI and accepts the output without understanding it. That is a valid approach for prototypes. But it is a fundamentally different story.

When a developer with 8 years of experience and 60+ production projects uses AI, something else is happening:

• He knows what the agent generated and why
• He spots the bug before it reaches production
• He recognizes when the model is hallucinating and confidently producing broken code
• He knows how to give the agent the right context, not just describe a desired outcome

AI in the hands of an experienced developer is a force multiplier. AI in the hands of someone without the foundation is a lottery. That distinction matters — and it is exactly why an experienced developer will get the most out of Cursor.

How I design the project architecture in Cursor

When I first started using Cursor, I did what most people do — opened Agent Mode and typed the task. The agent ran, generated something, I accepted it, then spent half an hour figuring out why it did not work the way I expected.

My process looks different now.

Plan Mode — the entry point for anything touching more than 1 file

If the task is small and local — fix a function, rename a variable — I work without a plan. But the moment a task touches multiple files, introduces a new feature, or has any meaningful structure behind it, I start with Plan Mode.

In your case, the task will be to build a SaaS platform, app, or bot from scratch

How it works step by step:

• Open Cursor, Then press Ctrl/⌘ + I to open AI chat.
• Press Shift+Tab in the input field — Cursor switches to planning mode (⌘+I — agent which can edit files, ⌘+L — just read and chat)
• The agent reads the codebase and asks clarifying questions before doing anything. For example: “Should the new auth module be session-based or JWT? Should it share the existing user model or create a separate one?”
• A Markdown plan is generated with links to specific files, Mermaid architecture diagrams, and a to-do checklist
• I save the plan to the repo via “Save to Workspace” — it lands in .cursor/plans/ and goes into git

This is not just documentation. It is a contract between me and the agent: exactly what will be done and how. The next agent — or me in two weeks — can pick up from that file without rebuilding context from scratch.

Project Rules — what a plan cannot replace

Plan Mode answers what needs to be done. Project Rules answer how it should always be done — in every plan, every task, every session.

Rules live in .cursor/rules/*.mdc and are version-controlled with the rest of your code. Without Rules, the agent starts every new session like someone on their first day at the project. With Rules, it behaves like a developer who has been on the team for a month and already knows how things are done here.

Three types of rules:

• Always-applied — active in every session. Example: “Always use the repository pattern for database access. Never write raw SQL queries outside of /db/queries/. Use camelCase for variables and PascalCase for components.”
• Glob-scoped — applied only to specific files or directories. Example: a separate rule for /frontend/** that enforces React component structure, and another for /backend/** that enforces Express middleware patterns
• Agent-requested — the agent loads these when it decides they are relevant. Example: a rule with API integration patterns that only activates when the agent is working with external service files

---
globs:
alwaysApply: false
---
- Use our internal RPC pattern when defining services
- Always use snake_case for service names.
@service-template.ts

Agent Mode vs Manual Mode

Most people start and finish with Agent Mode — and gradually lose track of what is actually changing in their codebase.

Agent Mode:

• Autonomously searches the codebase, opens files, runs terminal commands
• Iterates on errors without waiting for you
• Example: “Refactor the authentication flow across the entire app to use the new JWT service” — the agent finds all relevant files itself, makes the changes, runs the tests, fixes what breaks
• Best when the task is well-defined and the plan is ready

Manual Mode:

• Edits only the files you explicitly reference
• No autonomous search, no terminal commands
• Example: You open UserService.ts and auth.middleware.ts, say “Add rate limiting to the login method using the existing Redis client”, and the agent touches exactly those two files and nothing else
• Full control over what changes and where

I personally spend the majority of my time in Manual Mode. When you are deep inside a specific piece of code, you do not need an agent wandering through the project and “helping” in adjacent files.

Agent Mode I enable for large, well-planned tasks — when the plan is written, Rules are set, and I am ready to give the agent more autonomy.

Running agents in parallel

In Cursor you can run several agents at the same time, each in its own context on its own task.

A real example from my workflow:

• Agent 1 — writes unit tests for the new payments module
• Agent 2 — refactors the notification service in a separate branch
• Agent 3 — generates API documentation from the existing route handlers

Cursor 3.0 (or 2.0) made the Agents Window the primary interface — ⌘+Shift+P -> Agents Window. When multiple agents finish the same task, Cursor automatically evaluates all results and recommends the best one with an explanation of why.

This is not vibe coding. This is orchestration.

Features Most Engineers Skip

I went through the current documentation and picked what actually changes how you work day to day — not marketing features, but things I use myself.

Tab — not autocomplete, but next-action prediction

The Tab model in Cursor does not predict the next line. It predicts the next edit:

• Renamed a variable userId to accountId in one place — Tab suggests renaming it across all call sites in the same file
• Added a new parameter locale: string to a function — Tab suggests updating every place that calls that function
• Used a method from another file — Tab automatically adds the missing import statement

Controls: Accept the suggestion — Tab / Reject it — Esc / Accept word by word — ⌘+Right Arrow

Memories

Opt-in feature, enable it in Settings -> Rules. The difference between Memories and Rules:

• Rules — explicit instructions you write manually. Example: “Always use async/await, never raw Promise chains”
• Memories — implicit knowledge Cursor derives from your behavior. Example: you corrected the agent three times on how you structure React components — Cursor remembers that and applies it going forward without you writing a rule

Together they give the agent a persistent understanding of how you work, without repeating yourself every session.

@-symbols for precise context

Instead of copy-pasting files into the chat, Cursor gives you targeted references:

• @Branch – gives the agent context about what branch you are on and what changed. Example: “Review the changes on this branch and find anything that could break the existing API contract”
• @Past Chats — reference a previous conversation. Example: you designed an architecture last week, now you continue from that decision without rebuilding context
• @Recommended – the agent pulls relevant files itself based on your query. Useful when you are not sure which files matter
• @Docs – connects library documentation directly into context. Example: @Docs Stripe and the agent knows the current Stripe API without hallucinating outdated methods

Custom slash commands (now it called skills)

Skills are reusable sets of instructions that teach Agent how to handle specific tasks. They’re more detailed than rules and designed for multi-step workflows.

1. Type /create-skill in chat and describe the skill you want
2. To create one manually, add a SKILL.md file in .cursor/skills/your-skill-name/:
3. Example of skill:

# Deploy to staging
1. Run the test suite
2. Build the production bundle
3. Deploy to the staging environment
4. Verify the deployment health check

Bugbot

Automatic PR reviewer, connects to GitHub directly:

• Triggers on every PR update
• Leaves comments on specific lines with detected issues
• Proposes a ready fix — you click “Fix in Cursor” and land in the editor with a pre-filled prompt
• More than 35% of proposed fixes are merged as-is
• Current resolution rate: ~78% — higher than GitHub Copilot (46%), CodeRabbit (49%), and Gemini Code Assist (31%) in published benchmarks

Background Agents

You start an agent in a cloud sandbox on a separate branch, go do other work, and come back to a finished result.

Good for:

• Large refactors where you do not want to watch every step. Example: “Update all API endpoints to the new response format from the design doc”
• Dependency updates across the whole project
• Generating tests for existing code you wrote without them

Checkpoints

Every Composer generation creates a restore point automatically. I use this more than git stash for risky experiments:

• Try an approach, it goes wrong, click “Checkout” next to any checkpoint, back to the clean state in one click
• No branch switching, no stash conflicts, no lost work

Hell yeah!! This feature has saved me so many times when I wanted to revert to a previous version of the code after things went completely haywire.

Cursor vs Claude Code: An Honest Comparison

This is the question I get asked the most.

Cursor and Claude Code come from different philosophies:

• Cursor — IDE-first. I drive. AI assists at every keystroke. I see every change as a diff before it is applied.
• Claude Code — agent-first. I describe intent in the terminal. The agent drives. I review the outcome when it is done.

Where Cursor wins for me

• Interactive work and UI iteration — seeing changes inline is faster than reviewing a batch diff
• Anything where Tab autocomplete improves the flow of writing code
• File-by-file visual diff review — I can accept or reject individual lines
• Multi-model routing: Claude, GPT, Gemini, and Cursor’s own Composer model available per task in one place
• Working in an unfamiliar codebase — easier to navigate visually

Where Claude Code wins

• Autonomous multi-file refactors where I do not need to watch
• CI/CD integration through the SDK — the agent runs as part of the pipeline, no human present
• Large context window: up to 1 million tokens on Sonnet with the Max plan, more stable than Cursor’s context under load
• Automation beyond code: file operations, scripts, batch processing from the terminal

What I actually do: I use both. Cursor for active development and design. Claude Code in the terminal for heavy autonomous tasks that do not need me present.

The question is not which tool wins. The question is which part of your workflow each one belongs in.

What the Official Docs Get Right

The documentation at cursor.com/docs is organized around concepts: Tab, Agent, Plan Mode, Modes, Rules, Memories, Background Agents, MCP, Bugbot. That structure matches how you actually learn the tool — from simple to composed.

My recommended reading order if you are starting out:

1. Concepts — understand the basic model before touching anything
2. Rules — set these up before you write a single line of code on a project
3. Plan Mode — learn this before you run your first agent on a real task

What the docs cover less thoroughly:

• How Rules and Memories interact in practice — which one takes precedence, how they combine
• Real-world MCP setup patterns for common services
• The conditions under which Plan Mode triggers automatically vs. when you need to invoke it manually

3 Habits That Made the Biggest Difference

Habit 1. Write a rule only when the agent makes the same mistake twice

Premature Rules are premature optimization. You write a rule for a situation that never repeats, and it becomes noise in the context. I add a rule only when I see a pattern: the agent made the same wrong call twice.

Example: the agent kept generating class-based React components on a project where we use only functional components. After the second time, I added one rule: “Always use functional components with hooks. Never use class components.” That rule paid for itself immediately.

Habit 2. Start a new chat when the agent loses focus

Long sessions accumulate noise. After 20–30 turns the agent starts getting confused by the accumulated context, drifts toward irrelevant details, and quality drops. I do not try to fix a drifted session. I open a new chat and use

@Past Chats to bring forward only what matters — without the noise.

Habit 3. Go back to the plan instead of fixing bad code

This changed how I work more than anything else.

Before, when the agent produced something wrong, I would try to fix it with follow-up prompts:

• “No, not like that, I meant this”
• “You did not account for this edge case”
• “Redo this part differently”

This turned into an endless back-and-forth with growing context noise, and the output kept drifting further from what I actually wanted.

Now I do this instead. If the result is wrong — I roll back to the checkpoint, open the plan, sharpen the specific to-do item that caused the confusion, and run the agent again. It is always faster. Always cleaner.

Example: the agent built an entire caching layer the wrong way because the plan said “add caching to the user service” without specifying the strategy. I rolled back, updated the plan to say “add Redis-based cache with a 5-minute TTL using the existing RedisClient from /lib/redis.ts”, and the next run was correct on the first pass.

The problem is almost never the agent. The problem is that the plan was not precise enough. A good plan is not documentation. It is the accuracy of the assignment. And the accuracy of the assignment is the core skill of working with AI

To Close

My name is Alex Gromov. I am a Fullstack developer with 8 years of experience — JavaScript, React, Node.js, Python. Over the last 2 years, most of my work has involved AI tools in some way: building products with them, automating workflows, experimenting with agents, and writing about what actually works.

Cursor has been my primary tool for 2 years. Not because I am a fan. Because it fits the way I actually work.

If this breakdown was useful, I would be glad to connect on LinkedIn. I publish this kind of material regularly — AI tooling, engineering workflows, and the practical reality of building with agents.

One question to close: what is the one Cursor feature you would never give up — and what is the one thing you think is still broken?