How are you using Cursor beyond basic code generation?

Discussions
, ,
1

I’ve been exploring Cursor more seriously and I’m curious how others are using it in day-to-day development.

Most people talk about Cursor as a tool for generating code, but I feel its real value is in how it understands the project context, helps edit across files, explains existing code, and supports debugging when you’re working inside a real codebase.

The features I’m most interested in are:

  • Agent for handling larger coding tasks

  • Codebase indexing for better project understanding

  • Rules for keeping responses aligned with project standards

  • Inline edits for small, focused changes

  • Chat for understanding unfamiliar files or logic

One thing I’m still trying to figure out is the best workflow.

Do you use Cursor mainly for writing new features, fixing bugs, refactoring, explaining code, or planning architecture before coding?

Also, for people using Rules, what kind of instructions have actually improved the quality of Cursor’s output?

Would love to hear practical workflows from people using Cursor on real projects, not just small demos.

3

For me, code generation is actually one of the smaller use cases.

The biggest unlock has been treating Cursor like a junior engineer (or a minion XD) that has access to my entire codebase.

A few workflows that work really well:

• Refactoring across multiple files. I’ll ask Agent to trace a feature end-to-end, propose a refactor plan, then execute it across backend, frontend, tests, and docs.

• Debugging production issues. I paste the error, ask Cursor to find all relevant code paths, generate hypotheses, and suggest the most likely root cause before changing anything.

• Architecture discussions. Before writing code, I often ask Cursor to compare 2-3 approaches, explain tradeoffs, and generate an implementation plan. This usually saves more time than code generation itself.

• Understanding unfamiliar codebases. I’ll ask things like “Explain how authentication works from login request to database” or “Trace how a payment is processed.” The codebase indexing is incredibly useful here.

• Large feature implementation. Instead of “build X”, I first ask for a task breakdown, review the plan, then let Agent implement it step-by-step. The results are much more reliable.

• PR reviews with Bugbot. This is probably one of my favorite newer workflows. Bugbot often catches edge cases, regressions, missing validations, and weird logic issues before another engineer even looks at the PR.

• Automations. I use Cursor’s automations to run repetitive engineering tasks in the background. Things like reviewing changes, checking project health, validating patterns, and reducing the amount of manual engineering work I have to do.

Rules have also made a huge difference. Some of the most useful ones I’ve used are:

• Prefer existing patterns before creating new abstractions.
• Reuse existing components whenever possible.
• Keep solutions simple and avoid over-engineering.
• Follow project folder structure and naming conventions.
• Explain major architectural decisions before implementing them.
• Write tests for critical business logic.

One thing I’ve learned: the better the context and constraints, the better the output. I spend more time describing the problem and desired outcome than reviewing generated code.

Interestingly, I now use Cursor more for planning, debugging, codebase navigation, refactoring, PR reviews, and automation than for writing code from scratch.

4

  • New Features - Kinda, with heavy guidance. The plan feature with being very very specific is nice but have to make sure nothing is vague so I will say in every request, If unsure or ambiguity even in the slightest. Ask me questions.

  • Fixing Bugs - Rarely, I use agents to find where the issue is likely stemming from but every agent I’ve used to date still does dumb bug fixes time and time again. Not to say its always wrong but ohh boy can it be and break an entire app doing so.

    • Like one time I was working on something with Tailwind in early 2026 and encountered a situation weird issue. Not sure what model was being used but solution was to replace v4 with v3 because it believed no matter what I tried that v4 was in a early beta state despite v4 released over a year earlier.

  • Refactoring - Kinda, I’ll have a high end agent like Opus to review new code for potential refactors BUT will only do maybe half of the suggestions. A lot of the time it can make refactor suggestions that to it seems like a good idea but if you know something is coming later that requires the code to be the way that it is. Gotta tell it no.

  • Explaining Code - For any 3rd party code that I’m not 100% on, I will totally get Composer’s opinion on it and do a back and forth discussion. Helps make sure I have the full context on if I overlooked something.

  • Architecture planning - Tried it a few times but 95% of the time, absolutely not. Even on the best models I’ve seen some of the absolutely dumbest suggestions and I no longer trust it in any capacity at this time. Agents are too readily to say “yes” to dumb ideas based on what their training data suggested to do in such cases. Their training data is also often outdated so when it encounters lets say new versions of something it doesn’t think exists, it’ll try to replace it.

    • Kinda related to the fixing bugs example, I’ve asked it to come up with an architecture plan to handle data in a certain way. I vaguely remember the solution it came up with was utilizing a package that was no maintained for over 5 years and the second suggestion was another package that hadn’t been maintained in 3 years. If I had just said yes to the first or second one, that could have been really bad further down the road.

Hope that answers your inquiry a bit.