Why you should come back to Cursor

I left Cursor for Claude Code and Codex, then came back. Here is the setup and the method I actually use.

I'm Jimmy Xu. This is how I actually use Cursor.

Most of my work is research and writing, prototypes and demos, product MVPs, and light site ops. The setup below sits between vibe coding and strict agentic engineering: enough structure to ship, not a platform team's maintenance stack. It is meant for AI product managers, founders, and builders — not for people whose job is the compiler.

You should leave with three things:

Why I came back to Cursor
A configuration you can copy
A method that works if you are not a systems engineer

Why I came back to Cursor

I started with Cursor in August 2025, when it was the default AI IDE. The first projects I vibe-coded were built in it.

Then Claude Code and Codex got strong, and I switched. I also tried TRAE's overseas build. I came back.

The reasons were practical:

Claude accounts get banned. I have lost two.
Codex burns quota too fast. Without a reset, it does not last.
TRAE overseas still topped out at GPT-5.4. I could not use the newest models there.

Grok 4.6 is cheap and it holds up. Cursor itself — both as an AI IDE and as a harness — is still a good place to work.

Against Codex and Claude Code, Cursor's real advantage is speed. Grok 4.6 in Fast mode does not make you wait.

On quota, Cursor Models — the Grok series and the Composer series — are generous enough that a Pro+ plan covers my work.

How I configure Cursor

I am against installing a pile of Skills, MCPs, plugins, and subagents by default. Two reasons:

Anthropic cut most of the system prompt in Claude Code, and performance did not drop.
Extra components pollute context. A tool that fires at the wrong time lowers the quality of the output.

I also think you have to understand what the agent is producing. If you cannot read it, you are rolling dice, and the ceiling on your AI coding stays low. To raise that ceiling, you have to be able to read the agent's work.

Rules

A rule is a hard line: something the agent must follow in every session. I use a global rule for three basic problems.

Problem	Fix
The agent does not write like a person. Hard to follow.	Pyramid principle
It treats the surface, not the root.	First principles
It over-designs.	Occam's razor

You can create this in Cursor with /create-rule:

Use the pyramid principle. Prefer diagrams, tables, and lists.

Use first principles. Start from facts, keep asking why, and find the root cause.

Use Occam's razor. Smallest change. Do not add an entity unless you need it.

Plugins and MCPs

Give Cursor the link and let it configure itself. If you do not have a link, search the marketplace.

Firecrawl. Web search and scrape. Fresh technical information for research.
Context7. Current docs and API usage. Fewer invented APIs.
Composio. Connect other apps so the agent can call them, instead of you wiring every API.
Vercel. Ship a product to the cloud.
Supabase. A database with a backend attached. Lowers the cost of standing up a site.
Spaceship MCP. A domain-registrar MCP. Pair it with Vercel to put a domain on a live app. Spaceship MCP docs
Playwright MCP. Drive a browser to test what the front end actually shows. microsoft/playwright-mcp

People ask why I bother with Playwright, since Cursor already has a Browser Tab. The built-in tab has a width problem. I often need to check a page at full screen, so I use Playwright.

Two Playwright settings matter:

channel: chrome — use the Chrome on this machine, not bundled Chromium
viewport: null — do not lock the window size, or you cannot test full screen

playwright-mcp-config.json:

{
  "browser": {
    "browserName": "chromium",
    "launchOptions": {
      "channel": "chrome"
    },
    "contextOptions": {
      "viewport": null,
      "deviceScaleFactor": 1
    }
  }
}

Skills

UI UX Pro Max. Makes generated pages look designed. nextlevelbuilder/ui-ux-pro-max-skill
lark-cli. Feishu / Lark. Read and write docs, operate Feishu apps.

Personal take: UI UX Pro Max is much better than frontend-design or design.md for UI work. design.md is almost useless when you need to change a front-end design.

How I work

That is the setup. These are the rules I actually follow.

1. One task, one session

Keeps context clean and avoids burning tokens on a mixed thread.

2. When you do not understand something, fork the chat

Open a new session in Ask mode. The point is to understand why the agent designed it that way — that is how you raise your own engineering ceiling — without contaminating the original task.

3. Complex work goes through Plan mode

Plan first. Review it yourself. Then execute.

4. Use Debug mode for bugs that only show up at runtime

Not every bug needs Debug mode. Ordinary errors and static logic problems are fine in a normal Agent session.

Debug mode is for problems that only appear when the code runs. Those are hard to find by reading the source. You need real runtime data to get to the root cause. When you hit one of those, switch to Debug mode. It often works.

5. Automate the actions you repeat

Once you have a clear acceptance bar, give the repeatable work to automation. There is a lot to say here. I will write that up next.

6. Use a subagent when a frequent job should stay out of the main session

Example: reviewing a PRD or TRD. I have a subagent, @prd-trd-reviewer. It only reviews. The main session edits the document. They do not step on each other.