Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Graphite is joining Cursor

cursor.com

Post reply on HN
Print view View original

211–220 of 264 posts

Re: Graphite is joining Cursor

#211

Post by wilg »

bangaladore wrote: post #53

Imo Cursor did had the first mover advantage by making the first well known AI coding agent IDE. But I can't help but think they have no realistic path forward. As someone who is a huge IDE fan, I vastly prefer the experience from Codex CLI compared to having that built into my IDE, which I customize for my general purposes. The fact it's a fork of VSCode (or whatever) will make me never use it. I wonder if they bet…

I also would think Cursor would be screwed, but I tried out the Codex VS code extension and its still very barebones, and Cursor seems to update like 5 times a day and is constantly coming out with mostly great new features. Plus it is nice to be able to use any model provider.

Re: Graphite is joining Cursor

#212

Post by bloppe »

bangaladore wrote: post #53

Imo Cursor did had the first mover advantage by making the first well known AI coding agent IDE. But I can't help but think they have no realistic path forward. As someone who is a huge IDE fan, I vastly prefer the experience from Codex CLI compared to having that built into my IDE, which I customize for my general purposes. The fact it's a fork of VSCode (or whatever) will make me never use it. I wonder if they bet…

I think beginner programmers like the fact that they can just open one app and the AI chat box is right next to their editor window. Other than that, I agree that it's pretty silly to maintain a whole IDE just to attach an AI chat box to it.

Now that there's MCP, the community will out-innovate anything a single company can do in terms of bolting on features. It's easy enough to get all the LSP integration and stuff into Claude code.

So it all comes down to model differentiation. Can cursor compete as a foundation model creator? Maybe, but even so, that's going to be a very tough market. Margins will be razor thin at best. It's a commodity.

Anyway, the last thing I would want if I were them is to keep worrying about maintaining this IDE themselves.

Re: Graphite is joining Cursor

#213

Post by bloppe »

redox99 wrote: post #175
tukantje wrote: post #124

Earlier quoted context omitted.

Cursor still has the advantage UX wise. The biggest reason I avoid using them though is their pricing structure being abysmal. I can't randomly throw credits into a pit and say "oh 2000$ spent this month whatever". For larger businesses I suspect it is even worse. If they had a 200$ subscription with proper unlimited usage (within some limits obviously) I would have jumped up and down though.

I don't understand where $2000 comes from. Relatively heavy cursor usage in my experience is around 100USD/month. You can set a limit to on demand billing.

Even 100/mo is a lot when you can get unlimited Sonnet for 20/mo.

Re: Graphite is joining Cursor

#214

Post by bloppe »

ekropotin wrote: post #110
bangaladore wrote: post #53

Imo Cursor did had the first mover advantage by making the first well known AI coding agent IDE. But I can't help but think they have no realistic path forward. As someone who is a huge IDE fan, I vastly prefer the experience from Codex CLI compared to having that built into my IDE, which I customize for my general purposes. The fact it's a fork of VSCode (or whatever) will make me never use it. I wonder if they bet…

I personally use CLI coding agents as well, but many people do prefer tight IDE integration. I’ve tried every popular agent IDE, but none of them beat Cursor’s UX. Their team thought through many tiny UX details, making the whole experience smooth like a butter. I think it’s a huge market differentiator. Also their own composer model is not bad at all.

Which ux details come to mind?

Re: Graphite is joining Cursor

#215

Post by noodletheworld »

pjmlp wrote: post #185
aqme28 wrote: post #184

Earlier quoted context omitted.

> Yeah, hard disagree on that one, based on recent surveys, 80-90% of developers globally use IDEs over CLIs for their day-to-day work. This is a pretty dumb statistic in a vacuum. It was clearly 100% a few years ago before CLI-based development was even possible. The trend is very significant.

CLI based development predates IDEs for a couple of decades, and we moved away for very good reasons.

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.

Re: Graphite is joining Cursor

#216

Post by surajrmal »

dacox wrote: post #203
tombert wrote: post #201

Earlier quoted context omitted.

Forgive some ignorance, but we use Graphite at work, and I don't dislike it or anything, but I haven't really been able to see its appeal over just doing a PR within Github, at least if you exclude the AI stuff. What do you like about the non-AI parts? I mean it's a little convenient to be able to type `gt submit` in order to create the remote branch and the PR in one step, but it doesn't feel like anything that an a…

the stacked changes support, for me, was an absolute game changer. the auto rebasing, etc, is -really- nice. i found it especially useful for Gitops type stuff where you have to make lots of little PRs

Is it better than just using jj locally though?

Re: Graphite is joining Cursor

#217

Post by koreth1 »

jacobegold wrote: post #129
aabhay wrote: post #126

Earlier quoted context omitted.

jj is actually perfectly fit for this and many other problems. In fact, this is actually the default behavior for jj -- if you squash a bunch of jj commits, the bookmarks on top automatically point to the updated rev tree. Then when syncing the dependent branches to git they all rebase automatically. The problem however lies in who or what does this rebasing in a multi-tenant environment. You sort of need a system th…

Correct (Graphite eng here for context) - we've thought about extending our CLI to allow it to sync jj with GH pull requests to do exactly this. Essentially - similar workflow but use `jj` as the frontend instead of `gt`

Please do this! As a Graphite user, I'd love to be able to switch to jj for my local development, but the disconnect between it and Graphite keeps me away.

Re: Graphite is joining Cursor

#218

Post by yakattak »

archon810 wrote: post #57
bangaladore wrote: post #53

Imo Cursor did had the first mover advantage by making the first well known AI coding agent IDE. But I can't help but think they have no realistic path forward. As someone who is a huge IDE fan, I vastly prefer the experience from Codex CLI compared to having that built into my IDE, which I customize for my general purposes. The fact it's a fork of VSCode (or whatever) will make me never use it. I wonder if they bet…

As someone who uses Cursor, i don't understand why anyone would use CLI AI coding tools as opposed to tools integrated in the IDE. There's so much more flexibility and integration, I feel like I would be much less productive otherwise. And I say this as someone who is fluent in vim in the shell. Now, would I prefer to use vs code with an extension instead? Yes, in the perfect world. But Cursor makes a better, more co…

The Claude Code integration with IntelliJ (or any Jetbrains IDE for that matter) is the perfect combination. That is the perfect world to me. An entire company maintaining a fork of VS Code just doesn't compute to me, but its how you sell it to shareholders.

Re: Graphite is joining Cursor

#219

Post by simondotau »

Yoric wrote: post #173
santoriv wrote: post #140

Earlier quoted context omitted.

It is really good at grep and will make multiple grep calls in parallel. And when I open it in the parent directory of a bunch of repos in our codebase, it can very quickly trace data flow through a bunch of different services. It will tell me all the files the data goes through. It's context window is "only" 200k tokens. When it gets near 200k, it compresses the conversation and starts a new conversation..... which…

> It is really good at grep and will make multiple grep calls in parallel. How does that work? Multiple agents grepping simultaneously?

Presumably if it knows it needs to perform multiple searches in order to gather information (e.g. searching for redundant implementations of an algorithm, plus calls to the codebase's canonical implementation) it should be able to run those searches in parallel grep calls.

Re: Graphite is joining Cursor

#220

Post by trollbridge »

bhl wrote: post #167
jonathannorris wrote: post #65

Earlier quoted context omitted.

Yeah, hard disagree on that one, based on recent surveys, 80-90% of developers globally use IDEs over CLIs for their day-to-day work. I was pretty worried about Cursor's business until they launched their Composer 1 model, which is fine-tuned to work amazingly well in their IDE. It's significantly faster than using any other model, and it's clearly fine-tuned for the type of work people use Cursor for. They are also…

It does not matter what 80-90% of developers do. Code development is heavily tail-skewed: focus on the frontier and on the people who are able to output production-level code at a much higher pace than the rest.

No kidding. Arguing "90% of devs do this" makes it that much more likely that it's something that the bottom 90% of devs do.
Post reply on HN