Hi all! Graphite cofounder Greg here - happy to help answer questions. To preempt one: I’ve been asked a few times so far why we decided to join.
Personally, I work on Graphite for two reasons. 1) I love working with kind, smart, intense teammates. I want to be surrounded by folks who I look up to and who energize me. 2) I want to build bleeding-edge dev tools that move the whole industry forward. I have so much respect for all y’all across the world, and nothing makes me happier than getting to create better tooling for y’all to engineer with. Graphite is very much the combination of these two passions: human collaboration and dev tools.
Joining Cursor accelerates both these goals. I get to work with the same team I love, a new bunch of wonderful people, and get to keep recruiting as fast as possible. I also get to keep shipping amazing code collaboration tooling to the industry - but now with more resourcing and expertise. We get to be more ambitious with our visions and timelines, and pull the future forward.
I wouldn’t do this if I didn’t think the Cursor team weren’t standup people with high character and kindness. I wouldn’t do this if I thought it meant compromising our vision of building a better generation of code collaboration tooling. I wouldn’t do it if I thought it wouldn’t be insanely fun and exciting. But it seems to be all those things, so we’re plunging forward with excitement and open hearts!
As someone who loves all the non-AI portions of Graphite (the CLI and the reviewer UI) should I be worried about this acquisition? Or will the CLI and Reviewer Ui continue to be be maintained and improved?
Congrats!! I see this as two great companies joining forces in a crowded space where it is clear the whole is worth more than the sum of their parts. Best of luck on your journey
Makes sense and appreciate the transparency. Have admired what you're building at Graphite and look forward to seeing what you build as part of the Cursor team. Congrats!
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 wrong.
But that's just usability and preference. When the SOTA model makers give out tokens for substantially less than public API cost, how in the world is Cursor going to stay competitive? The moat just isn't there (in fact I would argue its non-existent)
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 clearly charging a premium for it and making a healthy margin on it, but for how fast + good it's totally worth it.
Composer 1 + now eventually creating an AI native version of GitHub with Graphite, that's a serious business, with a much clearer picture to me how Cursor gets to serious profitability vs the AI labs.
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 cohesive overall product through their vertical integration, and I just did the jump (it's easy to migrate) and can't go back.
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.
One of the biggest values for Cursor is getting all these different models under a single contract. A contract that very importantly covers the necessary data privacy we want as a business. We can be sure that no matter which model a developer chooses to use, we are covered under the clauses that disallow them from retaining and training on our conversations.
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.
What I don't understand why people would go all in on one IDE/editor and refuse to make plugins for others. Whether you prefer the CLI or the integrated experience, only offering it on vscode (and a shitty version of it, as well) is just stupid.
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.
> 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
Fascinating.
As a person who *loathes VS Code* and prefers terminal text editors, I find Cursor great!
Maybe because that I have zero desire to customize/leverage Cursor/VS Code.
Neat. Cursor can do what it wants with it, and I can just lean into that...
> The fact it's a fork of VSCode (or whatever) will make me never use it
Are you sure entire opinion is not just centred around that fact? Sounds like it
The UX of IDE integration with the existing VSCode plugins and file manager… it’s not even close to the same. Some people just get comfortable with what they are comfortable with
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.
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.
I think calling Open AI Codex or Claude Code "CLI" is a bit a of minomer. It's more of a GUI, just rendered in a terminal. I honestly think a "regular" for GUI for OpenAI Codex / Claude Code could be much better.
Cursor is better suited for enterprise. You get centralized stats and configuration management. Managers are pushed for AI uptake, productivity and quality metrics. Cursor provides them.
Virtually anybody going all in AI is exposing itself of being redundant.
I don't envy startups in the space, there's no moat be it cursor or lovable or even larger corps adopting ai. What's the point of Adobe when creating illustrations or editing pics will be embedded (kinda is already) in the behemoth's chat it's?
And please don't tell me that hundreds of founder became millionaires or have great exits or acquihires expecting them. I'm talking about "build something cool that will last".
If these ai companies had 100x dev output, why would you acquire a company? Why not just show screenshots to your agent and get it to implement everything?
Is it market share? Because I don't know who has a bigger user base that cursor.
The claims are clearly exaggerated or as you say, we'd have AI companies pumping out new AI focused IDEs left and right, crazy features, yet they all are Vs code forks that roughly do the same shit
A VSCode fork with AI, like 10 other competitors doing the same, including Microsoft and Copilot, MCPs, Vs code limitations, IDEs catching up. What do these AI VsCode forks have going for them? Why would I use one?
Heyo, disclosure that I work for graphite, and opinions expressed are my own, etc.
Graphite is a really complicated suite of software with many moving pieces and a couple more levels of abstraction than your typical B2B SaaS.
It would be incredibly challenging for any group of people to build a peer-level Graphite replacement any faster than it took Graphite to build Graphite, no matter what AI assistance you have.
My guess is the purchase captures the 'lessons learned' based upon production use and user feedback.
What I do not understand is that if a high level staff with capacity can produce an 80% replacement why not assign the required staff to complete that last 10% to bring it to production readiness? That last 10% is unnecessary features and excess outside of the requirements.
I hate the unrealistic AI claims about 100X output as much as anyone, but to be fair Cursor hasn't been pushing these claims. It's mostly me-too players and LinkedIn superstars pushing the crazy claims because they know triggering people is an easy ticket to more engagement.
The claims I've seen out of the Cursor team have been more subtle and backed by actual research, like their analysis of PR count and acceptance rate: https://cursor.com/blog/productivity
So I don't think Cursor would have ever claimed they could duplicate a SaaS company like Graphite with their tools. I can think of a few other companies who would make that claim while their CEO was on their latest podcast tour, though.
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!
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-based review step. The prompt would ask the reviewer to behave like a senior engineer or architect, follow common industry review standards, and return structured feedback - explicitly separating must-have issues from nice-to-have improvements.
The output would be generated as markdown and posted back to the PR, either as a comment or some attached artifact, so it’s visible alongside human review. The intent isn’t to replace human reviewers, but to catch obvious issues early and reduce review load.
What I’m unsure about is whether diff-only context is actually sufficient for meaningful reviews, or if this becomes misleading without deeper repo and architectural awareness. I’m also concerned about failure modes - for example, noisy or overconfident comments, review fatigue, or teams starting to trust automated feedback more than they should.
If you’ve tried something like this with Bitbucket/Jenkins, or think this is fundamentally a bad idea, I’d really like to hear why. I’m especially interested in practical lessons.
> What I’m unsure about is whether diff-only context is actually sufficient for meaningful reviews, or if this becomes misleading without deeper repo and architectural awareness.
The results of a diff-only review won't be very good. The good AI reviewers have ways to index your codebase and use tool searches to add more relevant context to the review prompt. Like some of them have definitely flagged legit bugs in review that were not apparent from the diff alone. And that makes a lot of sense because the best human reviewers tend to have a lot of knowledge about the codebase, like "you should use X helper function in Y file that already solves this".
At $DAYJOB, there's an internal version of this, which I think just uses Claude Code (or similar) under the hood on a checked out copy of the PR.
Then it can run `git diff` to get the diff, like you mentioned, but also query surrounding context, build stuff, run random stuff like `bazel query` to identify dependency chains, etc.
They've put a ton of work into tuning it and it shows, the signal-to-noise ratio is excellent. I can't think of a single time it's left a comment on a PR that wasn't a legitimate issue.
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.
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.
We have coding agents heavily coupled with many aspects of the company's RnD cycle. About 1k devs.
Yes, you definitely need the project's context to have valuable generations. Different teams here have different context and model steering, according to their needs.
For example, specific aspects of the company's architecture is supplied in the context. While much of the rest (architecture, codebases, internal docs, quarterly goals) are available as RAG.
It can become noisy and create more needless review work. Also, only experts in their field find value in the generations. If a junior relies on it blindly, the result is subpar and doesn't work.
I wonder about this. Graphite is a fantastic tool that I use every day. Cursor was an interesting IDE a year ago that I don't really see much of a use case for anymore. I know they've tried to add other features to diversify their business, and that's where Graphite fits in for them, but is this the best exit for Graphite? It seems like they could have gotten further on their own, instead of becoming a feature that Cursor bought to try to stay in the game.
How does Graphite compare with other AI code review tools like Qodo?
My team has been using Qodo for a while now and i've found it to be pretty helpful. EVery once in a while it finds a serious issue, but the most useful part from my experience are the features that are geared towards speeding up my review rather than replacing it. Things like effort labels that are automatically added to the pr and a generated walk through that takes you through all of the changed files.
Would love to see a detailed comparison of the different options. Is there some kind of benchmark for AI code review that compares tools?
Took me a month to learn jujutsu. Was initially a skeptic but pulled through. Git was always easy to me. Its model somehow just clicks in my brain. So when I first switched to jj, it made a lot of easy things hard due to the lack of staging (which is often part of my workflow). But now I see the value & it really does make hard things easy. My commit history is much cleaner for one.
I was scared to learn but then a coworker taught me the 4 commands I care about (jj new, jj undo, jj edit, jj log) and now I can't imagine going back to plain git.
Obviously the working tree should be a commit like any other! It just makes sense!
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.
Love this announcement style. Direct, confident, and not a word longer than it needs to be. Gives major "the work speaks for itself" vibes. OpenAI's comms used to be like this, until it morphed into Apple-like grandiosity that instead comes off as try-hard.
i mentioned a few months ago that it was a shame where graphite was headed re: AI (https://news.ycombinator.com/item?id=44955187). this appears to be the final nail in the original products coffin
for anyone else looking for a replacement, git spice and jujutsu are both fantastic
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.
I've been using git spice (https://abhinav.github.io/git-spice/) for the stacked PRs part of graphite and it's been working pretty well and it's open source and free.
Woahhhhh I missed this. Got a reference or link? My Googling is failing me. That's my biggest complaint about Github coming from Gerrit for Open Stack.
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.
I have gotten code reviews from OoenAI's Codex integration that do point out meaningful issues, including across files and using significant context from the rest of the app.
Sometimes they are things I already know but was choosing to ignore for whatever reason. Sometimes it's like "I can see why you think this would be an issue, but actually it's not". But sometimes it's correct and I fix the issue.
I just looked through a couple of PRs to find a concrete example. I found a PR review comment from Codex pointing out a genuine big where I was not handling a particular code path. I happened to know that no production data would trigger that code path as we had migrated away from it. It acted as a prompt to remove some dead code.
There are two Graphite companies. The time series DB for metrics (not this) and the stacked diff code review platform (this). Looking at other comments under the post, they seem to have executed a hard AI pivot recently.
Why doesn't Cursor allow selecting a LLM for code completion in the UI anymore and forces "auto" everywhere now? I have a Pro account and noticed this started like a month ago, and the "auto" output was often garbage, not following the instructions.
This is an example of an AI project not working out and getting consumed by a higher wrung in the pyramid. Who will consume Anthropic later? Can’t wait to find out
Good news. Been using Cursor heavily for over a year now (on the Ultra plan currently). Hope we get access to this as part of our existing subscriptions.
Are there thoughts on getting to something more like a "single window dev workflow"? The code editing and reviewing experiences are very disjoint, generally speaking.
My other question is whether stacked PRs are the endpoint of presenting changes or a waypoint to a bigger vision? I can't get past the idea that presenting changes as diffs in filesystem order is suboptimal, rather than as stories of what changed and why. Almost like literate programming.
This is annoying, Graphite's core feature of stacked PRs is really good despite all the AI things they've added around their review UI. I doubt we'll want to keep relying on that for very long now.
You can still think of AI as one facet of Graphite's product that you can use or not depending on your work style. Stacked PRs are still a core piece and not going anywhere :)
Never heard of graphite before today. Were they built specifically for AI code reviews or it's a pivot / new feature from a company that started with something else?
fosterfriends|2 months ago
Personally, I work on Graphite for two reasons. 1) I love working with kind, smart, intense teammates. I want to be surrounded by folks who I look up to and who energize me. 2) I want to build bleeding-edge dev tools that move the whole industry forward. I have so much respect for all y’all across the world, and nothing makes me happier than getting to create better tooling for y’all to engineer with. Graphite is very much the combination of these two passions: human collaboration and dev tools.
Joining Cursor accelerates both these goals. I get to work with the same team I love, a new bunch of wonderful people, and get to keep recruiting as fast as possible. I also get to keep shipping amazing code collaboration tooling to the industry - but now with more resourcing and expertise. We get to be more ambitious with our visions and timelines, and pull the future forward.
I wouldn’t do this if I didn’t think the Cursor team weren’t standup people with high character and kindness. I wouldn’t do this if I thought it meant compromising our vision of building a better generation of code collaboration tooling. I wouldn’t do it if I thought it wouldn’t be insanely fun and exciting. But it seems to be all those things, so we’re plunging forward with excitement and open hearts!
momentsinabox|2 months ago
jjmarr|2 months ago
bostonvaulter2|2 months ago
julianozen|2 months ago
nadis|2 months ago
sam_s|2 months ago
andsoitis|2 months ago
barfoure|2 months ago
Somebody screenshot this please. We are looking at comedy gold in the next 3 years and there’s no shortage of material.
bangaladore|2 months ago
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 wrong.
But that's just usability and preference. When the SOTA model makers give out tokens for substantially less than public API cost, how in the world is Cursor going to stay competitive? The moat just isn't there (in fact I would argue its non-existent)
jonathannorris|2 months ago
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 clearly charging a premium for it and making a healthy margin on it, but for how fast + good it's totally worth it.
Composer 1 + now eventually creating an AI native version of GitHub with Graphite, that's a serious business, with a much clearer picture to me how Cursor gets to serious profitability vs the AI labs.
archon810|2 months ago
Now, would I prefer to use vs code with an extension instead? Yes, in the perfect world. But Cursor makes a better, more cohesive overall product through their vertical integration, and I just did the jump (it's easy to migrate) and can't go back.
bloppe|2 months ago
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.
ziml77|2 months ago
infecto|2 months ago
gcbirzan|2 months ago
xenodium|2 months ago
Even Emacs nuts like me can use agents natively from our beloved editor ;) https://xenodium.com/agent-shell-0-25-updates
tukantje|2 months ago
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.
modeless|2 months ago
Also Cursor's dataset of actual user actions in coding and review is pure gold.
realityfactchex|2 months ago
Fascinating.
As a person who *loathes VS Code* and prefers terminal text editors, I find Cursor great!
Maybe because that I have zero desire to customize/leverage Cursor/VS Code.
Neat. Cursor can do what it wants with it, and I can just lean into that...
dmix|2 months ago
Are you sure entire opinion is not just centred around that fact? Sounds like it
The UX of IDE integration with the existing VSCode plugins and file manager… it’s not even close to the same. Some people just get comfortable with what they are comfortable with
ekropotin|2 months ago
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.
wilg|2 months ago
Palmik|2 months ago
malfist|2 months ago
mstump|2 months ago
IncRnd|2 months ago
epolanski|2 months ago
I don't envy startups in the space, there's no moat be it cursor or lovable or even larger corps adopting ai. What's the point of Adobe when creating illustrations or editing pics will be embedded (kinda is already) in the behemoth's chat it's?
And please don't tell me that hundreds of founder became millionaires or have great exits or acquihires expecting them. I'm talking about "build something cool that will last".
jammo|2 months ago
[deleted]
gravypod|2 months ago
Is it market share? Because I don't know who has a bigger user base that cursor.
Bridged7756|2 months ago
A VSCode fork with AI, like 10 other competitors doing the same, including Microsoft and Copilot, MCPs, Vs code limitations, IDEs catching up. What do these AI VsCode forks have going for them? Why would I use one?
gen220|2 months ago
Graphite is a really complicated suite of software with many moving pieces and a couple more levels of abstraction than your typical B2B SaaS.
It would be incredibly challenging for any group of people to build a peer-level Graphite replacement any faster than it took Graphite to build Graphite, no matter what AI assistance you have.
pizzafeelsright|2 months ago
What I do not understand is that if a high level staff with capacity can produce an 80% replacement why not assign the required staff to complete that last 10% to bring it to production readiness? That last 10% is unnecessary features and excess outside of the requirements.
Aurornis|2 months ago
I hate the unrealistic AI claims about 100X output as much as anyone, but to be fair Cursor hasn't been pushing these claims. It's mostly me-too players and LinkedIn superstars pushing the crazy claims because they know triggering people is an easy ticket to more engagement.
The claims I've seen out of the Cursor team have been more subtle and backed by actual research, like their analysis of PR count and acceptance rate: https://cursor.com/blog/productivity
So I don't think Cursor would have ever claimed they could duplicate a SaaS company like Graphite with their tools. I can think of a few other companies who would make that claim while their CEO was on their latest podcast tour, though.
dbgrman|2 months ago
Also, graphite isn't just "screenshots"; it's a pretty complicated product.
dcre|2 months ago
scotty79|2 months ago
Angostura|2 months ago
timvdalen|2 months ago
adamors|2 months ago
archon810|2 months ago
My usually prefer Gemini but sometimes other tools catch bugs Gemini doesn't.
As someone who has never heard of Graphite, can anyone share their experience comparing it to any of the tools above?
paradox460|2 months ago
tomasreimers|2 months ago
fosterfriends|2 months ago
scottydelta|2 months ago
> After bringing features of Supermaven to Cursor Tab, we now recommend any existing VS Code users to migrate to Cursor.
Supermaven was acquired by Cursor and sunset after 1 year.
ravirajx7|2 months ago
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-based review step. The prompt would ask the reviewer to behave like a senior engineer or architect, follow common industry review standards, and return structured feedback - explicitly separating must-have issues from nice-to-have improvements.
The output would be generated as markdown and posted back to the PR, either as a comment or some attached artifact, so it’s visible alongside human review. The intent isn’t to replace human reviewers, but to catch obvious issues early and reduce review load.
What I’m unsure about is whether diff-only context is actually sufficient for meaningful reviews, or if this becomes misleading without deeper repo and architectural awareness. I’m also concerned about failure modes - for example, noisy or overconfident comments, review fatigue, or teams starting to trust automated feedback more than they should.
If you’ve tried something like this with Bitbucket/Jenkins, or think this is fundamentally a bad idea, I’d really like to hear why. I’m especially interested in practical lessons.
trevor-e|2 months ago
The results of a diff-only review won't be very good. The good AI reviewers have ways to index your codebase and use tool searches to add more relevant context to the review prompt. Like some of them have definitely flagged legit bugs in review that were not apparent from the diff alone. And that makes a lot of sense because the best human reviewers tend to have a lot of knowledge about the codebase, like "you should use X helper function in Y file that already solves this".
abound|2 months ago
Then it can run `git diff` to get the diff, like you mentioned, but also query surrounding context, build stuff, run random stuff like `bazel query` to identify dependency chains, etc.
They've put a ton of work into tuning it and it shows, the signal-to-noise ratio is excellent. I can't think of a single time it's left a comment on a PR that wasn't a legitimate issue.
gen220|2 months ago
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.
baq|2 months ago
0xedd|2 months ago
Yes, you definitely need the project's context to have valuable generations. Different teams here have different context and model steering, according to their needs. For example, specific aspects of the company's architecture is supplied in the context. While much of the rest (architecture, codebases, internal docs, quarterly goals) are available as RAG.
It can become noisy and create more needless review work. Also, only experts in their field find value in the generations. If a junior relies on it blindly, the result is subpar and doesn't work.
AlexB138|2 months ago
outofdistro|2 months ago
My team has been using Qodo for a while now and i've found it to be pretty helpful. EVery once in a while it finds a serious issue, but the most useful part from my experience are the features that are geared towards speeding up my review rather than replacing it. Things like effort labels that are automatically added to the pr and a generated walk through that takes you through all of the changed files.
Would love to see a detailed comparison of the different options. Is there some kind of benchmark for AI code review that compares tools?
AbraKdabra|2 months ago
nozzlegear|2 months ago
https://www.merriam-webster.com/dictionary/graphite
AbstractH24|2 months ago
spooky_action|2 months ago
acheong08|2 months ago
ninjha|2 months ago
Obviously the working tree should be a commit like any other! It just makes sense!
wrs|2 months ago
Phlogistique|2 months ago
paradox460|2 months ago
tomasreimers|2 months ago
baq|2 months ago
fosterfriends|2 months ago
gk1|2 months ago
hzia|2 months ago
Huge fans of their work @ GitStart!
rileymichael|2 months ago
for anyone else looking for a replacement, git spice and jujutsu are both fantastic
2gremlin181|2 months ago
knes|2 months ago
Then Cursor takes on GitHub for the control of the repo.
jacobegold|2 months ago
novoreorx|2 months ago
dvtkrlbs|2 months ago
chucknthem|2 months ago
dcre|2 months ago
servercobra|2 months ago
unknown|2 months ago
[deleted]
asdev|2 months ago
epolanski|2 months ago
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.
crabmusket|2 months ago
Sometimes they are things I already know but was choosing to ignore for whatever reason. Sometimes it's like "I can see why you think this would be an issue, but actually it's not". But sometimes it's correct and I fix the issue.
I just looked through a couple of PRs to find a concrete example. I found a PR review comment from Codex pointing out a genuine big where I was not handling a particular code path. I happened to know that no production data would trigger that code path as we had migrated away from it. It acted as a prompt to remove some dead code.
hamdingers|2 months ago
geoffbp|2 months ago
arthur-st|2 months ago
joecool1029|2 months ago
Looks bad: https://forum.cursor.com/t/font-on-the-website-looks-weird/1...
storus|2 months ago
debo_|2 months ago
unknown|2 months ago
[deleted]
nottorp|2 months ago
Is corporate English becoming a form of newspeak and will significantly diverge from regular English over the next 100 years?
matt3210|2 months ago
mat_b|2 months ago
unknown|2 months ago
[deleted]
tomasreimers|2 months ago
acjohnson55|2 months ago
My other question is whether stacked PRs are the endpoint of presenting changes or a waypoint to a bigger vision? I can't get past the idea that presenting changes as diffs in filesystem order is suboptimal, rather than as stories of what changed and why. Almost like literate programming.
Areibman|2 months ago
pm90|2 months ago
elsigh|2 months ago
mcintyre1994|2 months ago
dbalatero|2 months ago
WXLCKNO|2 months ago
jacobegold|2 months ago
unknown|2 months ago
[deleted]
qudat|2 months ago
jjmarr|2 months ago
hunterbrooks|2 months ago
- Hunter @ Ellipsis
mlutsky1231|2 months ago
1317|2 months ago
what does graphite have to do with code review?
Bayko|2 months ago
smb06|2 months ago
promiseofbeans|2 months ago
saraverdi7|2 months ago
fractalnetworks|2 months ago
raincole|2 months ago
seemaze|2 months ago
eduardogarza|2 months ago
AbstractH24|2 months ago
nextworddev|2 months ago
alexgotoi|2 months ago
[deleted]
starkiller|2 months ago
[deleted]
gk1|2 months ago