← Back to blog

How I Use Cursor

April 22, 2026

Table of Contents

There are many agentic coding tools on the market these days, but one stands out more to me than any other. That is Cursor. It enables the agent to do so much more out of the box than most other tools I've tried, and not chatting in the terminal is a breath of fresh air.

Cursor 3 introduced Glass. This made it easier than ever to multitask by running multiple agents on multiple projects at the same time. But there are also so many other features inside Cursor that many users are missing out on.

I live in Cursor when I am building, including at Inference Partners, the technical agency I run. I wanted to write down how I use it, which features I reach for on real work, and a few that do not get enough airtime. A recent end-to-end build was the nudge to put it on paper, but what follows is the workflow, not the story of one project.

Scope the work

Once I had requirements locked and was ready to plan, I jumped into Cursor and started sharing notes in the repo. I already had a landing page in the workspace, so I used that context as a starting point.

I mainly used Opus 4.6 (eventually 4.7) and Composer 2 at this stage and I was not letting my agents write any code. The focus here was to break down the requirements and determine what work was needed to satisfy the requirements, just like you would with a team of PMs and engineers.

Once the work was scoped out, I had the agents break it down into small workable Linear Epics and issues. Using the Linear plugin in Cursor, I didn't have to write anything by hand or do any copy/paste. The agent did the work while I reviewed the output.

Drafting Linear epics and issues from the scope conversation, then reviewing what the agent wrote.

Do the work

Now that the work is scoped, it is time to execute. Cursor enables me to do this in various ways. At any given moment, I might have 5 or more agents running at the same time in different environments (cloud and local).

Typically when I'm at my machine, I'm running agents locally. They kick off faster, and it's quicker to test and validate their changes. I bounce back and forth between Opus 4.7 and Composer 2. Usually Opus handles the planning or the intense UI work, while Composer handles everything else. When Opus creates a plan, I hand it off to Composer and it knocks it out incredibly fast.

When something new pops into my head that is related to the feature I'm working on, I open a new thread and spin up a new agent. On occasion, it is helpful to mention past chats in a new thread so that the agent has the relevant context it needs. It is far more productive to do this than to continue a never-ending thread and let context rot pile up.

Cloud Agents

My favorite workflow I've been using lately is automatically kicking off cloud agents via Linear. Back in the Scope the work section we talked about how we used agents to write Linear issues. Well, you can tag an agent directly in a Linear issue by commenting @Cursor and a cloud agent will move the issue to In-Progress and complete the work according to the contents of the issue.

This workflow is incredible. I can be away from my desk, out on a walk or anywhere else, and just tag Cursor in a Linear issue from the Linear mobile app and the agent does the rest. When the agent has completed the work, it shares a demo recording so I can easily validate if this is correct or not. Most of the time I validate the changes when I get back to my desk, but nonetheless this is awesome.

Tagging @Cursor on a Linear issue so a cloud agent picks it up and leaves a demo when it is done.

I highly suggest giving cloud agents a try. See how to set it up here.

Built in Browser

An underrated feature of Cursor is the built-in browser. People aren't talking about this enough. If you are doing frontend work with an agent, chances are you have copy/pasted many screenshots to the agent telling it to fix something or how bad the UI looks. With Cursor's built-in browser, you can just tell the agent to open the browser with @Browser and it carefully reviews the frontend. You can literally see what the agent is viewing in the browser in realtime. It won't always see things that are off like a human would, but it is far more effective than constantly pasting screenshots into the chat.

Review the work

While the frontier models and coding agents write good code, they are far from perfect and their output still needs to be reviewed. Cursor makes this extremely easy. The diff viewer on web and in Cursor Glass is so clean and such an incredible user experience. It's easy to review changes, and create PRs all without having to leave the app.

Now let's talk about Bugbot. This is one of the best code review agents I've used. It does not catch everything but it does a pretty good job of finding bugs before you merge your PR. My favorite part is using Bugbot with autofix turned on. Whenever Bugbot finds an issue, a new cloud agent is automatically spun up to fix the issue and then pushes the changes. So smooth. Read more about closing the code review loop from the Cursor team.

Now of course you should still read the code your agents put out, but bugbot acts as another set of eyes for each PR. When you're working solo, this is worth every penny.

Walking changes in Glass and letting Bugbot catch issues before merge.

Complete the work

I covered some of my favorite features that I use daily with Cursor in this post, but that hardly scratches the surface. Some other powerful ones I missed were canvas, design, and debug. See the full list of features here.

I hope this was useful. I will leave the floor open for discussion, whether you want to share how you use Cursor or your take on anything in the post. If you are looking for a hand on a build, I work with teams in that space at Inference Partners. I am open to chat via will@inferencepartners.ai or @wrowston on X for a quick question, a back-and-forth on ideas, or a project you have in mind.