_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Graphite is joining Cursor
rileymichael wrote 12 min ago:
i mentioned a few months ago that it was a shame where graphite was
headed re: AI ( [1] ). 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
HTML [1]: https://news.ycombinator.com/item?id=44955187
mat_b wrote 56 min ago:
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.
joecool1029 wrote 3 hours 2 min ago:
> The way developers write code looks different than it did a few years
ago.
Looks bad:
HTML [1]: https://forum.cursor.com/t/font-on-the-website-looks-weird/142...
geoffbp wrote 3 hours 22 min ago:
Confusing. I thought graphite was a TSDB
arthur-st wrote 13 min ago:
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.
promiseofbeans wrote 3 hours 35 min ago:
Oh, the code review system. I was worried that my favourite web svg
editor got bought up:
HTML [1]: https://graphite.rs/
asdev wrote 3 hours 47 min ago:
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
crabmusket wrote 1 hour 30 min ago:
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.
hamdingers wrote 2 hours 48 min ago:
Graphite is a pull request management interface more than it is an AI
code review tool.
2gremlin181 wrote 4 hours 4 min ago:
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.
scottydelta wrote 4 hours 39 min ago:
> Weâre sunsetting Supermaven after our acquisition one year 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.
AlexB138 wrote 5 hours 39 min ago:
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.
bangaladore wrote 5 hours 44 min ago:
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)
realityfactchex wrote 24 min 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
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...
IncRnd wrote 2 hours 20 min ago:
Cursor's cursor-agent can be run interactively from the CLI or
headless.
modeless wrote 3 hours 24 min ago:
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.
girvo wrote 1 hour 23 min ago:
God cursors tab complete is woeful in basically all of my usage at
work. Itâs so actively wrong that I turned it off. Itâs agent
flows are far far more useful to me
hn1986 wrote 26 min ago:
Glad i'm not the only one. I use SQL primarily and it is awful
and distracting
tukantje wrote 3 hours 24 min ago:
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.
ekropotin wrote 3 hours 56 min ago:
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.
ziml77 wrote 4 hours 50 min ago:
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.
infecto wrote 4 hours 54 min ago:
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.
bmelton wrote 4 hours 7 min ago:
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
infecto wrote 3 hours 34 min ago:
I use vs code mostly without a mouse same with most of my in IDE
AI usage.
ziml77 wrote 4 hours 42 min ago:
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 models in the same conversation.
infecto wrote 3 hours 32 min ago:
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.
gcbirzan wrote 5 hours 5 min ago:
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.
neutronicus wrote 2 hours 28 min ago:
Yeah! Integrate with emacs!
toddmorey wrote 4 hours 40 min ago:
Cursor if I recall actually started life as a VScode plugin. But
the plugin API didnât allow for the type of integration &
experiences they wanted. Hit limits quickly and then decided to
make a fork.
g947o wrote 4 hours 30 min ago:
Not to mention that VSCode has been creating many "experiemental"
APIs that are not formalized for years which become de facto
private APIs that only first party extensions have access to.
Good thing that Copilot is not the dominant tool people use these
days, which proves that (in some cases) if your product is good
enough, you can still win an unfair competition with Microsoft.
ninjha wrote 4 hours 55 min ago:
Codeium (now Windsurf) did this, and the plugins all still work
with normal Windsurf login. The JetBrains plugin and maybe a few
others are even still maintained! They get new models and bugfixes.
(I work at Windsurf but not really intended to be an ad Iâm just
yapping)
airstrike wrote 39 min ago:
Windsurf is at least 10x better than Cursor in my opinion... I'm
honestly still puzzled it doesn't seem to get as much buzz on HN!
I had to literally cmd+F to find a reference here and this is the
only comment ;-;
jonathannorris wrote 5 hours 18 min ago:
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.
freeone3000 wrote 17 min ago:
I use an IDE. It has a command line in it. It also has my keybinds,
build flow, editor preferences, and CI integrations. Making
something CLI means I can use it from my IDE, and possibly soon
with my IDE.
bhl wrote 23 min ago:
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.
the_mitsuhiko wrote 2 hours 23 min ago:
> 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 have absolutely no horse in this race, but I turned from a 100%
Cursor user at the beginning of the year, to one that basically
uses agents for 90% of my work, and VS Code for the rest of it.
The value proposition that Cursor gave me was not able to compete
with what the basic Max subscription on anthropic gave me, and VS
Code is still a superior experience to Claude in the IDE space.
I think though that Cursor has all the potential to beat Microsoft
at the IDE game if they focus on it. But I would say it's by no
way a given that this is the default outcome.
Sleaker wrote 1 hour 7 min ago:
How does company X dependant on company Y product beat company Y
in what is essentially just small UI differences? Can cursor even
do anything that vscode can't right now?
the_mitsuhiko wrote 50 min ago:
> Can cursor even do anything that vscode can't right now?
Right now VSCode can do things that Cursor cannot, but mostly
because of the market place. If Cursor invests money into the
actual IDE part of the product I can see them eclipsing
Microsoft at the game. They definitely have the momentum. But
at least some of the folks I follow on Twitter that were
die-hard Cursor users have moved back to VSCode for a variety
of reasons over the last few months, so not sure.
Microsoft itself though is currently kinda mismanaging the
entire product range between GitHub, VS Code and copilot, so I
would not be surprised if Cursor manages to capitalize on this.
bangaladore wrote 4 hours 48 min ago:
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
frontier models. And even if it did, it would become outdated very
quickly.
It seems somewhat clear (at least to me) that economics of scale
heavily favor AI model development. Spend billions making massive
models that are unusable due to cost and speed and distill their
knowledge + fine tune them for stuff like tools. Generalists are
better than specialists. You make one big model and produce 5
models that are SOTA in 5 different domains. Cursor can't do that
realistically.
spruce_tips wrote 4 hours 6 min ago:
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
santoriv wrote 4 hours 36 min ago:
> My bet is their model doesn't realistically compare to any of
the frontier models.
I've been using composer-1 in Cursor for a few weeks and also
switching back and forth between it, Gemini Flash 3, Claude Opus
4.5, Claude Sonnet 4.5 and GPT 5.2.
And you're right it's not comparable. It's about the same quality
of code output of the aforementioned models but about 4x as fast.
Which enables a qualitatively different workflow for me where
instead of me spending a bunch of time waiting on the model, the
model is waiting on me to catch up with its outputs. After using
composer-1, it feels painful to switch back to other models.
I work in a larg(ish) enterprise codebase. I spend a lot of time
asking it questions about the codebase and then making small
incremental changes. So it works very well for my particular
workflow.
Other people use CLI and remote agents and that sort of thing and
that's not really my workflow so other models might work better
for other people.
neutronicus wrote 2 hours 29 min ago:
Does it have some huge context window? Or is it really good at
grep?
The Copilot version of this is just fucking terrible at
suggesting anything remotely useful about our codebase.
I've had reasonable success just sticking single giant
functions into context and asking Sonnet 4.5 targeted questions
(is anything in this function modifying X, does this function
appear to be doing Y) as a shortcut for reading through the
whole thing or scattershot text search.
When I try to give it a whole file I actually hit single-query
token limits.
But that's very "opt-in" on my part, and different from how I
understand Cursor to work.
santoriv wrote 2 hours 15 min ago:
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 mostly works but sometimes it has a
bit of amnesia if you have a really long running conversation
on something.
Yoric wrote 4 min ago:
> It is really good at grep and will make multiple grep
calls in parallel.
How does that work? Multiple agents grepping
simultaneously?
nusl wrote 5 hours 17 min ago:
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.
CharlieDigital wrote 4 hours 7 min ago:
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.
whalesalad wrote 2 hours 39 min ago:
Part of a healthy codebase is ensuring that anyone can hack on
it, regardless of their editor setup. Relying on something in
.vscode and just assuming people are using that editor is what
leads to this kind of situation.
Bake that into the workflow some other way.
tyre wrote 3 hours 50 min ago:
allow me to introduce you to the lord and savior,
HTML [1]: https://pre-commit.com/
adamcharnock wrote 55 min ago:
Agreed. Also Lefthook:
HTML [1]: https://github.com/evilmartians/lefthook
atomicUpdate wrote 3 hours 57 min ago:
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.
archon810 wrote 5 hours 39 min ago:
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.
bhl wrote 24 min ago:
Multi-agents.
desireco42 wrote 55 min ago:
It is very easy to open multiple terminals, have them side by side,
do different things. It is more natural to invoke agents and let
them do their things.
sergiotapia wrote 1 hour 17 min ago:
I don't understand what you gain by using an "integrated IDE with
AI". No snark, really asking please share always eager to learn
better workflows.
I use VS Code, open a terminal with VS Code, run `claude` and keep
the git diff UI open on the left sidebar, terminal at the bottom.
lmeyerov wrote 1 hour 18 min ago:
Now that I can do a lot with 3-6 AI agents running usefully 2-5min
at a time to crank through my plans, the IDE is mostly just taking
valuable space
For backend/application code, I find it's instead about focusing on
the planning experience, managing multiple agents, and reviewing
generated artifacts+PRs. File browsers, source viewers, REPLs, etc
don't matter here (verbose, too zoomed-in, not reflecting agent
activity, etc), or at best, I'll look at occasionally while the
agents do their thing.
gnarcoregrizz wrote 2 hours 29 min ago:
I agree. I did most of my work in vim/cli (still often do), but the
tight agent integrations in the IDEs are hard to beat. I'm able to
see more in cursor (entire diffs), and it shows me all of the
terminal output, whereas Claude Code hides things from you by
default, by only showing you a few pieces and summaries of what it
did. I do prefer to use CC for cli usage though (e.g. using aws
cli, Kubernetes, etc). The tab-autocomplete is also excellent.
I also like how cursor is model-agnostic. I prefer codex for first
drafts (it's more precise and produces less code), for Claude when
less precision or planning is required, and other, faster models
when possible.
Also, one of cursor's best features is rollback. I know people have
some funky ways to do it in CC with git work trees etc, but it's
built into cursor.
zaphirplane wrote 2 hours 33 min ago:
Whatâs an example of? The only thing I can think of is providing
approval per section, but that doesnât really scale well
girvo wrote 1 hour 26 min ago:
And Claude Code run inside VSCode does as well. An extension to
give those extra integration features to a CLI agent to me is far
better.
mckn1ght wrote 4 hours 7 min ago:
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.
kleiba wrote 1 hour 31 min ago:
Emacs has a number of packages for AI integration which I haven't
tried yet. Have you?
ravirajx7 wrote 5 hours 45 min ago:
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.
trevor-e wrote 1 hour 30 min ago:
> 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".
abound wrote 5 hours 15 min ago:
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.
anon7000 wrote 4 hours 58 min ago:
Yeah, itâs exceptionally easy to set this up and we have the same
thing. Except the team hasnât had time to fine tune it, and it
shows.
AbraKdabra wrote 5 hours 46 min ago:
Startups should check the internet before naming them after tools like
Graphite for monitoring [1] .
HTML [1]: https://graphiteapp.org/
nozzlegear wrote 5 hours 44 min ago:
Graphite should check the dictionary before naming itself after a
soft, black, lustrous form of carbon.
HTML [1]: https://www.merriam-webster.com/dictionary/graphite
AbraKdabra wrote 5 hours 36 min ago:
Yeah well at least the OG graphite is not software.
nozzlegear wrote 5 hours 17 min ago:
Sure, but if the concern is googling "graphite" and finding
results that aren't the Graphite you're looking for, it's the
same problem. There will always be more results for graphite, the
mineral than graphite, the enterprise-ready monitoring tool.
If that's not the concern, then what's the big deal?
gk1 wrote 5 hours 47 min ago:
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.
knes wrote 5 hours 54 min ago:
Blacksmith.sh acquisition in 3, 2, 1 ...
Then Cursor takes on GitHub for the control of the repo.
gravypod wrote 5 hours 55 min ago:
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.
dcre wrote 48 min ago:
Who has claimed to have 100x productivity?
Aurornis wrote 1 hour 18 min ago:
> If these ai companies had 100x dev output,
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: [1] 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.
HTML [1]: https://cursor.com/blog/productivity
gen220 wrote 3 hours 36 min ago:
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.
manquer wrote 2 hours 12 min ago:
Itâs always faster and easier to copy than create(AI or not).
There is lot of thought and effort in doing it first, which the
second team(to an extent) can skip.
Much respect to what have you have achieved in a short time with
graphite.
A lot of B2B SaaS is about tones of integrations to poorly designed
and documented enterprise apps or security theatre, compliance,
fine grained permissions, a11y, i18n, air gapped deployments or
useless features to keep largest customers happy and so on and on.
Graphite (as yet) does not any of these problems - GitHub, Slack
and Linear are easy as integrations go, and there is limited
features for enterprises in graphite.
Enterprise SaaS is hard to do just for different type of complexity
gen220 wrote 38 min ago:
I think trivial GH integrations are easy.
If you've used Graphite as a customer for any reasonable period
of time or as part of a bigger enterprise/org and still think our
app's particular integration with GH is easy... I think that's
more a testament to the work we've done to hide how hard it is :)
Most of the "hard" problems we're solving (which I'm referencing
in my original comment) are not visually present in the CLI or
web application. It's actually subtle failure-states or
unavailability that you would only see if I'm doing my job
poorly.
I'm not talking about just our CLI tool or stacking, to clarify.
I'm talking about our whole suite, especially the review page and
merge queue.
What kind of enterprise SaaS features do you wish you had in
Graphite? (We have multiple orgs with 100s-1,000s of engineers
using us today!)
dbgrman wrote 4 hours 37 min ago:
Existing users, distribution, and brand are a big part of
acquisition. Graphite is used mainly by larger orgs.
Also, graphite isn't just "screenshots"; it's a pretty complicated
product.
pizzafeelsright wrote 4 hours 47 min ago:
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.
Bridged7756 wrote 5 hours 16 min ago:
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?
jjmarr wrote 6 hours 19 min ago:
If my company has an existing Cursor subscription, can we get Graphite
for free?
dvtkrlbs wrote 6 hours 20 min ago:
I guess this makes sense Github announced they are gonna bring stacked
PRs this year so I think that kinda makes Graphite obsolute.
chucknthem wrote 5 hours 14 min ago:
I've been using git spice ( [1] ) for the stacked PRs part of
graphite and it's been working pretty well and it's open source and
free.
HTML [1]: https://abhinav.github.io/git-spice/
servercobra wrote 6 hours 11 min ago:
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.
spooky_action wrote 6 hours 21 min ago:
Well, time to bite the bullet and learn jujutsu over the holidays
paradox460 wrote 1 hour 32 min ago:
Do it. It's absolutely worth it. You can pick it up in 30 minutes and
have full proficiency in an afternoon
ninjha wrote 4 hours 49 min ago:
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!
Phlogistique wrote 5 hours 29 min ago:
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.
aabhay wrote 3 hours 23 min ago:
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.
jacobegold wrote 2 hours 56 min ago:
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`
ninjha wrote 4 hours 44 min ago:
jj-spr solves this, although it is still pretty buggy:
HTML [1]: https://github.com/LucioFranco/jj-spr
samhh wrote 4 hours 9 min ago:
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.
paradox460 wrote 1 hour 31 min ago:
And tangled.sh supports JJ stacks out of the box
acheong08 wrote 6 hours 10 min ago:
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.
wrs wrote 6 hours 17 min ago:
Itâs not so much biting the bullet as eating the delicious
chocolate.
hzia wrote 6 hours 36 min ago:
Congrats team! Graphite was basically what GitHub should have been but
never was
Huge fans of their work @ GitStart!
tomasreimers wrote 6 hours 37 min ago:
Hi! Another one of the Graphite co-founders here. Alongside Greg, happy
to answer any questions :)
acjohnson55 wrote 5 hours 2 min ago:
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.
elsigh wrote 5 hours 7 min ago:
Congratulations Tomas!
pm90 wrote 5 hours 19 min ago:
Congrats on the acquisition! I know its early but would existing
cursor users get graphite for free/at a discount?
Areibman wrote 6 hours 5 min ago:
What's the main synergy between Cursor and Graphite that led you to
join? Stacked PRs? AI code review? Something else?
raincole wrote 6 hours 41 min ago:
I thought it were graphite.art and had a figurative heart attack.
seemaze wrote 5 hours 53 min ago:
Never used the tool being acquired, but just discovered the 2D design
tool from your comment, looks super cool!
mcintyre1994 wrote 6 hours 43 min ago:
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.
qudat wrote 3 hours 32 min ago:
check out a range-diff approach using patchsets:
HTML [1]: https://pr.pico.sh
dbalatero wrote 6 hours 31 min ago:
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 :)
victorvation wrote 23 min ago:
Except for the undismissable "Pay use more to enable AI reviews"
nag that Graphite places above your CI checks and assigned
reviewers.
jacobegold wrote 6 hours 33 min ago:
stacked prs will only get better from here :) we have an incredible
amount of resources to keep improving that part of our product.
WXLCKNO wrote 6 hours 41 min ago:
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?
David wrote 6 hours 35 min ago:
No, they've been doing "managing stacks of dependent pull requests"
for a lot longer than AI code review. I've mostly been a happy
user, they simplify a lot of the git pain of continually rebasing
and the UI makes stacks much easier to work with than Github's own
interface.
mcintyre1994 wrote 6 hours 36 min ago:
They started as a better PR review tool, with the main feature that
you can stack PRs that have dependencies on each other. It solves
the problem of having PRs merging into other PR branches, or having
notes not to merge something until another PR merges. Recently they
became an AI code review tool, and just added a bunch of AI tools
to the review UI, but you could just ignore it and the core
functionality was still great.
saraverdi7 wrote 6 hours 44 min ago:
two of my fave products under one roof? ok hell yeah
hunterbrooks wrote 6 hours 44 min ago:
congrats Greg, Merrill, and the rest of the folks at Graphite!
- Hunter @ Ellipsis
baq wrote 6 hours 48 min ago:
if my employer has a cursor sub, but not a graphite sub, will this news
free me from the demon's shackles from hell of github PRs?
fosterfriends wrote 6 hours 19 min ago:
This is my favorite question yet
timvdalen wrote 6 hours 51 min ago:
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.
paradox460 wrote 1 hour 34 min ago:
Our amazing journey...
archon810 wrote 5 hours 34 min ago:
We currently let loose Gemini, Cursor Bugbot, Qodo, and even Sentry
started reviewing PRs now.
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?
timvdalen wrote 2 hours 38 min ago:
I've never used Graphite's AI features, so I can't compare!
hagbarth wrote 4 hours 19 min ago:
Graphite predates AI code reviews. Obviously includes it now, but
the original selling point was support for stacking PRs.
mcintyre1994 wrote 4 hours 24 min ago:
Graphite isnât really about code review IMO, itâs actually
incredibly useful even if you just use the GitHub PR UI for the
actual review. Graphite, its original product anyway, is about
managing stacks of dependent pull requests in a sane way.
adamors wrote 5 hours 34 min ago:
I really wanted to give them a try actually, now I definitely
wonât.
fosterfriends wrote 6 hours 39 min ago:
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!
forgetfulness wrote 4 hours 1 min ago:
HTML [1]: https://ourincrediblejourney.tumblr.com/
twistedfred87 wrote 5 hours 43 min ago:
There is literally nothing anyone can say to convince me any
product or person is safe during an acquisition. Time and time
again it's proven to just not be true. Some manager/product
owner/VP/c-suite will eventually have the deciding factor and I
trust none of them to actually care about the product they're
building or the community that uses it
colesantiago wrote 5 hours 46 min ago:
> I can confirm Graphite isnât going anywhere...
sweet summer child.
moralestapia wrote 6 hours 5 min ago:
LOL. Just by bayesian logic this statement makes it more likely
that it will go to trash.
whimsicalism wrote 6 hours 15 min ago:
mhm
BoorishBears wrote 6 hours 29 min ago:
> Cursor acquires Supermaven.
> "Will the plugin remain up? Yes!"
>
HTML [1]: https://supermaven.com/blog/sunsetting-supermaven
firloop wrote 6 hours 35 min ago:
Supermaven said the same thing when they were acquired by Cursor
and then EOLed a year later. Honestly, it makes sense to me that
Cursor would shut down products it acquires - I just dislike
pretending that something else is happening.
jacobegold wrote 6 hours 28 min ago:
we are a 70 person team, bringing in significant revenue through
our product, have widespread usage at massive companies like
shopify robinhood etc, this is a MUCH MUCH MUCH different story
than supermaven (which I used myself and was sad to see go) which
was a tiny team with a super-early product when they got
acquired.
everyone is staying on to keep making the graphite product great.
we're all excited to have these resources behind us!
tyre wrote 8 min ago:
Obviously what you need to say but the reality is that youâre
not in control anymore. Thatâs what an acquisition is.
If Cursor wants to re-allocate resources or merge Graphite into
to editor or stagnate development and use it as a
marketing/lead gen channel, it will for the business.
Anything said at time of acquisition isnât trustworthy. Not
because people are lying at the time (I donât think you are!)
but because these deals give up leverage and control
explicitly. If they only wanted tighter integration, they could
fund that via equity investment or staffing engineers (+/-
paying Graphite to do the same.) Companies acquire for a reason
and it isnât to let the team + product stay independent
organsnyder wrote 5 hours 37 min ago:
Not your fault at all, but there is a ton of precedent to be
skeptical that these pronouncements end up being accurate.
delfinom wrote 5 hours 48 min ago:
I've seen big companies cleave off tens of millions of
profitable products on a whim pretty often....
saraverdi7 wrote 6 hours 33 min ago:
relax
rozap wrote 6 hours 2 min ago:
"trust me bro"
(6 months later)
"An update about your graphite workspaces"
zeroonetwothree wrote 6 hours 36 min ago:
Weâve heard this many times before with other acquisitions so
donât be upset if people are a bit skeptical.
fosterfriends wrote 7 hours 0 min ago:
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!
nadis wrote 3 hours 50 min ago:
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!
momentsinabox wrote 4 hours 23 min ago:
Really appreciate the tone of this post. We need more leaders
prioritizing words like love, kind, people, heart and character. Good
on you.
reply
jjmarr wrote 6 hours 50 min ago:
If my company has an existing Cursor subscription, can we get
Graphite for free?
andsoitis wrote 6 hours 57 min ago:
congrats.
DIR <- back to front page