How Graphite Ships 🚢
A deep dive into the workings of the team behind one of the most beloved dev tools.
It’s a weird time for engineering teams.
The jury is still out on AI’s true impact on productivity, but at least it feels like it gave everyone permission to question old practices and try new things.
Nothing is sacred anymore, and everyday someone is figuring out something new: inventing workflows, debating how engineers should spend their time, and more.
The result is an incredible diversity.
Some teams are going all-in on AI, others are doubling down on fundamentals. Some are rethinking things entirely, others are skeptical that much has changed at all.
This is all fascinating… and overwhelming.
A lot of the thought leadership out there is necessarily short-lived, and I don’t want to be guilty of that myself, so I want to experiment with doing more of one simple thing: just sit down with leaders of elite engineering teams, and ask them how they work.
Not theory. Just: what do you do, and why?
The goal is to learn from teams that ship great products, fast — and understand how they’re adapting to this moment. What practices are they doubling down on? What are they throwing out the window?
For this first chat, I sat down with Greg Foster, co-founder and CTO of Graphite, a beloved tool that helps engineers ship faster through stacked changes and AI-powered code reviews.
What makes Graphite especially interesting is that they’re an AI dev tool built by devs, for devs. Their engineers use the tool every day. This creates an incredibly tight feedback loop and forces them to be intentional about how they work.
During our chat, Greg shared several practices that stood out — some controversial, some deceptively simple, but all battle-tested:
🚀 High-agency engineers — why Graphite runs with just ~2 PMs for 30 engineers, and how they make it work.
🎲 Onboarding roulette — randomly deleting employee accounts to dogfood their own product.
🏗️ Boring tech == fast shipping — monorepo, single language, Postgres for everything: simple beats clever.
👁️ Code review in the AI era — the vision for AI deciding what needs human review, and how stacking fits in.
🔥 Hard work as a lagging indicator — why the 996 debate misses the point entirely.
Let’s dive in!
I am grateful to Graphite and Greg for partnering on this piece, and I am a fan of what they are building. You should try it out! 👇
🚀 High-agency engineers
Graphite is obsessed with building a team in which engineers have incredible agency.
For Greg, a high-agency engineer is one who doesn’t just write code to spec — they own problems end-to-end. This matters for two reasons:
🏃♂️ Productivity — less back-and-forth, less waiting, less “that’s not my job”, but also…
❤️ Fulfillment — people who have real impact are more engaged, grow faster, and stick around longer.
So high agency is a North Star worth chasing, both for how your team ships and for how they feel about their work. But how do you trend towards it?
What enables agency?
From first principles, high agency comes from three things:
🎯 Purpose — a clear vision of where you’re going and why it matters.
🔑 Permission — freedom to go after big things, make decisions, and occasionally get things wrong.
🪄 Simplicity — cognitive load that’s manageable enough for ownership to feel like a superpower, not a burden.
As a result, Graphite is light on product management — just a couple of PMs for 30+ engineers. Engineers fill the gap: they talk to stakeholders, figure out details, make prototypes to be tested and dogfooded internally, and push things forward without being blocked.
This is the ideal world of Product Engineering but, admittedly, Graphite has an unfair advantage: they’re building a dev tool, so their engineers are their users. They have strong product intuition out of the box.
For the rest of us who are not building a dev tool, how do you get there? Is that even possible?
Bridging the gap
I believe getting engineers closer to customers is a principle that holds true for everyone. Your mileage may vary, but you get increasing benefits along the way.
What changes, if you are not building a dev tool, is that you need to invest intentionally to bridge this gap. Some ideas are:
📞 Bring engineers to customers — sales calls, user interviews, support escalations. First-hand exposure beats summaries.
📚 Make context accessible — record calls, share clips, pipe support tickets into Slack.
🐕 Dogfood relentlessly — even if your product isn’t “for” engineers, find ways to make them use it.
At Graphite, dogfooding is cultural. Every new feature launches internally first, often for weeks. It doesn’t ship until people are voluntarily using it. That’s an incredible feedback loop — and while not every company can replicate it perfectly, every company can move in that direction.
But dogfooding is easier said than done. Most teams do it once—when they onboard—and then never again. So how do you keep it alive? 👇
🎲 Onboarding roulette
Here’s one of Graphite’s most interesting practices: every day, a random employee gets their account deleted.
 | A guest post by
|