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!
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
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?
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.
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.
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.
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.
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’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".
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)
> 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...
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 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.
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.
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.
> 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 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.
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.
68 comments
[ 5.4 ms ] story [ 84.7 ms ] threadPersonally, 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!
Somebody screenshot this please. We are looking at comedy gold in the next 3 years and there’s no shortage of material.
- Hunter @ Ellipsis
Huge fans of their work @ GitStart!
Is it market share? Because I don't know who has a bigger user base that cursor.
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.
Then Cursor takes on GitHub for the control of the repo.
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.
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".
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)
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...
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.
Even Emacs nuts like me can use agents natively from our beloved editor ;) https://xenodium.com/agent-shell-0-25-updates
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
> 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.