How I Use Cursor to Ship 10× More Code

How I Think About Cursor

I think about Cursor as a code editor that lets me write ten times as much code as long as my mind can keep up. It removes the mechanical bottleneck of typing and lets you move at the speed of thought. That’s the real shift. It’s not about having AI write code for you. It’s about removing friction between an idea in your head and working software on the screen.

Where I’m Coming From

I’m not a computer science graduate or a researcher. Everything I describe here comes from practical experience and years of trial and error. For the past six years, I’ve been building SaaS products, reading code, writing a lot of code, and recently also building teams of talented developers. There hasn’t been much theory involved, only the constant cycle of writing, breaking, fixing and learning.

My Workflow in Cursor

Let’s say there is a Linear ticket waiting for me. Here’s how I go from task to shipped feature using Cursor.

1. Start With a Plan

I always begin by building a plan.Cursor’s Plan mode makes this step more natural because it gives structure to what used to be a few messy notes. The first prompt always includes a clear description of the problem from a business perspective. That part matters. You want Cursor to understand why the task exists, not just what code needs to be written.

I also add any technical context that will be needed later, such as identifiers, REST API docs or edge cases.

2. Review the Plan Like Code

Once Cursor drafts the plan, I read it carefully, the same way I would review a pull request. Line by line, I check whether each idea makes sense. If something feels weak, I ask for clarification or propose a different approach.

Sometimes I’ll have a short discussion with the LLM about potential alternatives.
Since GPT-5, it has become quite good at evaluating ideas critically and explaining trade-offs.

3. Approve and Build

When I’m fully happy with the plan, I tell Cursor to build it. It takes the plan and turns it into working code across the relevant files.

4. User Testing

Once Cursor finishes building the feature, the next step is to test it as a real user would. This is where things get interesting. Inside Cursor, you can tag @browser and write something like:

“Please test the feature as a user in the browser and make sure everything works as expected and as described in the initial ticket.”

Cursor will then open a Chromium browser and use the Playwright MCP server to automatically test your web app.

At this point, I simply wait while Cursor runs the tests. It will either confirm that the feature works correctly or fix the issues and test again.

Sometimes you need to explicitly ask it to re-test, but it’s still much faster than doing everything manually.

Once the feature passes all user tests, I move to the final stage.

5. Review, Don’t Write

Now the usual review begins. I go through every file and review it with the same care as a senior engineer’s pull request. I add comments, ask questions and request small refactors where needed.

That’s basically my workflow now. I spend my time reviewing plans, user testing, and reviewing code, not typing it out. It feels more like communicating intent and experience than manual labour.

Final Thought

Cursor doesn’t replace great engineers. It amplifies them.

AI isn’t taking senior devs jobs -> it’s giving an advantage to the people who already know what they’re doing. And the better your fundamentals are, the more power you’ll get out of it.