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

121–130 of 264 posts

Re: Graphite is joining Cursor

#121

Post by infecto »

ziml77 wrote: post #89
infecto wrote: post #79

Earlier quoted context omitted.

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.

It's really nice that the integrated nature means that, with no extra work on my part, the agent can see exactly what I'm seeing including the active file and linter errors. And all the model interaction is unified. I point them to specific files in the same way, they all have access to the same global rules (including team-global rules), documentation is supplied consistently, and I can seamlessly switch between mod…

That has been my experience as well. When I am prompting an agent it is using my open tabs first. When changes are made I get green and red lines and quickly can digest the difference. I don’t want it going off building a big feature form start to finish. I want to maybe use an AI to map out a plan but then go through each logical step of the implementation. I can quickly review changes and at least for me have the context of what’s happening.

Re: Graphite is joining Cursor

#122

Post by gen220 »

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-…

I work at Graphite, our reviewer is embedded into a bigger-scope code review workflow that substitutes for the GH PR Page.

You might want to look at existing products in this space (Cursor's Bugbot, Graphite's Reviewer FKA Diamond, Greptile, Coderabbit etc.). If you sign up for graphite and link a test github repo, you can see what the flow feels like for yourself.

There are many 1000s of engineers who already have an AI reviewer in their workflow. It comments as a bot in the same way dependabot would. I can't share practical lessons, but I can share that I find it to be practically pretty useful in my day-to-day experience.

Re: Graphite is joining Cursor

#123

Post by epolanski »

asdev wrote: post #114

Does anyone get actual insightful reviews from these code review tools? From most people I've spoke with, it catches things like code complexity, linting, etc but nothing that actual relates to business logic because there's no way it could know about the business logic of the product

I built an LLM that has access to documentation before doing code reviews and forces devs to update it with each pr.

Needless to say, most see it as an annoyance not a benefit, me included.

It's not like it's useless but... people tend to hate reviewing LLM output, especially on something like docs that requires proper review (nope, an article and a product are different, an order and a delivery note are as well, and those are the most obvious..).

Code can be subpar or even gross but to the job, but docs cannot be subpar as they compound confusion.

I've even built a glossary to make sure the correct terms are used and kinda forced, but LLMs getting 95% right are less useful than getting 0, as the 5% tends to be more difficult to spot and tends to compound inaccuracies over time.

It's difficult, it really is, there's everything involved from behaviour to processes to human psychology to LLM instructing and tuning, those are difficult problems to solve unless your teams have budgets that allow you hiring a functional analyst that could double as a technical and business writer, and these figures are both rare and hard to sell to management. And then an LLM is hardly needed.

Re: Graphite is joining Cursor

#124

Post by tukantje »

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…

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.

Re: Graphite is joining Cursor

#125

Post by modeless »

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…

Tab complete is still useful and code review/suggesting changes can be better in a GUI than in a terminal. I think there is still a radically better code review experience that is yet to be found, and it's more likely to come from a new player like Cursor/Graphite than one of the giants.

Also Cursor's dataset of actual user actions in coding and review is pure gold.

Re: Graphite is joining Cursor

#126

Post by aabhay »

Phlogistique wrote: post #63
spooky_action wrote: post #26

Well, time to bite the bullet and learn jujutsu over the holidays

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 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 that can do it automatically, or one that gives you control over the process. For example, jj can often get tripped up with branch rules in git since you might accidentally move a bookmark that isn't yours to move, so to speak.

Re: Graphite is joining Cursor

#129

Post by jacobegold »

aabhay wrote: post #126
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 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`

Re: Graphite is joining Cursor

#130

Post by bangaladore »

infecto wrote: post #84
jstummbillig wrote: post #75

Earlier quoted context omitted.

Say more? It's the first time I see Composer 1 being talked about outside of the Cursor press stuff, with high praise no less. What are we talking about? Autocomplete or GPT/Claude contender or...? What makes it so great?

GPT contender. There has been talk on the cursor forums. I think largely people have e slept on coding models and stick with Anthropic thinking it’s the best. Composer fit that niche of extremely fast and smart enough. Sometimes you just want a model that has a near instant response. The new Gemini preview is overtaking my usage of Composer.

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.

Post reply on HN