Introducing Trunk's AI DevOps Agent: Root cause and automatically fix CI failures Join the waitlist
General

Cursor’s Bugbot code reviewer and web app are a DX nightmare

Riley DrawardRiley Draward
July 31, 2025

TLDR: Frustrating workflows and inconsistent information make using Cursor’s Bugbot and web app a chore.

I originally sat down to test out Cursor’s Bugbot code reviewer so I could compare it to tools like CodeRabbit, Copilot, and, of course, Trunk’s CI autopilot. I found Bugbot’s initial developer experience when using the web app so aggravating that I decided to write this semi-coherent rant instead.

I have been using Cursor on and off for a while, but have been using Zed most recently. So I paid for a month of Cursor Pro to test out Bugbot.

Getting started with Bugbot

Setting up Bugbot on my test repo was easy enough. Cursor’s docs weren’t necessary; I just needed to give Bugbot access to my GitHub repo. I opened a PR from a random old branch I had lying around to make sure things were working and explore Bugbot before starting to test how well it could detect and fix code smells and CI failures.

And Bugbot did find weird typos that somehow ended up on this branch. It looks like a cat had jumped across my keyboard. I don’t have a cat. Moving on.

Bugbot leaves a nice, inline comment pointing out my mistake, and gives me two options:

  • Fix in Cursor

  • Fix in web

I figured that I had a good idea of what the “Fix in Cursor” experience would be. How could I resist the temptation of “Fix in web”?

”Fix in web” refers to the agent management page in Cursor’s web app. I will continue to refer to it as “Fix in web".

If only a “Fix in web” button existed for the “Fix in web” experience

I want to believe that a good user flow exists for working with Bugbot and the agent manager web app. Unfortunately, I wasn’t able to find something that feels good in the time I spent testing.

Clicking “Fix in web” brought me to the agent manager in Cursor’s web app. I was greeted by a pre-filled prompt ready to be edited and submitted. My issue was simple enough that the base prompt didn’t require any editing.

The agent went off in the background and did its thing, and, when finished making all the necessary changes, presented me with a diff of… my entire PR. Probably not the least helpful thing that Cursor could have displayed, but not far off. Nothing indicated what changes the agent actually made. In my case, it was removing bad copy changes, so the file change was not even visible in the diff.

Thankfully, a short summary of changes was at the top of the page with the original Cursor prompt and a summary of the changes made:

Well, sometimes Cursor produces a summary.

The second time I ran through the “Fix in web” experience (to make sure I didn't hallucinate my “Fix in web” experience), Cursor’s agent did not give me a summary of changes. Thankfully, I still had (another) full diff of my PR, so that I could look for the one-line change manually.

At this point, I was itching to go back to GitHub. Cursor navigated to “Fix in web” in the same tab as my PR. There was no obvious link back to my existing PR. There is a “Create PR” button with the GitHub logo, but I already have a PR and clicking this button just threw an error. I’m being nitpicky here, but it is annoying.

(Note: It appears that this has been fixed. Clicking "Create PR" now navigates you back to GitHub. It doesn't create a PR, but that's just semantics, right?)

It was only when I was back on my PR that I discovered Cursor had committed a fix on my branch. Without approvals or warning or notice. Neat-o. At least there was a diff I could examine.

Desperate to continue the “Fix in web” experience, I went back to Cursor’s agent manager.

Please, revert

The “Fix in web” page has an input asking for follow-up instructions. So I tried to revert the changes the agent had made with the prompt: “Revert the most recent changes you made”.

It said that the changes were successfully reverted.

The changes were not reverted.

“Fix in web”.

Seemingly out of other experiences to try out, I clicked on the only button that remained: “Open in Cursor”.

At least this worked. Cursor was opened, and the agent manager was open in a side panel. And reverting worked fine in the IDE.

Small changes would really improve DX

I can see the outlines of a good experience here. Maybe?

It would be nice if Cursor showed me:

  • A diff of the commit changes made by the agent, instead of the whole PR.

  • A link to the commit pushed to my PR (heck, a notification that a commit was pushed would be an improvement).

The integration between Bugbot and the Cursor web app seems like it was born of a last-minute “oh ya, these things could work together” decision without anyone considering the developer experience.

Just use the IDE

To be fair to Cursor, none of these issues arises when I “Fix in Cursor”. Clicking that option in GitHub opens Cursor, prompts you to change branches, and loads up the prompt in the agent panel so you can edit and fire away. Commits and changes can be done by the agent or manually by a developer.

It is a wonderful experience!

By contrast, the Bugbot + “Fix in web” experience sticks out as so painfully bad that I’m a bit amazed that it even made it out of beta.

The Bugbot + web app experience could use more time in the oven 

The vibes were not good using Bugbot with Cursor’s web app. Which is a shame. Reviewing code is hard. If AI can speed up the process even a little bit, it would be helpful. 

But alas, my actual testing of Bugbot will have to wait for another day. The "Fix in web" experience was too good not to stop everything and write about.

Try it yourself or
request a demo

Get started for free

The DevOps Assistant
for self-healing CI