This does Cursor a disservice by not mentioning its deep integration.

Cursor will suggest and complete code for you inline. You just tab-complete your way to a written function. It's mad.

Claude Code doesn't do this.

Cursor also has much better awareness of TypeScript. It'll fix errors as they occur, and you can right-click an issue and have it fixed.

Contrast with CC where I've had to specify in CLAUDE.md to "NEVER EVER leave me with TS errors", and to do this it runs a CLI check using its integration, taking way longer to do the same thing.

Fwiiw

I noticed that CC’s generated Go code nowadays is very solid. No hallucination recently that i can remember or struck me. I do see youtube videos of people working with js/ts still struggling with this. Which is odd, there is way more training material for the latter. Perhaps the simplicity of Go shines here.

CC might generate Go code for which there are already library functions present. So thorough code reviews are a necessity.

Modern idiomatic JavaScript and TypeScript encourage "clever" code. The latter also has a very complicated type system, which, again, is frequently used, especially in .d.ts files for pure JS libraries because JS devs love tricks like functions doing different things based on number and type of arguments. So models learn all that from the training set, but then often can't deal with the complexity they themselves introduce.

Much as I dislike Go, it is indeed probably closer to the ideal language for the LLM. But I suspect that we need to dial it down even further, e.g. no type inference whatsoever (so no := etc). In fact I wonder if forcing the model to spell out the type of every subexpression as a type assertion might be beneficial due to the way LLMs work, for the same reason why prompting for explicit chain-of-thought improves outputs even with models not specifically trained to produce CoT. In the similar vein, it could require fully qualified names for all library functions etc. But it also needs to have fewer footguns, which Go has aplenty - possible to ignore error returns, concurrency is unsafe etc. I suspect message passing a la Erlang might be the best bet there but this is just a gut feel.

Of course, the problem with any hypothetical new PL optimized for LLMs is that there's no training data for it. To some extent this can be mitigated by mechanically converting existing code - e.g. mandatory fully qualified names and explicit type assertions for subexpressions could be easily bolted onto any existing statically typed language.

The CC vscode plugin can also fetch the errors and warnings reported to vscode by other plugins and language Servers, making the additional compile step obsolete

That's the biggest reason that the IDE plugin exists, so that Claude Code can get access to the LSP information

Right. Which it can. But to suggest that this makes it Cursor-like is wildly misrepresentative.

This is precisely what the CC extension does, no? At least that’s how the extension behaves in JetBrains IDEs.

Nope. It allows the CLI to read and parse your files. It absolutely does not give you Cursor-like interactivity.

If I’m wrong I’d be overjoyed! But I have it installed and have seen no hint of this.

It doesn't give you a Cursor-like experience but it gives Claude Code the LSP info, which means it will make less mistakes, especially with TypeScript

I started a new project to test out CC and constantly find I have to ask it to fix ts errors…it’s nice I don’t have to tell it what error it is (ie “fix the ts errors in file.tsx”) but I’m surprised it doesn’t have a “check ts” step automatically (i even added something to CLAUDE.md, which seems to work sometimes, but not always). It’s especially bad when working with recently updated libraries. It keeps suggesting thing that don’t exist anymore even though ts clearly knows it’s wrong.

Otherwise CC has been stellar and I live it’s a CLI + optional vs code extension.

I’ve used Cursor a good deal and also CC. The CC JetBrain extension replaces my code in the IDE, shows me a preview ans allows me to confirm, decline, etc. Am I missing something super specific about Cursor’s behavior? It doesn’t seem that practically different to me.

Copilot in vscode is so bad about typescript errors as well.

You mentioned that Claude Code is fully agentic.

I am using the Cursor agent mode, which can run in auto mode with, let's say, 50 consecutive tool calls, along with editing and other tasks. It can operate autonomously for 30 minutes and complete a given task. I haven't tried Claude Code yet, but I'm curious—what exactly does Claude Code do differently compared to the Cursor agent?

Is the improvement in diff quality solely because Cursor limits the context size, or are there other factors involved?

I'd suggest to just give it a shot and notice the difference, it's night and day.

I couldn't get cursor agent to do useful stuff for me - might be because I don't do TS or Python - and Claude Code was a big productivity boost almost from day one. You just tell it to do stuff, and it just... does it. At like the level of a college student.

I'm writing TS and I was not very happy with Cursor - I expected more coming from using Cline + Sonnet in VS Code. I tried the composer or how do they call it, and the results were mediocre. After few hours of struggling I gave up and returned to Cline. Now with Claude Code I got much more value right from the start. I don't know, maybe I was "holding it wrong".

Cursor does a lot of trickery to reduce context size, since they ultimately have to pay per token even if you pay them a flat fee. Cline, on the other hand, is quite profligate with context, but the results are correspondingly better, especially when paired with Gemini due to its large max context.

"infrantry"

I think you meant "infancy"

Not sure what you mean, cursor has agents, that run in feedback cycles, checking e.g syntax errors before continuing, reflecting, working for minutes if need be, can execute commands in your terminal, check any file it wants. What can cc do that cursor can't, at least in theory?

I've had Claude Code run for many hours, and also let it manage its own sub-agents. Productively.

Coming back to an implementation that has good test coverage, functions exactly as specified, and is basically production-ready is achievable through planning/specs.

Maybe Cursor can do this now as well, but it was just so far behind last time I tried it.

> but Claude Code is like a junior developer.

This has been exactly my experience. I guess one slightly interesting thing is that my “junior developer” here will get better with time, but not because of me.

Do you have details on what "optimise for token usage" looks like in Cursor? Or is your point more about how Cursor manages the context window?

Cursor does all that stuff too perfectly fine.