jacobegold (u/jacobegold)

jacobegold commented on Code review can be better tigerbeetle.com/blog/2025... · Posted by u/sealeck

ndr · 12 days ago

Is there something that does this?

I've played with git town which is great for what it is.

But at $DAYJOB we are now all on graphite and that stacking is super neat. The web part is frustratingly slow, but they got stacking working really well.

jacobegold · 12 days ago

we have a big effort in the works to improve web perf! where specifically are you seeing slowness in the app — what flows, what pages, etc?

jacobegold commented on Jujutsu and Radicle radicle.xyz/2025/08/14/ju... · Posted by u/vinnyhaps

koreth1 · 12 days ago

As a satisfied customer of yours, the prospect of having to give up Graphite is the main thing keeping me from giving jj a try at my day job.

Ironic, since if there are a bunch of people in my boat, the lack of us in jj's user base will make it that much harder for jj to cross the "popular enough to be worth supporting" threshold.

jacobegold · 12 days ago

My ideal is really just a version of `gt sync` and `gt submit` that handle updating the Graphite + Github server-side of things let you use `jj` for everything else, I think it could feel super nice. Probably not as simple as my dreams, but hopefully something we can get to with enough interest!

jacobegold commented on Code review can be better tigerbeetle.com/blog/2025... · Posted by u/sealeck

jacobegold · 12 days ago

It's so cool that Git is considering first class change IDs!! That's huge! This sounds similar to what we had at Facebook to track revisions in Phabricator diffs. Curious if anyone knows the best place to read about this?

jacobegold commented on Code review can be better tigerbeetle.com/blog/2025... · Posted by u/sealeck

tomasreimers · 12 days ago

Just taking a step back, it is SO COOL to me to be reading about stacked pull requests on HN.

When we started graphite.dev years ago that was a workflow most developers had never heard of unless they had previously been at FB / Google.

Fun to see how fast code review can change over 3-4yrs :)

jacobegold · 12 days ago

hell yeah

jacobegold commented on Graphite Chat graphite.dev/blog/introdu... · Posted by u/jordanscales

rileymichael · 13 days ago

to be direct, there's really nothing for you to do — it's a branding issue. if i were to link graphite to any of the devs i know that are actually interested in improving their development workflow, they would immediately close out after one look at the landing page. they have zero interest in AI and certainly won't pay for it to be shoved down their throats. graphite is now perceived as an AI company first, not a developer company.

you state that users don't 'have to use ANY of our AI features' — does that mean you have an opt-out toggle that fully hides any mention of it (e.g. in your 'AI-powered PR page')? if so, how long will that stick around? how long will your core products remain unsullied once your investors start to pressure you to push AI more? these sort of concerns around long term direction keep myself and others from adopting graphite.

jacobegold · 13 days ago

(views expressed in this comment are my own, not those of graphite)

we have a number of large customers that feel the same way and are fully opted out of anything AI-related.

in my experience, our foremost goal is bring graphite to more people. i have seen many cases where folks get us in the door with diamond and then begin championing stacking which leads to a ton of organic spread that it otherwise may not get.

we have seen a ton more signal that ai is the easier way to get more committed folks in the door than signal that we are losing potential customers over having it as an option. if that were not true, we probably would not have gone in this direction.

i would love for graphite-lovers to make more noise about stacking as well and see no reason it can't happen in parallel - every month i see more and more conversations about stacking happening in the wild, and more and more of them reference us directly!

jacobegold commented on Graphite Chat graphite.dev/blog/introdu... · Posted by u/jordanscales

rileymichael · 14 days ago

shame to see a company that was originally targeting a niche (devs that care enough to pay for a tool for stacked diffs) do a complete 180 to chase the AI bag. i have to imagine the overlap between the original users and ones interested in 'graphite chat' is miniscule.

for anyone that's looking for a no-fluff stacked diff tool to replace Graphite, i've found https://abhinav.github.io/git-spice/ to be solid

jacobegold · 14 days ago

we still do stacked diffs — it's our bread and butter, and many of our existing customers, some of whom have been with us since the beginning, are finding a ton of value from both diamond comments and chat. i loved working on the CLI, i loved working on chat, and i'm excited to continue building tools that make code review less of a pain.

the core problem that stacked diffs and that adding AI to the PR page solve are the same — code reviews slow devs down and force unnecessary context switching.

stacked prs help you get around this by allowing you to manage your work in way that makes it easier to organize in an author and easier to deal with as a reviewer. AI can help you get around this by making it easier to review PRs when you open the page, and save you the context switch of going back to your editor to make a tweak that a reviewer suggests.

Graphite has always been about shortening the cycle time and reducing the amount of busy work from writing code to getting it merged, and we'll continue building features that speed up that cycle.

the best part is — you can still pay for Graphite, and you don't have to use ANY of our AI features. we're still constantly shipping improvements to our CLI, optimizing our merge queue for our larger enterprise deployments, continually working on making the PR page more modern and easier to use than GitHub's and working with the same customers that we have since the beginning to do so.

would love to hear what you think we can do better to address your needs

jacobegold commented on Jujutsu and Radicle radicle.xyz/2025/08/14/ju... · Posted by u/vinnyhaps

vlovich123 · 19 days ago

And do downstream PRs show just what changed or is the merge target against main which then just keeps accumulating differences?

This is one of the strengths I appreciate about graphite which is that the PRs are always on the preceding branch but it knows that when you go to merge it should actually really retarget and merge against main.

jacobegold · 19 days ago

(Graphite dev here)

Yeah – the key thing here is that there is work to be done on the server, so JJ likely either needs its own forge or a GitHub App that handles managing PRs for each JJ commit.

I'm a huge fan of the JJ paradigm – this is something I'd love for us to be able to do in the future once one or both of: - we have more bandwidth to go down this road - JJ is popular enough that its worthwhile for us to do

That said I'd also love to see if anyone in the community comes up with an elegant GH app for this!!

jacobegold commented on Ask HN: Will human code review still exist a year from now? · Posted by u/changisaac

changisaac · 23 days ago

>"Code review" as defined as a human in the loop getting the final say on whether a change will be made to the system will be the absolute last thing to go. That process may look very different as both the inputs massively increase in scale and the methods get disrupted by AI.

I know this is probably not something you can divulge but I look forward to how your team at Graphite plans to solve this! (Would also love your personal take!)

jacobegold · 23 days ago

We've already soft launched the next step toward this to some existing Graphite users, so I'm fine sharing!

We're adding an agentic chat sidebar to the pull request that can help you gather context to understand a PR and make pre-merge changes without needing to leave the PR page. Open beta next week.

We're only going to spend more and more time looking at diffs as the amount of them increases, so the tools that we use here need to evolve as well. "AI code review" should be an interactive experience that directly builds on how code is reviewed today, not just a bot that comments on your PRs.

jacobegold commented on Ask HN: Will human code review still exist a year from now? · Posted by u/changisaac

changisaac · 24 days ago

Surprised that’s your take considering Diamond is one of the code review bots that are ahead of the pack. Curious why you think that’s the case? Is it a technical limitation? Or something about human code review that is just fundamentally hard to copy?

jacobegold · 24 days ago

AI will certainly make human code review easier — the goal being to keep up with the velocity of changes to existing large systems.

"Code review" as defined as a human in the loop getting the final say on whether a change will be made to the system will be the absolute last thing to go. That process may look very different as both the inputs massively increase in scale and the methods get disrupted by AI.

jacobegold commented on Ask HN: Will human code review still exist a year from now? · Posted by u/changisaac

jacobegold · 24 days ago

lol. human code review is all we will do day-to-day in a year

(i'm the lead engineer on diamond)