With the rise of agentic development, a lot of attention has been focused on context. How big is our context window? How do we structure our Markdown files to provide the right context at the right time? How do we craft prompts that provide the right kind of context for successful outcomes? We're so focused on it, in fact, that it's now its own type of engineering: Context Engineering.
But this isn't a new problem. You've been managing context long before the agentic revolution. Long before Claude, Cursor, or Copilot. Back when we still thought attention wasn't all we needed, you were already managing context; not for automated agents but for human engineers. And here's the kicker: humans need that context more than ever. The speed at which agents are able to generate code is ever increasing, and that classic trope that "context switching is hard" still rings true to this day. If we're going to be able to realize more of the gains made by these code generation tools, we're going to have to shift some of the focus back on our human reviewers.
Keep PRs small
The easiest way to reduce the necessary context for a reviewer is just to keep things small. This shouldn't be a surprise: keep the number of lines manageable, break larger PRs into smaller standalone chunks, keep quality-of-life improvements separated from functional changes. These are all established practices to reduce the cognitive load on reviewers when striving for those green checkmarks.
Concise agentic PR context
It's no secret that agents love to output text, but in most cases less is more. The reviewers tagged on a PR are likely there because they already have some prior experience with the code in question. This context does not need to be reiterated or stated. Guide your agents to provide relevant, but concise PR descriptions. Add topical context inline with code or pull request comments. These small changes go a long way to reduce the wall of context reviewers are met with when attempting to review pull requests.
Aggressively decouple
This is all about reducing the amount of context needed to accurately review any given change. If we are able to reduce the blast radius of a given PR, that reduces the amount of context needed to communicate to reviewers. This doesn't necessarily mean you go out and break your monolith into microservices, but the importance of clearly defined domain boundaries between applications is critical. If we can avoid that nagging uncertainty about all the downstream effects of a particular change, that decreases the cognitive load on reviewers, requiring less context to effectively review a PR.
All of these are established engineering principles because we've been aware of the context problem for as long as we've been programming. It's never been faster to generate code, but understanding still takes effort. If we're focused on the context needs of a reviewer, not only will our velocity increase, but the understanding of our code will as well.