Reviewing code in the agent era

Last week, Linear introduced Diffs, a new feature that allows for code reviews directly within the platform. This new feature has generated a lot of interest and questions from users. As someone who builds software, I felt the impact of these advancements firsthand when I started working at Linear in 2026. The introduction of more powerful models and agents led to a significant increase in the volume of code moving through my team.

In fact, between January and March, both the number of issues created and PRs merged rose by 50%. While this growth was exciting, it also presented challenges, particularly in maintaining the high standards of quality that Linear is known for. I found myself tempted to quickly approve changes to keep up with the pace, which compromised the quality we strive for.

This led me to focus on finding a solution to efficiently manage the review process without sacrificing quality. After several months of using Diffs, I can confidently say that it has helped me manage the deluge of agentic code and maintain the high standards of Linear. Reviews now have a prominent space in Linear, making it easy for me to keep track of the reviews I need to complete for others and for my own work that is being reviewed.

Linear's notification system, which includes an inbox in the app and a Slack integration, ensures that I don't miss any new requests or feedback. When I start reviewing a request, I first get a clear understanding of the reason behind the change. I can easily see what inspired the code, such as customer feedback, bug reports, or ideas shared in Slack threads.

If the change is visible, like a UI tweak or a new flow, I open the preview build to experience how it behaves. I take screenshots and screen recordings to highlight any issues or concerns I have, so the author can see exactly what I'm reacting to. Next, I examine the diff itself. I quickly review the overall size and scope of the change.

If the change is significant, I use Linear's guided review feature to navigate the change in a logical order. I no longer need to read line by line, as much of the bug checking and logic correctness is now handled by agents. This allows me to focus on the bigger picture, such as whether the change fits into the system and effectively solves the problem.

I can now think about edge cases, user experience, and alternative solutions. Sometimes, I notice that the change addresses the wrong problem. For example, someone or an agent may have taken the brief too literally. In such cases, I start a discussion with the team, which becomes easier when all the relevant context is readily available alongside the code change.

More often, the change is on track, and the work remains within the diff. I leave comments to guide the author towards making necessary adjustments. They can directly address these comments using an agent within Linear, and I can also contribute to these discussions to clarify my feedback. Reviewing code in Linear has become a valuable opportunity for collaboration with my team.

It allows me to see different perspectives, engage in discussions, and notice smarter approaches that I may not have considered. This collaborative aspect of review is crucial to our engineering culture. I believe that quality code review now means that the code is not only correct but also useful and aligns with our product goals.

Overall, I find myself spending more time in review, deciding whether the work being shipped earns its place in the product, rather than just whether it works technically.