It’s becoming an increasingly common feeling to open a PR and see something like this:

Summary

This PR fixes a null pointer exception in the onboarding flow, and in doing so takes a more robust approach to how session state is handled at the boundary. The initial implementation wrapped the call site in a try/catch, which handled the symptom but notably left the underlying contract undefined. A Redis-backed session cache was then prototyped, and while it integrated seamlessly, it required a new infrastructure dependency and a schema migration, so it was reverted in a3f9c21. Renaming the file to UserServiceV2.ts was also considered and ultimately not pursued. The final implementation adds a comprehensive guard clause before user is dereferenced, which crucially reduces the surface area for this class of failure. It is worth noting that this is not just a null check — it is a contract between the session layer and everything downstream of it.

Key changes

• Hardened session integrity — the guard clause is load-bearing, and underpins the contract between the session layer and its consumers
• Zero performance impact — the check is O(1) and adds no measurable latency to the request path
• Reduced cognitive load — engineers delving into this area will find the control flow genuinely easier to reason about, streamlining future work in the onboarding module

Testing

• ✅ 1,247 tests passing, 0 failing, 3 skipped
• ✅ Coverage: 94.2% (+0.1%)
• ✅ Lint and type checks clean
• ✅ CI green in 4m 12s

Additionally, no new tests were added, as the behaviour is already covered by the existing suite.

The rise of AI tooling has made the feedback loop of writing software faster than ever. A bug report can move from verification, to fix, to review in minutes. A complex feature that would have taken a team a couple of weeks to build can be completed by one developer in a day. The PR review process is also becoming increasingly automated. This begs a question: in this new world, who is the PR description written for?

Some would say that how the PR is written doesn’t really matter. It doesn’t matter how much unusual technical jargon, almost indecipherable additional context, and flowery prose it contains. It doesn’t matter how many “It’s not X, it’s Y” constructions or “load-bearing” phrases it features, because the reviewer will ultimately ask an agent to review it.

I’d like to offer a slightly different perspective.

In my opinion, there are two key questions that the PR review phase needs to answer:

1. Is this code technically correct? Is it well-structured, following existing patterns, sufficiently tested, cleanly implemented? Have edge cases been considered?
2. Should this code exist at all? Is it doing the “right” thing?

In my opinion, point 1 can almost be entirely handed to an agent. Frontier models (with guardrails) are more than capable enough to answer all of these questions and more. They can test scenarios a human would not be reasonably expected to think of. I would argue a human is unlikely to catch anything an agent would miss, assuming the agent has enough context (e.g. repo conventions).

However, even the best agent can’t reason whether the PR is solving the right problem. This is where the knowledge, experience and context of a good engineer comes into play. This is why I’d suggest that the most important thing a PR description needs is the context on why the author chose to solve the problem in this way. Ideally in terms a human can easily understand.

So, should you ask an agent to write your PR description? My answer is yes, but with the caveat that you develop a skill to help the agent write in your voice, with the intended end-user in mind. And that you read it and make sure it actually makes sense before posting.

I developed a skill which I’ve been getting good results out of. It’s definitely not perfect, and I still find myself needing to manually edit it sometimes, but it usually gets me 90% of the way there. A few guidelines I’ve found particularly useful:

• Lead with the problem. One or two plain sentences on what was broken or missing, before any implementation detail. A reader shouldn’t have to reach the bullets to work out why the PR exists.
• Reuse the commit messages. By the time a branch is ready, the commit bodies usually already contain the why, so the agent reuses them instead of re-deriving it from the diff.
• Describe the final state of the change, not the journey. Abandoned approaches and fix-of-a-fix commits stay in the history, not the description.
• Prefer bullets over prose. Short imperative bullets for the changes. Compatibility notes and design decisions get their own short section rather than being woven into a paragraph.
• Write for your audience. The description should be understandable by someone familiar with the codebase who has no context on this issue.
• Keep test steps concrete and reproducible. Numbered steps a reviewer can run in their own environment. Whatever the repo uses as its standard setup is fine to reference. Anything that only exists on your machine is not.
• Follow a consistent set of voice rules: no em-dashes, plain vocabulary (no “robust”, “comprehensive”, “notably” or “leverage”), complete sentences, and opinions stated as opinions with facts stated plainly.

The full skill can be found here in case anyone finds it useful.