Graphite Blog

Graphite |Senior Software Engineers| New York, NY in our Soho Headquarters | https://graphite.dev

We’re building Graphite to help high-performing engineering teams run faster, cleaner code reviews. Our product is already used by some of the world’s best developers, and we’re just getting started!

We are also thrilled to share that Graphite is joining Cursor! With Cursor, we’ll bring together the best-in-class tools for creating, reviewing, and merging code in the age of AI.

We're hiring experienced engineers across the stack, are are looking for people who:

-Care deeply about code quality, system design, and scaling software responsibly

-Have a strong product sense and enjoy collaborating closely with design & product teams

-Have experience with AI-driven workflows, prompt engineering, or interest in developer tooling is a plus

-Are product-driven and quality-obsessed; we ship thoughtfully and often

The hiring process: quick intro call, 2 technical interviews, & an onsite interview, followed by offer!

If you are someone who wants to work on meaningful problems, values clean code and thoughtful systems, & loves building tools for other engineers, we'd love to chat with you!

You can apply directly on our careers page(https://graphite.dev/careers#positions) or email sam@graphite.dev with the subject title: "Thank you for stacking with us) with a copy of your CV.

Recruiters: appreciate your hustle, but we’re only hiring through direct applications.

Graphite | Mid-level & Senior Software Engineers| New York, NY in our Soho Headquarters | https://graphite.dev

We’re building Graphite to help high-performing engineering teams run faster, cleaner code reviews. Our product is already used by some of the world’s best developers, and we’re just getting started! We're hiring experienced engineers across the stack, are are looking for people who:

-Care deeply about code quality, system design, and scaling software responsibly

-Have a strong product sense and enjoy collaborating closely with design & product teams

-Have experience with AI-driven workflows, prompt engineering, or interest in developer tooling is a plus

-Are product-driven and quality-obsessed; we ship thoughtfully and often

We've recently raised a $52m Series B by Accel, A16z, & others, and have big goals this year.

The hiring process: quick intro call, 2 technical interviews, & an onsite interview, followed by offer!

If you are someone who wants to work on meaningful problems, values clean code and thoughtful systems, & loves building tools for other engineers, we'd love to chat with you!

You can apply directly on our careers page(https://graphite.dev/careers#positions) or email sam@graphite.dev with the subject title: "Thank you for stacking with us) with a copy of your CV.

Recruiters: appreciate your hustle, but we’re only hiring through direct applications.

No, paying for GH doesn't make the code review experience any better. It's identical across public/cloud/enterprise GH.

I do not know if GitLab does anything different; I've never used it in anger. I'd bet $10 the answer is "no, it's basically just the same as GitHub", though.

If you want a service that adds stacking on top of GitHub, my conclusion after some research is that https://graphite.dev/ is the best option. We did consider it, but it couldn't work in my last job for "reasons" (see my other replies in this thread) but if you've got a shop of Git users and just want to throw money at the problem, I think it's the best choice.

GerritHub is also a possibility, they employ many of the Gerrit devs and know what they're doing, but holy shit the corporate options are expensive out of the gate. It's like $20k/yr minimum regardless of size or number of users.

Honestly, Graphite is cheap as hell considering how much more productive your engineers can be with a good review tool. Gerrit was basically night and day for us. It's not "oh, it pays for itself really quickly in a few days!" You'd probably pay off the monthly cost in less than an hour of actual code review. And you don't even have to opt most of your engineers in; you can trial it where 90% of them use GH and only a subset use graphite and pay.

Generally, most things jj does can be done in Git, it's just much more pleasant / seamless / consistent in jj - maybe with the exception of the "Working on Two Things at the Same Time" pattern[0], that one might be really hard to achieve in Git.

> but does it work as a front-end tool over git/other VCS?

citing from the article

> Before we dive in, one last thing you should take note of, is that most people use jj with its Git backend. You can use jj with your existing Git repos and reap its benefits in a way that is completely transparent to others you’re collaborating with. Effectively, you can treat it like a Git frontend.

> I don't get it. What does make rebase hard?

It's hard when you work on a set of stacked PRs and make frequent changes to arbitrary PRs in that stack, because every time you make a change, you have to manually rebase and push all of the other PRs. There's SaaS's specifically built and used for solving this problem in Git[1].

Maybe hard is the wrong word, it's just annoying and tedious. jj makes this completely seamless, as shown in the article[2].

[0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/#pattern-working-on-two-things-at-the-same-time

[1]: https://graphite.dev/

[2]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/#pattern-stacked-prs

Agreed with a lot, but for many companies I think cleaning up git history is more effectively accomplished by cleaning up PRs than actually trying to clean up the commits themselves that developers write.

"Good commits" are one of those things that benefit the whole, but no individual developer is incentivized to do. Because of that, it's easier to enforce at code review (rather than hope developers just do it). Many companies do this by squashing changes, so a developers' commits and the commits on trunk are decoupled.

I think the best way to make changes (and therefore commits on trunk) understandable is to split them up into series of dependent changes; something supported by the code review tooling used at places like FB / Uber / Google, but not super well in GitHub... Which leads to large PRs with a lot of unrelated fixes.

Disclaimer: I work at a company trying to bring that dependent change / stacked diff workflow to git and GitHub (https://graphite.dev).

Along what axis do you want the VCS to be "better" than git?

For example, git's cli user interface is monstrous (yes, I know, you personally have 800 cli commands memorized and get them all right every time, that doesn't make it "good"). From the outset, the maintainers of git basically decided "it's too much work to make all the cli flags behave and interact consistently" so they didn't. This allowed git to grow fast, at the cost of the cli user experience.

That said, git is big enough that multiple companies have come along and "solved" the git UI problem. None of these aftermarket UI layers are perfect, but there are enough of them and they are different enough that you can probably find one that is good enough for you, along whatever axis you personally dislike the git UI (examples include [0], [1], [2], which tackle very different user workflow problems).

[0] https://git-fork.com/

[1] https://graphite.dev/

[2] https://news.ycombinator.com/item?id=7565885