Why we use Graphite and stacked diffs

At Monk, we automate accounts receivable for fast growing companies. Speed matters. When a customer's payment is late, every day counts. When an issue hinders performance in intelligent collections module, every minute counts. And above all - our customers are aOur engineering culture reflects this urgency.

We use Graphite and stacked diffs because they let us ship faster without breaking things.

Smaller PRs Are Better PRs

The best code reviews happen on small changes. Not 1,000-line PRs where reviewers skim and approve.

Small PRs respect your teammates' time. A reviewer can look at 100 lines in 10 minutes between meetings. They need an hour for a 1,000-line change and they'll probably miss something.

Breaking work into small pieces also forces you to think. You can't hand-wave the design when each PR has to stand on its own. You have to know what you're building and why. This matters!

Stay in flow

Engineers are most productive during uninterrupted coding streaks. You get into a rhythm. The problem lives in your head. You see the solution clearly.

Then you submit a PR and wait. Flow breaks. The problem fades. By the time you get approval, you've moved on to something else. When you come back, you have to load everything into your head again.

Stacked diffs solve this. You keep building on your own work without waiting for approval. You stay in flow.

The cost of switching between unrelated PRs is high. Much higher than pushing forward on work that builds on itself.

And so we try to optimize for staying in flow as much as possible via stacked diffs.

Trust the engineers

Stacking puts engineers in control of their velocity. No blocking on reviewers. No artificial gates. You ship when you're ready.

Code review still happens. It just doesn't stop you. Feedback improves your code, but it doesn't halt your progress. You can incorporate changes while moving forward.

With traditional workflows, you ship one feature per week. With stacking, you can ship multiple related improvements in a day.

Good outcomes for customers + more fun for the engineering team.

How graphite speeds everything up

Take our Playbooks feature. Playbooks are an automation/workflow layer on top of our intelligent collections module. It is non trivial (as are most enterprise grade workflows). Database changes, business logic, UI, AI conditions, nested workflows.

We didn't ship it as one massive PR.

First we landed the database schema. Then the core engine. Then the UI. Each PR landed in sequence. Each PR small enough to review properly.

The conditions system grew the same way. Basic conditions first. Then LLM-powered conditions. Last we shipped time-based triggers and response detection.

Actions expanded piece by piece as well (emails, loops, nested playbooks).

When we added nested playbooks, we didn't wait for unrelated condition logic to finish. They were separate PRs in the stack and so it all moved forward independently.

Parallel development without merge conflicts

Multiple engineers can work on overlapping areas without stepping on each other. Graphite's gt sync handles rebasing automatically. What used to take 20 minutes of manual work is now one command.

When someone lands a PR in your stack, your downstream PRs update themselves. You don't waste time on merge conflicts.

Small PRs get reviewed faster. Faster reviews mean faster feedback. Engineers spend less time waiting and more time shipping. Boom!

Better reviews, not just faster

Small PRs are easier to review well. A reviewer can hold the entire change in their head. They understand what it does and why. They can spot problems that would hide in a larger diff.

This leads to higher quality reviews, not just rubber stamps.

The pattern repeats for us. Features go through small composable PRs. Reviewers approve atomic changes. Engineers stay unblocked and maximize time in flow.

Why do we care? We care because it matters for our domain (revenue automation) and for our engineering culture

When you are automating accounts receivable, reliability is everything. A bug in payment tracking means lost revenue. A bug in email automation means damaged customer relationships.

Small PRs catch bugs early. Fast iteration fixes them before these bugs compound. And honestly above all - engineers who stay in flow build better systems.

Fast growing companies can't wait a week for a feature. Their needs change daily. Stacked diffs allow us to keep up with our customers.

We chose Graphite because it makes our engineers faster without making our code worse. It's that simple.

‍