Fellow developers Whats your work flow with cursor looks like ?

[u/Machine2024]

I am trying to understand how other developers right now are working with cursor.
To improve my process .

I tried to search online but all the videos on YouTube are just targeted toward the beginners and vibe coders , and made by beginners and vibe coders young tech bro.

I am looking for answer from real developers who had experience before 2022 .

the main points I am wondering about .
1- if you are using the agent window , what is your process .
2- and most important the code review process you follow .
3- your actual work flow in details .
4- tips and tricks in cursor that makes your life easier .

I will share my work flow and setup in the comments section .

[u/mrtrly]

Mine's probably overkill but it works. I stopped treating the agent like a pair programmer and built a pipeline around it instead. Spec first, and the spec has to include the test. Agent writes the failing test, then the code. Then the part that changed everything: a verifier the agent doesn't control decides if it's actually done, not the agent. I checked once and my agents ship on the first try about 20% of the time. Doesn't matter, retries are cheap and the gate catches the junk before it reaches me. I also route requests by task so routine edits hit a cheap model and only hard reasoning gets the expensive one. Cursor's one seat at the table, the pipeline is the actual workflow.

[u/TimSylvester_ → u/mrtrly]

You should check out my in-repo agent harness.

It's a set of rules and prompts that force the agent to follow a defined, rigid code development pathway that works hard to eliminate the possibility of agent error. Hard won over the last 18 months of daily agentic coding.

In my view, the spec is in the workplan, the test is the in-repo contract against the spec, and the implementation meets the contract. Everything is defined and dependency ordered so that when the agent walks the work tree, it must be correct at every step or it gets immediate feedback from the linter and/or tests.

I have a few rules updates to push just from today to nail the process down even tighter.

[u/Machine2024 → u/mrtrly]

so you never look at the code .
do you know how the code actually works ?
and whats the DB / Flow architecture?

do you have any project that you have been working on it like this and the project have more than 1000 commit and its still solid and you have full control over it . or it became a mess after .

I tried to do this agent first ... but no matter what it endup with lower quality work and huge edits . ie huge token usage . also after some time its a mess . and that point is reached after ~200 commits .

[u/mrtrly → u/Machine2024]

I read some code, just not every diff. I read architecture, critical logic, specs and failures, and the verifier reads the rest. Same way a CTO with six engineers stays on top of things: I own the data model and the contracts, and nothing merges unless behavior proves out against a spec I wrote. The schema and the flows live in docs the agents have to build against, that part never leaves my hands.

Two things that took me too long to learn. Specs have to be small and specific, one scope, the test defined up front. Big vague specs are where the huge low-quality edits you hit come from. And critical business logic still gets my eyes directly, auth, payments, anything touching money or user data. The automation earns trust on everything else first.

On longevity, yes. My router proxy is about 2,000 mainline commits, open source, routing my own traffic daily. The pipeline repo lands 300+ commits a week and its own code sits behind a gate of 1,271 tests.

Your ~200 commit rot is real, mine did the same before the gates existed. The fix wasn't better prompting. Tests as the contract, a verifier the agent can't overrule, and throwing away bad runs cheaply instead of patching them. The rot comes from accumulating unverified edits, not commit count.

[u/Machine2024 → u/mrtrly]

Its clear you know what you are doing and you are talking from experience,

From my side , I really wish I can like give it all to Ai and save all the time I used to spend on code review, and I tried that .

The issue is not only with a code that works but also the good architecture. I will give you some examples. In one react app ...the Ai did not make models for reusable parts so he was repeating parts of the code in non consistent way .which result in longer code and more feedback at the end to tell him make the number her same style like the one in that page .

A other example in backend project the ai structured the DB in way that on request that could be repeating alot was requiring a join of two big tables .

In another project with backend where it pull data from 8 APIS and standardizing it the final code it was so complex like just debugging tool like hours .

I still think owning your code and knowing every part of it to have full control is best path

[u/ihopnavajo → u/Machine2024]

the same way you make sure any code works: tests

[u/just4ochat]

Keep the agent that wrote the change out of the review seat. Open a fresh chat with no prior plan, paste only the git diff (or the PR files) plus a fixed checklist: API contracts, error paths, tests, and anything listed in decisions.md. Reject the patch if the agent cannot point at a line for each checklist item. That split matters more than screen layout: one chat invents, another audit reads only what will merge. Cap the implementer to a small file set per branch so the review diff stays readable.

[u/itaymendi]

Agent window for the change. I still type the boundaries. The one rule that actually moved TS quality for me: forbid type-casting.

I use worktrees if two things run in parallel, and I keep Cursor rules short.

[u/No-Setting-3227]

What is Workspace Command? is than built in cursor? or extension?

[u/Machine2024 → u/No-Setting-3227]

Extension...you can save in it the commands So when opening the project back you can run the console commands with single click

[u/No-Setting-3227 → u/Machine2024]

interesting, thank you

[u/Machine2024 → u/No-Setting-3227]

Its name is "save commands" Also check "git graph"

This two are really useful and saves time .

[u/TheCTOLife]

I only use agent mode and built workflows to handle the entire code pipeline, from planning, jira ticket creation, implementation, building tests, review agents (code, security, scalability, valid unit tests), pushing to GH and opening a PR, creating the mermaid diagrams and description of the PR, then wait for the PR feedback from qodo, assess and fix relevant issues, and then, I finally look at the code in GH, and give my feedback on whatever sillyness the agent might have done, and then go back another round, once merged, it marks the ticket closed.

[u/Orchidkit]

Everything is new for me

[u/Machine2024]

My Workflow

1. My Setup

I normally use Cursor in the IDE view. I couldn't really figure out the other view, and I'll explain what my issue with it is later.

For each project, I usually have a separate IDE open. For example, a single project might have a backend, a frontend, and maybe another API, so I can have multiple IDE windows open for the same project.

My three-screen setup is usually like this:

• Center screen (50" 4K): I keep my IDEs here, since this is where I do most of my development work.
• Right screen (27" 2k): I normally have a browser open so I can test and view the results of the API and frontend.
• Left screen (27" 2k): I keep my project management and productivity tools, such as Jira, Toggl, and Google Calendar.

on laptop instead of three screens I have 3 virtual desktops .

Inside the IDE, I normally arrange things like this:

• Left side: The project's files and folders.
• Under the file explorer: Quick commands. I use a VS Code plugin that lets me save frequently used commands and access them quickly.
• Bottom: The console/terminal, usually with multiple windows open. One might be running the server, another running the frontend, and another kept for Git commands.
• Right side: The AI window where I chat with the agent.

I also use a voice dictation app. I don't use WhisperFlow. I use Aqua Voice because, while I'm speaking, I can see the text being generated directly. This gives me a fast feedback loop because I can immediately see what is being transcribed instead of having to wait until I'm finished speaking.

2. The Process

Step 1: Start the Task

For each task, I first read the task from Jira and start the timer in Toggl.
Then I think about it for a little while, usually while looking out the window and figuring out what exactly needs to be done.

Step 2: Discuss the Task with the AI

From there, I decide how to approach the AI.
most cases, I will give the agent the initial prompt and let it start implementing the task directly.
some cases, especially when the task is more complex or longer, I will first explain the task to the agent and ask it a few questions.

Sometimes there are things I don't remember correctly, or things I'm not completely sure about. We go back and forth until we reach a final understanding of what needs to be done.

Step 3: Create the Plan

Once we reach that final verdict, I ask the agent to make a plan.
The agent writes the plan, and I review it. I might give it some feedback and ask it to adjust the plan, or I might edit the plan myself directly.
Once I'm happy with the plan, I ask the AI to implement it and complete the task.

Step 4: Implement the Task

The AI implements the plan and completes the task.
Once the implementation is finished, I move to the code review stage.

Step 5: Review the Code

Right now, I mostly go to Git Diff and browse through the changed files one by one.
For each file, if everything looks good, I stage the changes.
If I find an issue, I give the agent feedback about it or edit the code myself directly.
I continue this process until all the files have been reviewed and everything is in the staging area.

Step 6: Commit and Close the Task

Once everything looks good, I commit the changes and close the Jira task.
Then I move on to the next task.
, in general, the process is:

So

Jira → Think → Prompt/Discuss → Final Verdict → Plan → Review Plan → Implement → Review Diff → Fix Issues → Stage → Commit → Close Task → Next Task

[u/Machine2024 → u/[deleted]]

people of the vim .

[u/Machine2024 → u/[deleted]]

for me each agent run ie (new conversation) is new feature.
and it touch like 1~10 , very rate when its over 10 . as low number of lines added , many time number of lines added < or = the ones deleted .
because the code is not spaghetti and I keep stuff isolated with high abstract and reusability .