Claude Code vs Cursor: My First Impressions

I gave Claude Code a specific task and compared how it did vs Cursor

A few months ago during the Vibe Coding Game Jam, almost everyone I saw on Twitter discussing their work was using Cursor, one of the most popular AI-assisted IDEs. Claude Sonnet 4 had just been released, and Cursor had put their coding “Agent” feature front-and-center and moved its “Ask” feature to the side. The combination of the power of Sonnet with the tooling of Cursor made vibe coding more powerful and fun than ever.

More recently, I’ve seen countless people talk about embracing Claude Code - which Anthropic, the creator of Claude, released in ‘research preview earlier this year’ - in favor of tools like Cursor, an AI-based IDE I’ve written about on my newsletter and Youtube a few times.

Unlike Cursor, Claude Code is a primarily terminal-based tool, though there is some IDE support via plugins, including one for VSCode and Cursor itself. The terminal-based nature of Claude Code is a huge appeal to many engineers, some of whom prefer not to use IDEs, and others who want to use agentic based coding in contexts outside of the IDE such as terminal scripts and GitHub.

When Cursor hype was at its peak (raising money at a $9B valuation), many highlighted the irony that a “ChatGPT-wrapper” - a tool that just builds around foundational models- seemed to be a stronger business than the foundational models themselves. This inverted previous assumptions that “wrappers” were low effort with little to no competitive business moats.

Since the release of Claude Code in Research Preview, we’ve seen a foundational model company strike back. Claude Sonnet is usually cited as the current strongest coding model, and Anthropic - being the company that makes Claude - has at least some advantages in building the best coding tools on top of it.

Claude Code has emerged as one of the most popular tools for AI-assisted coding, and I’ve seen countless tweets and Reddit posts asserting that they’ve abandoned Cursor in favor of simply using Claude Code. So I’ve decided to give both a spin and come to some early opinions.

The Task They Battled Over - Improving ESLint Config in a Large Turborepo Monorepo

The main task I set out to accomplish is one that’s been giving me headaches for months. In Typescript, you can write async functions which are almost always intended to be called with await . Forgetting this has been a huge source of bugs in my codebase.

As an example of a bug, I mean to send a customer an email, but the server function finishes and terminates because I did not await for the email function. Because the server thread no longer exists, the async email function never around to being run, and a critical email is not sent.

This is not technically a violation of the Typescript compiler, and is instead something that should be checked by a linter like ESLint. In a small project, this is usually trivial to add.

The real challenge arose when I moved to a Turborepo monorepo, which I mostly did so that my web version of my project (written in React) and the native iOS/Android versions (built with Expo / React Native) could share code. NodeJS dependency management is notoriously error-prone and fragile, and in the world of Expo and React Native, doubly so, and in a world of trying o combine Expo with NextJS, triply so.

A few months ago, I spent over 10 hours with both Claude and ChatGPT trying to get my linter working, and still failed. It sounds a bit ridiculous, but does speak to the complexity and fragility of the ecosystem.

Claude Code One-Shots It

I downloaded Claude Code, and ran just claude in my cli, being presented with a prompt, where I described my issue.

Before I did that, I ran the initialization to create a Claude.MD, and I was pleasantly surprised that it deduced that my project was really two separate but closely connected apps (web and native) sharing code, without any instruction from me explaining this.

I then asked it to fix the ESLint issues, including that I was looking for a sample file that could reproduce the bug and show “red squiggly lines” in my IDE, which would call visual attention to the bugs as I develop.

Claude Code had no problem navigating my codebase (including the two separate versions of the product) and setting up ESLint:

It also created the test file like I asked and pointed it to me to verify I could see the red squiggly lines:

But Cursor One Shots It Too

I was blown away by Claude Code finally getting the configuration right and fixing this long standing issue, as I thought previous AI toolings had failed. However, I asked Cursor to accomplish the same thing, and it also one-shot it, fixing many quirky dependency issues:

It’s All The Same Underlying Model - So Whats The Difference

Its not surprising that both Claude Code and Cursor were able to fix the issue since they both use the same model, Claude Sonnet, behind the scenes.

While there’s clearly some minor differences in how their agent operates, both Claude Code and Cursor have top-notch teams so any big difference in capabilities is likely to be ironed out over time.

So if both Claude Code and Cursor can accomplish this task - what is the difference between the two tools? I’ve come to the following (early) conclusions:

1. Cursor still offers better IDE usability. While I tried the Claude Code VSCode Plugin, it’s bare-bones in comparisons to Cursor, mostly just showing diffs to approve. Cursor, meanwhile, has tab to complete and multi-line edit, which are much more sophisticated ways for a human to use AI to code faster.

2. Cursor is a faster workflow if you can use your codebase knowledge to hint the AI along its task. When I asked Claude Code to fix one of the linter errors, it took several Unix search and grep commands to even identify the area of the code I was talking about. Cursor, on the other hand, by default will add the file you’re looking at into the context, and specifically add context about where your cursor is highlighting code. This makes Cursor’s agent slightly faster when you are actively working in your codebase.

3. Claude Code is scriptable . Claude Code has a -p flag that lets you give it a prompt as you call it, which means you can write a script that will trigger Claude Code to do its job. This has almost infinite use cases but to name one, you could imagine a simple script to pull a GitHub PR, and run claude -p fix the linter errors . This way, Claude Code can be dispatched to every use case outside of the IDE, while Cursor’s agent is trapped inside of it.

4. Claude Code has tight GitHub integration - This ties into the above scriptabiilty topic, but it’s worth calling out that Anthropic has already added first-class support to GitHub for Claude Code. There’s tons of cool out-of-the-box features like being able to go to a GitHub issue, mention @claude, and have it create a new PR using a Github action in the background.

5. Claude Code is slightly more price efficient - Both Claude Pro and Cursor Pro are $20/month, but Claude Pro resets its usage slightly more frequently. If you need to step up from there, Claude Code offers a halfway price point at $100/mo, while both offer $200/mo plans.

Why Not Both?

It’s worth noting that Cursor, being a fork of VCCode, has a terminal window as one its panels. That means its trivial to run Claude Code inside of Cursor, and in fact Cursor is explicitly supported.

If you take this approach, you’ll still have to pick whether you want to use Cursor’s agent or Claude Code , with Cursor support, on any given task. The difference is subtle, but as noted above, if you reach for Claude Code within Cursor, you’ll get basic code diffs but won’t have access to Cursor Rules or Projects. In practice, I think if I’m within the IDE, but there may be specific workflows where Claude Code is better set up to accomplish a task.

Conclusion

Both Claude Code and Cursor are fast moving products (along with the rest of the ecosystem) so it’s tough to compare any of these tools as anything written can be changed within a few weeks.

But overall, the comparison between them becomes pretty clear. Cursor is an IDE-first tool with a focus on a great IDE experience and Claude is a terminal-first tool with a focus on flexibility and scriptability. Since they both use the same models under the hood, most of the difference in these two tools becomes centered around these focus points.

Finally, you can run Claude Code in the terminal panel of Cursor and have access to the best of both worlds.

There’s still tons of interesting features being released by both products such as Cursor background agents, Claude sub-agents, and Claude Github integration I hope to explore in future posts. I’m also intrigued by Amazon’s new Cursor competitor - Kiro.