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

101–110 of 264 posts

Re: Graphite is joining Cursor

#101

Post by baq »

ravirajx7 wrote: post #51

I’m working on something in a similar direction and would appreciate feedback from people who’ve built or operated this kind of thing at scale. The idea is to hook into Bitbucket PR webhooks so that whenever a PR is raised on any repo, Jenkins spins up an isolated job that acts as an automated code reviewer. That job would pull the base branch and the feature branch, compute the diff, and use that as input for an AI-…

cursor has a reviewer product which works quite well indeed, though I've only used it with github. not sure how they manage context, but it finds issues that the diff causes well outside the diff.

Re: Graphite is joining Cursor

#102

Post by samhh »

ninjha wrote: post #87
Phlogistique wrote: post #63

Earlier quoted context omitted.

Well, Graphite solves the problem of how to keep your stack of GitHub pull requests in sync while you squash merge the lowest pull request in the stack; which as far as I know jujutsu does not help with.

jj-spr solves this, although it is still pretty buggy: https://github.com/LucioFranco/jj-spr

There’s also jj-stack. I don’t know how they compare.

This is something GitHub should be investing time in, it’s so frustrating.

Re: Graphite is joining Cursor

#103

Post by mckn1ght »

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…

Mobile developer here. I historically am an emacs user so am used to living in a terminal shell. My current setup is a split pane terminal with one half running claude and the other running emacs for light editing and magit. I run one per task, managed by git worktrees, so I have a bunch of these terminals going simultaneously at any given time, with a bunch of fish/tmuxinator automation including custom claude commands. I pop over to Xcode if I need to dig further into something.

I’ve tried picking up VSCode several times over the last 6-7 years but it never sticks for me, probably just preference for the tools I’m already used to.

Xcode’s AI integration has not gone well so far. I like being able to choose the best tool for that, rather than a lower common denominator IDE+LLM combination.

Re: Graphite is joining Cursor

#104

Post by CharlieDigital »

nusl wrote: post #68
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…

OP isn't saying to do all of your work in the terminal; they're saying they prefer CLI-based LLM interfaces. You can have your IDE running alongside it just fine, and the CLIs can often present the changes as diffs in the IDEs too.

This is how some folks on my team work. Ran into this when I saved a file manually and the editor ran formatting on it. Turns out that the dev that wrote it only codes via CLI though reviews the files in an IDE so he never manually saved it and ran the formatter.

Re: Graphite is joining Cursor

#105

Post by bmelton »

infecto wrote: post #79
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 struggle with understand why engineers enjoy using these CLI coding tools so much. I have tried a few times and I simply cannot get into a good workflow. Cursor, Kline and others feel like the sweet spot for me.

As an older engineer, I prefer CLI experiences to avoid mouse usage. The more I use the mouse, the more I notice repetitive stress injury symptoms

But also, 90% of the time if I'm using an IDE like VSCode, I spend most of my time trying to configure it to behave as much like vim as possible, and so a successful IDE needn't be anything other than vim to me, which already exists on the terminal

Re: Graphite is joining Cursor

#106

Post by spruce_tips »

bangaladore wrote: post #82
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…

As the other commenter stated, I don't use CLIs for development. I use VSCode. I'm very pro IDE. I've built up an entire collection of VSCode extensions and workflows for programming, building, customizing build & debugging embedded systems within VSCode. But I still prefer CLI based AI (when talking about an agent to the IDE version). > Composer 1 My bet is their model doesn't realistically compare to any of the fro…

composer 1 has been my most used model the past few months. but i only use it to execute plans that i write with the help of larger, more intelligent models like opus 4.5. composer 1 is great at following plan instructions so after some careful time providing the right context and building a plan, it basically never messes up the implementation. sometimes requires a few small tweaks around the edges but overall a fantastic workflow that's so delightfully fast

Re: Graphite is joining Cursor

#107

Post by 2gremlin181 »

IMO this is a smart move. A lot of these next-gen dev tools are genuinely great, but the ecosystem is fragmented and the subscriptions add up quickly. If Cursor aquires a few more, like Warp or Linear, they can become a very compelling all-in-one dev platform.

Re: Graphite is joining Cursor

#108

Post by forgetfulness »

fosterfriends wrote: post #12
timvdalen wrote: post #4

I'm really used to my Graphite workflow and I can't imagine going without it anymore. An acquisition like this is normally not good news for the product.

Heard on the worry, but I can confirm Graphite isn’t going anywhere. We're doubling down on building the best workflow, now with more resourcing than ever before!

https://ourincrediblejourney.tumblr.com/

Re: Graphite is joining Cursor

#109

Post by atomicUpdate »

CharlieDigital wrote: post #104
nusl wrote: post #68

Earlier quoted context omitted.

OP isn't saying to do all of your work in the terminal; they're saying they prefer CLI-based LLM interfaces. You can have your IDE running alongside it just fine, and the CLIs can often present the changes as diffs in the IDEs too.

This is how some folks on my team work. Ran into this when I saved a file manually and the editor ran formatting on it. Turns out that the dev that wrote it only codes via CLI though reviews the files in an IDE so he never manually saved it and ran the formatter.

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.

Re: Graphite is joining Cursor

#110

Post by ekropotin »

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.

Post reply on HN