Does it have some huge context window? Or is it really good at grep?

The Copilot version of this is just fucking terrible at suggesting anything remotely useful about our codebase.

I've had reasonable success just sticking single giant functions into context and asking Sonnet 4.5 targeted questions (is anything in this function modifying X, does this function appear to be doing Y) as a shortcut for reading through the whole thing or scattershot text search.

When I try to give it a whole file I actually hit single-query token limits.

But that's very "opt-in" on my part, and different from how I understand Cursor to work.

I expect the formatter/linter to be run as part of presubmit and/or committing the code so it doesn't matter how it's edited and saved by the developer. It's strange to hear of a specific IDE being mandated to work around that, and making quick edits with tools like vi unsupported.

Part of a healthy codebase is ensuring that anyone can hack on it, regardless of their editor setup. Relying on something in .vscode and just assuming people are using that editor is what leads to this kind of situation.

Bake that into the workflow some other way.

allow me to introduce you to the lord and savior, https://pre-commit.com/

> Can cursor even do anything that vscode can't right now?

Right now VSCode can do things that Cursor cannot, but mostly because of the market place. If Cursor invests money into the actual IDE part of the product I can see them eclipsing Microsoft at the game. They definitely have the momentum. But at least some of the folks I follow on Twitter that were die-hard Cursor users have moved back to VSCode for a variety of reasons over the last few months, so not sure.

Microsoft itself though is currently kinda mismanaging the entire product range between GitHub, VS Code and copilot, so I would not be surprised if Cursor manages to capitalize on this.

Strawman.

Imaginary situation: People are using claude instead of cursor, and you can run claude in a terminal, so this is going back to the days of not using an IDE for the people that do it.

Straw man shake down: Terminal based development like vim and emacs are old and shit, and we moved away from that for a reason, and so (although totally unrelated) this means 'using claude' means going back to using a terminal for everything, which is similarly old and shit.

...but, obviously wrong.

- There's a claude desktop app that isn't done via the terminal.

- Agents use the terminal/powershell to do lots of things, even in cursor because that's the only way to automate some things, eg. running tests.

- Terminal environments like vim and emacs are ides. :face-palm:

- It literally makes no difference what interface you copy and paste your text prompt into and then walk off to get a coffee in agent mode.

Anyone who's seriously arguing that IDE integrated LLM chat windows somehow beat command line LLM chat windows is either a) religiously opposed to the terminal window, or b) hasn't actually tried using the tools.

...because, you'll find it makes no difference at all.

Why is cursor getting involved with graphite? ...because the one place where is makes a difference is reviewing code, where most CLI based tools (eg. `git diff`) are just generally inferior to visual integrated code review tools.

You know what that is?

An acknowledgement that cursor, in terms of code generation has nothing that qualifies as the 'special sauce' to use it over any other tool. CLI or not.

So they're investing in another company that actually has a good, meaningful product.

I used it extensively for a week and gave it an honest chance. It’s really good for quickly troubleshooting small bugs. It doesn’t come anywhere close to Opus 4.5 though.

The problem is companies like OpenAI have the upper hand here as they show with the Codex models.

Which is what I was mentioning elsewhere. They build huge models with infinite money and distill them for certain tasks. Cursor doesn't have the funding, nor would it be wise, to try to replicate that.