Windsurf exploded onto the scene a couple of weeks ago, being boasted as a cursor killer by many. I've put both claims to the test.

After an intense week of Windsurf usage, I've broken down their critical differences into these

five categories that actually matter to developers. I'll also share why certain subtle features in Cursor made me stay

despite being genuinely impressed by Windsurf's capabilities. In this video, I won't be walking through every single

feature in a lot of detail. I'll be focused on comparing the differences between the features within

Cursor and Windsurf. Given that they are both forks of VS Code, most of the UI is

actually quite similar. I've even set my editor colors to look different just so that I can distinguish between them when

I use them on a daily basis. The first category we'll be looking at is code quality. Windsurf and Cursor don't

develop their own models for code completion; they mainly use models by Anthropic and OpenAI. In most cases, they

default to Claude 3.5, a sonnet, which is an amazing LLM for code output. Because

they share the same model underneath the hood, the code quality differences are not that big. Even though both are trying to

optimize prompts in a lot of places, it doesn't make a huge difference in terms of code. The main difference that makes

code generation different and accurate is the context that you put in. So, without considering that aspect, just looking at code quality alone, both

editors come out on top. Next, we'll be looking at that context. Context is really the killer feature here for Windsurf.

When it first released, Windsurf showcased its multi-file code adding tool. In Cursor, the equivalent is Composer.

One of the biggest differentiators for Windsurf at launch was its ability to decide on the context without you having

to explicitly prompt it at the very beginning. Very interestingly, Cursor quickly caught up with their own release

when Windsurf was just released about two weeks ago, and Cursor came up with the same feature just two weeks later.

And with a lot of the matching capabilities, together with Windsurf, if you look at some of the example runs here, it

feels like it's doing a kind of 01 preview-type inference, where it looks at the file, analyzes it, and then proceeds with the action,

rather than just, 'Oh hey, I got given this in context and then decide what to do.' Right? So that does seem to make AI

outputs better code than it used to. Another cool workflow that Windsurf demoed was the ability for Cascade to just

continue your work. So you could specify that you're already working on some code, and you were doing some like renaming or

refactoring of the code inside of Cascade. You can just type, 'Continue what I was working on,' and because it understands

the context of the files you just touched and the edits that you just made, so it's able to continue the work

without any explicit prompt. I've tried that in practice; it works well with small, smallish tasks, uh, like the

aforementioned one, renaming. But when you're working on a complex feature, you can't expect AI to just be able to guess

all of the context of the things that you have to work on, because at the end of the day, if you wanted to do a good

job, you need to give it very explicit specifications and context on what it needs to do. Say you've just started

implementing a feature; it might guess that you're implementing search, but you might just be trying to implement a new

model rather than actually doing the search, so the guesses would be completely wrong. And while I see this as a huge

convenience feature, and it works great in practice for small things, for large feature implementations be sure to still

give it a spec. While Wind did great in a lot of these auto-context tools, a lot of the other tools still lacked

quite a bit. For example, doc search doesn't exist; internet search doesn't exist. I can see what the Wind team is trying

to do; they're trying to hide a lot of this manual work underneath the hood so that you can rely on Wind to figure all

of these things out. But until those features are added, or have that auto-context capability for docs and search

to be added, you really have to give users those manual tools to shove things in so that they can get the context.

Without those features being implemented, in this case I think Cursor does a lot better by giving users just a lot of

picks and shovels to achieve the outcome, even though a lot of the workflow isn't as automated as Wind, but they are far more

convenient by having the feature rather than not giving you a tool at all. The other really convenient feature that's

in Cursor is the ability to mention the current diff, the working state of your current branch. Those things are

extremely convenient if you just want to review the code, if you want AI to figure out the context of your change and

continue. A nice small feature to keep in there. I really like how Cursor is implementing things by making sure users

have all of the tools available at their disposal. And while many users might not discover the good tools because they are

terrible at writing documentation, they are there. Once you discover it, after Wind released all of those auto-context

capabilities. I think CSA quickly realized that was a problem for them, so they quickly followed up with their own

release. So in the latest version, this is not even an edge for Wiv anymore, based on my experience inside the agent mode

for Composer, which is that auto-context implementation inside of Cursor. I think it's already on par with each other, but

with all of the other context tools that Cursor has added that users can directly reference and customize, I think Cursor

has a slight edge in the context department here as well. If I was just making this video a week ago, Wiv would be

winning out, but you can see how fierce the competition is in the AI code editor landscape right now. Moving on to the

next category, capabilities. This was an area that Wiv was just winning about a week ago, but now both are on par. One of the

biggest new tools inside Windsurf's sleeves is the capability to run commands directly as part of that cascade

execution. So let's say you're adding a new UI component and you were leveraging Chakra UI for the component library, and

it will be able to say, "Oh, I've added this new thing, and this uses a MUI component that didn't exist in your code

base, and here's the command that you need to run to add the MUI component. Would you like to do it?"  Confirm it, runs

a command. So this works for new libraries. While, you know, copy and pasting commands wasn't a huge issue, but

just having that integrated as part of the AI code generation makes it so much smoother in terms of experience. And

again, clearly Cursor saw this was an amazing feature and quickly followed up with their own version as well, and so

now inside the agent mode for Composer in Cursor has the exact same capability across the board. Um, you've already seen you

Multi-file editing is already a feature in both editors, so that's not a major point here. I'd like to see

new capabilities added to the AI chats.  I'd love to see the ability to not just run

commands, but long-running commands.  It should be able to restart the dev server with new configurations without requiring

access to the command line, or have the ability to access the existing terminal to say, 'This

is already running; let me just change these parameters.'  The web search capability is something I'd love to

see both editors add quickly. For example, if you're using a very new library or want to implement something

based on a best practice seen online, being able to mention a link specifically or mention

specific websites for code or styles you want to implement would be very convenient.

You wouldn't have to copy and paste from ChatGPT, search engines, or directly from web pages

into the chat. Having that directly implemented would be great. I think Cursor is already quite close because they already have the internal

tools; all they need to do is link their search and documentation tools inside this agent mode to achieve that. So, until the

new features are implemented, I'd say in terms of capabilities, both Cursor and Windsurf are tied at the moment.

Moving on to the next category: UX. To me, the UX is what sets one AI tool apart from another because if

they're mostly using the same LLM model underneath, code quality and capabilities will be very close, but UX,

while some might say it's easily copied, is core to the developer experience.

Everyday workflow: One thing I love from both editors is that, as you go through multiple stages in your chat, both

create checkpoints every time it makes a code modification. In Windsurf, if you go back to modify a prompt, it

automatically restores the code to the state it was in at that point. So if you modify the prompt, it won't continue

directly from there. It's a nice bit of implicit checkpointing. With Cursor, if you go back to edit part of the

prompt, it doesn't automatically revert; it continues on the codebase state, but it saves a checkpoint that you can

easily check out. In my dream world, I wish they just integrated with Git rather than using these kinds of arcane

editor built-in checkpoints. It would be much nicer to use Git to say, "Oh, I made a change; hey, I made a commit. This is great,"

and then made another change, and here's a new commit." If you want to revert back, great; I just use Git commands to do

that. And then, once you've completed the big feature, the AI can then squash those Git commits into a single, clean

commit with all of the feature implementations. That would be amazing to build in because, for a lot of people, Git

is not the most intuitive thing, and having to constantly worry about version control while using AI is another hurdle

for most users to use these tools well. So that is something I'd love to see in both tools. One of the biggest issues I

see with both AI editors currently is that if you touch multiple files, especially across a bigger feature, then the diff visualization to be able

to see the changes it made to the code gets quite annoying. Say you list this out, and then you have to click on this, open

this diff, and across the different parts in the chat, and you have to scroll down to click on each one of them while you

get a small, nice SP inside the editor to navigate through, but it kind of gets lost as you accept changes and move

through the code base. So I find that bar—it's a nice initial design, but it still needs to be massively improved.  Cursor used

to do this really well. I have no idea why they removed the feature. They used to have the composer window as a

whole separate thing, which showed you all of the file diffs in a nice, simple list on the left-hand side. Even

sometimes when it made edits across 5 to 10 different files, it was very easy to visualize and scroll through the changes.

Now they kind of force the UI to be part of the sidebar, making it much harder to actually visualize the changes. I think

it's a great change if you're making a ton of small changes, but if you're well-versed with your prompting and you have

been able to generate huge changes consistently—quality, big changes consistently with AI—then this makes it

kind of annoying. So Cursor, please bring it back! I look forward to that. A really nice side effect of all of this

move towards a more agentic design for code changes is that now the chat clearly lists out the logic of the

Windsurf vs Cursor: In-Depth AI Code Editor Comparison

Scripts