Code review should be fast
Today we’re launching Diffs, a new way to review pull requests inside Linear.
Why we built Diffs
When we started Linear, we set out to improve the experience of building software, which had been full of friction for too long. We obsessed over making the core workflow feel fast, fluid, and enjoyable to use.
Code review has stayed painfully slow while everything else sped up. Growing PR volumes from coding agents are putting further strain on an already creaking process. So much so that the speed gained from using agents gets swallowed in review.
Diffs is designed to keep code review fast without sacrificing the rigour of the work.
We approached Diffs with a short list of beliefs about what review should be:
- Fast. Reviews should open near-instantly
- Focused. Reviews should show what matters and strip out the noise
- In context. Code should sit next to the issue, project, and customer signal behind the change
To begin with, we’ve focused where the friction was loudest.
Knowing what to review first
Review requests get buried in your email inbox and the queue offers no guidance on what is urgent, because every PR in the list looks roughly the same. The requester shouldn’t have to spam your Slack DMs to get your attention.
Reviews sit inside Linear next to the rest of your work, where priority is visible because everything else competing for your attention is right there too. Each Diff is attached to the issue and project that produced it, so you can see when one is blocking something critical and weigh it against what else is on your plate.
Getting through a huge diff
Large pull requests are usually reviewed in whatever order the filesystem produced the files, with formatting churn and refactoring noise mixed into the substantive edits. Reviewer attention runs out before the diff does, and the rest gets either skimmed or rubber-stamped. Stacked diffs emerged as a workaround, but it’s a lot of overhead to compensate for tools that can’t handle a large diff.
Guided reviews in Linear break the diff into chapters that follow the order the work was reasoned through. It shows you the core of the change first, then walks you through the consequences, with auxiliary changes and glue code kept separate. A 2,000-line PR becomes legible in a single sitting.
Structural diff highlighting strips the formatting changes that have nothing to do with what the program does, so what is left on the page is the actual change rather than the noise around it.
Piecing together why it matters
A reviewer’s main job is to figure out why the change should exist at all, rather than just checking if the code is correct. This is a slower process when context is spread across multiple tools and tabs.
Because reviews live inside Linear, the issue, project, and customer signal that inspired the change are right there alongside them. There’s no chase across tools, because Linear has already assembled the picture and structured it for you.
The new shape of review
Agents have absorbed most of the line-by-line correctness work that used to take up a lot of time. What’s increasingly left is the layer above the code itself, which is whether the change fits the architectural system the team has and solves the problem the customer actually reported. Diffs removes the friction around reviews, giving the reviewer the time and attention to do that judgement work.
Linear Diffs is the latest step in a workspace Linear has been building for years, where every stage of shipping a product happens in the same place. There’s more of the workflow to come.
Available on all Linear plans starting today, see the Changelog for setup steps.