Two months ago, I stopped setting breakpoints. I didn’t decide to stop — I just noticed I hadn’t done it in a while.
That realization hit me during a quiet moment as I reflected on how my workflow has been shifting. Not in a dramatic, overnight way, but gradually, almost invisibly. The kind of change you only notice when you look back.
A Long History of Paying for My Tools
Since around 2009 or 2010, I’ve made a habit of paying for my own development tools. It’s a personal thing — a signal to myself that I take my craft seriously and that I’m not just waiting for an employer to hand me something.
For years, that meant Microsoft Visual Studio plus two productivity plugins: CodeRush and ReSharper. They overlapped in some areas, but each had features the other didn’t, so I kept both and tuned them to coexist. When I moved into Ruby on Rails, I adopted JetBrains RubyMine — a natural fit, since ReSharper is also a JetBrains product, and it gave me the same level of support in a different language. When I came back to the Microsoft space, I landed on JetBrains Rider: all the power of Visual Studio plus ReSharper, without the accumulated baggage. It also ran on both Mac and PC, which mattered to me.
VS Code never really took hold for me. I used it occasionally for light file editing, but Rider was home.
Enter Cursor — and a Two-Tool Workflow
About a year ago, I started using Cursor. At the time, Rider had just introduced its own AI-assisted code generation, and it was genuinely useful. I could be in a file, hit a shortcut, and get solid help finishing a method or generating a class. That was already a meaningful upgrade.
But Cursor raised the bar immediately. It didn’t just help within a single file — it could create multiple files at once, and scaffold entire features. So for the first several months, I ran a two-tool workflow:
-
Cursor for macro code generation — kicking off features, writing large amounts of code across multiple files.
-
Rider for everything else — refactoring the generated code to my preferences, navigating the codebase, running and debugging tests.
It wasn’t a perfect setup, but it worked. And the refactoring part was honestly necessary at first. The AI output needed shaping.
The Rules Files Changed Everything
What changed was a habit I built around markdown files — rules and instructions I kept refining to guide Cursor toward my style, my opinions, my approach. Over time, as those files got better, so did the generated code. I had to fix less. I had to refactor less. The two-tool split started to compress.
Eventually, I stopped using Rider’s AI features altogether. I’d only go to Rider for debugging.
Then, in late 2024, Cursor added a debug agent mode. And I started spending less and less time manually stepping through code.
I Don’t Remember the Last Time I Set a Breakpoint
A couple of weeks ago, I realized: I genuinely can’t recall the last time I opened a debugger and set a breakpoint.
The few times Cursor was spinning its wheels on a problem, I’d step in — go to Rider, look at the database, check the tests, identify what context was missing, then come back and give the AI that context. More importantly, I’d update the rules files so that the scenario wouldn’t recur.
But even that has become rare. And the database navigation piece — the one thing I kept returning to Rider for — has shifted too.
When the AI Can Read Your Database
We’re using Postgres with event sourcing, storing data as JSON documents. When something looks off, I used to open Rider’s database tool, run queries, and manually parse through rows and JSON fields.
Now I use the Postgres MCP server in either Cursor or Windsurf. I describe what I’m looking for, and it runs the queries itself. Because it has access to the codebase, the data models, and the schema, it knows where to look. It gives me results already formatted for readability — no more squinting at raw JSON columns.
That was the last thing tying me to Rider on any regular basis.
99%
For the past three weeks, my main project has been running entirely in Windsurf. When I checked my profile stats, the number stopped me: 99% of the code on that project has been written by Windsurf. The remaining 1% is almost certainly me refining a few markdown files — the rules, the context, the instructions that shape how the AI works.
That 1% might be the most important 1%.
The Shift Is Real, and It’s Still Happening
None of this happened all at once. Looking back, the major compression occurred over the last four to six months, within a broader shift over the last twelve months. It’s the kind of change that feels invisible while it’s happening, then obvious in retrospect.
I’m not claiming the debugger is dead, or that every team is ready to work this way. My setup is specific — the rules files, the MCP integration, the way I’ve trained my workflow over time. But the trajectory is clear enough that I think it’s worth naming.
The tools I reach for have changed. The mental model of what a developer does is changing with them.
Leave a Reply