12. 9. 2026

How to make your PRs a delight to review

Author: Tomáš Bořek

Tags: software-engineering

Ever since LLMs became a tool for managing changes in code from start to finish (from reading specs, tickets, and other resources to opening PRs, writing documentation, etc.), developers face a formidable number of inconsiderate, spirit-forsaken pull requests piling up in their feed.

There's something daunting about reviewing changes that no human eye has ever seen. After finding issues and commenting your proposals, chances are the "author" of the change will just run your comments through an LLM, and your remarks are lost in a void of tokens. You become an agent yourself, iterating on feedback given by another agent running on someone else's computer.

This is unrewarding and ultimately less productive than the "old-school" way. Code reviews and leading discussions in the comments (and the real world) is an immensely formative activity, forcing you and the author of the code to think not only about the changes, but also about how they fit into the composition of the whole project. Every comment is an opportunity to learn, ponder, find out something new about the project, the technologies you use, and your colleagues. It entrenches your understanding, and you carry this to the next task you need to tackle. This way, the whole team grows, and no comment or discussion goes in vain.

This, unfortunately, doesn't happen – or at least not to its full capacity – with changes that are fully carried out by LLMs. I think that now, more than ever, is a good time to rehearse some of the ways you can make your PRs not only bearable, but maybe even enjoyable to review by other people.

I lay out a few tips that I've found to be helpful during the process of code reviews. This list is in no way exhaustive but offers my take on various important aspects of preparing code changes for a review.

Slice it up

The best PRs begin by thinking through the radius of your change. No matter how good a developer you are, and no matter how much work and effort you put into your PR, seeing thousands of lines of code and tens of files with significant changes discourages a person.

Our goal, therefore, is to split the changes into smaller, more digestible pull requests. Consider a large feature or refactor that handles creating and interacting with comments in an imaginary app. Assuming our app has at least a moderate scale and maturity, this could easily be a very large change, so you would want to split it somehow. There are two main approaches you might consider when thinking about how to split a large change into smaller units: technical (horizontal) and feature or business logic (vertical) splits.

With the technically-sliced approach, you would probably first open a PR for the data layer, implementing all the DB communication methods you'll need; after that's safely reviewed and approved (or merged), you'd build on top of that with the business logic, calling the methods you've established in the previous step; the next step would be some presenter, and maybe tests at the end (or as the first thing, depending on your testing approach).

This approach is inferior to vertical slicing for various reasons, the main one being that while reviewing one technical layer, the reviewer can't see the other layers and therefore can't assess the aptness of the currently reviewed layer accurately. No one can truly judge whether the code is appropriate for the rest of the feature because the wiring doesn't exist yet. Methods written in one PR can silently remain unused or become subject to change in subsequent PRs of this large change – which then kind of breaks the splitting – and more.

Focusing on organizing your changes into units of thin, feature-oriented slices makes reviewing easier because everything has its place and the wiring is clear. Going back to the example, it would probably make sense for me to initially code the creation of comments end to end (with all the technical concerns); and after that's approved, I can progress to the feature of liking comments, etc.

Modern tools provide ergonomic ways to work with chained PRs. GitHub's new native stacked PRs feature, Graphite, or OS projects like git-branchless are all tools that allow developers to base their smaller-scale changes on the previous changes, which unblocks them from waiting for one slice to be reviewed and merged before they can start working on the subsequent one.

Be patient

Before opening a PR, let all the continuous integration pipelines run. All the tests, builds, and other checks should be green before the PR even gets moved out of drafts. Many projects now integrate automated AI review processes. After opening the PR, have the agent analyze it with priority; it can catch some obvious (or even less obvious) mistakes straight away, and it's much faster and cheaper than human energy and attention.

Only after verifying that all the tests pass and after addressing the automated review comments should you notify your teammates that your changes are ready for review. By being patient, you avoid duplicated comments, and it also increases the level of trust a reviewer has in your changes. It's a red flag when your colleague comments on some of the following:

• "This breaks a build,"
• "This test now fails because of this change,"
• "I agree with Copilot," etc.

All of these could've been caught by waiting a little longer and giving way to the automated tools first. Your teammate can then come to a partly pre-reviewed PR, in which they don't need to wonder about fundamental things, like whether the application remains functional after these changes.

Description is a story

The description should provide all the necessary high-level context, link all important resources, explain and acknowledge any caveats, and provide an instruction manual for how to use and test the change.

I often find AI-generated descriptions unhelpful because the agents only echo what they've been fed: Jira tickets, instructions, code changes, etc. It's usually the human who has a broader understanding of the domain and business and understands the exact whys and hows of the change. LLMs live in isolation; they have blinders on and see only a small fraction of the knowledge the human members of the team have accumulated over months or years in the company/on the project (also through such practices as thorough, attentive code reviews).

Trust is often neglected but is honestly one of the most important prerequisites to a smooth and satisfying code review. The reviewer needs context and trust before seeing a single line of code; the PR description can provide both.

Even with changes fully carried out by an LLM agent, I highly recommend writing the PR description yourself. It proves you know what you were prompting for, provides context the agent can't have, and makes your changes far more trustworthy. Don't make the descriptions overwhelming; keep a simple structure touching on:

• What changed?
• Why did it change?
• How to test and use this change?
• Are there any other important resources?

It should read like a narrative rather than a reiteration of what's present in the diff. Keep in mind that your description is like the packaging of your pull request. If you want to sell something, half the job is done through the packaging.

Code comments vs. PR documentation comments

Reserve code comments for information that will always be relevant as long as the piece of code it decorates stands; utilize PR comments for documenting why something changed, i.e., things that have transient relevance.

It's not a good practice to comment on why some change occurred and/or what the previous state in code was. Usually, no one cares when reading the code. When I come across a function, I very rarely want to see how the function was named four months ago and why it was renamed (and if I do, I always have git blame linking me to the relevant PR that introduced the changes into the main branch). This can definitely be useful information during the review, though!

Adding a bunch of comments to non-obvious changes before inviting someone to review the PR can add much-needed context for the reviewer, without engraving it forever into the codebase and overwhelming future readers.

It's also good practice to review your own changes before handing them to others (and you can do this while "being patient" for the automated pipelines to run) and to pre-object the PRs. Any time you encounter a line that you anticipate will cause some confusion or doubt, either try to find a better way to implement it or defend why this decision was necessary.

Bottom line: have basic empathy

The whole process of leveling up your PR game can be summed up as: plan your changes well, groom the PR nicely, verify it actually works with tools you already have, and explain yourself.

All of this is done in pursuit of a sole goal: make the life of the person on the other end of the screen a little easier. It's basic empathy – one of the easiest but most powerful things you can embrace in your job.

If you design, code, and document with at least a basic regard for others, you can forget these tips, and they will probably appear in your workflow organically. If you show care, others will try to reciprocate. By this, you make your, and everyone else's, job easier, and everybody wins!