I was a Cursor fan. Then something changed. Here's what I found when I started paying attention.
I want to start by saying I was a genuine Cursor believer.
Not the kind that jumps on every new tool because it has a nice landing page. The kind that actually integrates it into their daily workflow, tunes it, adds rules, writes custom commands, and tells other engineers to try it. I was that person. For a good stretch of time, Cursor felt like a genuinely unfair advantage.
And then, slowly, it didn't.
When the cracks started showing
I can't pinpoint the exact moment it happened. It was more of a gradual realisation. Tasks that used to go smoothly were starting to go sideways. Not catastrophically. Just... wrong in small ways, consistently. The kind of wrong that makes you read the output twice and wonder if you gave it bad instructions.
So I tried the obvious things first. I added better rules. More specific commands. Tighter context. I spent time thinking about how to prompt it better, how to structure the task before handing it off. I gave it a plan before asking it to execute.
It helped a bit. But not enough.
Even in planning mode, which should theoretically be where it shines, something felt off. It would confidently outline a solution that had a structural problem buried in step three. Or it would execute fine for the first few files and then start drifting. The more complex the task, the more it felt like I was spending as much time reviewing and correcting as I would have just writing it myself.
That is not a good sign for an AI coding tool.
The core problem: Cursor is a multi-model middleman
Here is what I think is actually happening, and why it matters.
Cursor is not an AI. It is an IDE built on top of AI. And the key word there is on top of. Under the hood, Cursor routes your requests to whichever model you have selected, whether that is Claude Sonnet, GPT-4o, Gemini, or their own Composer model. The flexibility of being able to switch models sounds like a feature. In practice, it introduces a layer of indirection that has real consequences.
The context Cursor passes to the model is curated by Cursor. It uses a RAG-based retrieval system to decide what parts of your codebase are relevant to the task and sends those along. That system is good but it is imperfect. It can miss things. It can truncate. And when a model is working with an incomplete picture of your codebase, the output reflects that. You end up with suggestions that are technically correct in isolation but wrong in context.
Claude Code works differently. It runs directly in your terminal, powered exclusively by Anthropic's models, and it reads your codebase the way you would: by actually navigating it. It uses grep and file traversal rather than semantic search, which sounds less sophisticated but in practice means it pulls the full context of what it needs rather than a curated approximation. The context window is also genuinely larger. Claude Code delivers the full 200K tokens reliably. Cursor advertises the same but multiple reports suggest actual usable context is closer to 70K to 120K after internal truncation.
For small, well-scoped tasks on small codebases, that difference barely matters. For anything complex, it shows up fast.
What happened when I switched
I set up Claude Code the same way I had set up Cursor. Same rules. Same custom commands. Same agents for the workflows I use most.
The difference was immediate enough that I genuinely went back and double-checked I had not done something wrong. The same tasks I had been wrestling with in Cursor were just... handled. Not perfectly every time, but handled with a level of understanding of my codebase that felt qualitatively different.
Adding the same structured rules and agents that I had in Cursor made it even better. The rules actually stuck. The agents executed with more consistency. Planning mode produced plans that held up when you looked at them carefully.
I think the reason is straightforward. When the model has genuine full context, good instructions compound. When the model is working from a truncated or estimated view of what matters, even well-written rules can only do so much.
The honest tradeoffs
Claude Code is not Cursor and I am not going to pretend it is.
Cursor is an IDE. It lives where you code. The inline diff view, the tab completions, the ability to see and approve individual changes right in the editor, those things are genuinely good. If you spend most of your day writing code line by line in a familiar environment, Cursor's workflow feels more natural. The visual feedback loop is tighter.
Claude Code is a terminal-first tool. If that is not already where you are comfortable, there is an adjustment period. It integrates with VS Code but it does not replace it in the same seamless way Cursor does.
The other thing worth being honest about is cost. Cursor's pricing changed significantly in June 2025, moving from request-based billing to a credit system. The base price looks reasonable but heavy agent use on premium models can quietly push you well past what you expect. Claude Code has fixed tiers that jump steeply but at least you know where you stand.
Neither of these is a dealbreaker. They are just real tradeoffs worth knowing before you switch.
The thing that actually matters
The question is not which tool has more features. It is which tool actually does the work correctly when you hand it something non-trivial.
For me, the answer shifted. Cursor was the right tool until it was not. Claude Code is the right tool now, for the kind of work I do: complex fullstack tasks across a TypeScript and Next.js codebase, multi-file changes, backend API work, the kinds of things where understanding the full shape of the project is the difference between a good output and a plausible-looking mess.
If you are a Cursor user who has been adding more and more rules trying to get consistent results and finding it still disappoints you on complex tasks, it is probably not your prompting. It is the context. Give Claude Code a proper try with the same setup and see what happens.
You might have the same reaction I did.
You will wonder why you waited.
I write about TypeScript, crypto infrastructure, and what it is actually like to build in this space. Previous posts covered MPC and institutional crypto custody and TypeChain and the bridge between Solidity and TypeScript.