Why does a two-sentence comment on a pull request now carry more weight than the code it describes? Because the comment is where the real decisions get made, and because an AI model probably wrote the first draft of the code it’s attached to. The person who opened the PR may not be the person who typed it. The reviewer is the one explaining, in writing, why it should ship.

That shift has turned the pull request thread into something closer to an essay than a checklist. It’s where intent gets argued, trade-offs get named, and the institutional memory of a codebase gets written down. And it’s the one piece of writing most engineering teams still treat as a chore.

Follow One Pull Request Through a Modern Review

Picture a routine change. A junior engineer opens a PR to add rate limiting to an internal API. The diff is 180 lines.

About two-thirds of it came from an AI assistant; the engineer edited the rest. The next morning, a senior reviewer opens the thread.

What the reviewer writes in the next twenty minutes will do more than catch bugs. It will teach the junior what the team cares about, flag the one line that would have paged someone at 3 a.m., and leave a trail the next person touching this file can read. The code may ship in an hour. The comments outlive it by years.

Teams that build custom software with firms like DEV increasingly treat that trail as part of the deliverable, because clients inherit the thread when they inherit the repo.

The Review Does More Than Catch Defects

Return to that rate-limiting PR. The reviewer spots a subtle off-by-one in the token bucket math. Good. But look at what else gets written: a note explaining why the team uses Redis for counters instead of in-memory state, a pointer to a prior incident, a question about whether the new endpoint should emit the same metric name as its neighbors.

None of that is bug-hunting. A Microsoft study of modern code review found that while finding defects remains the stated motivation, reviews actually deliver knowledge transfer, team awareness, and alternative solutions, and that understanding the change is the central activity reviewers are doing. The comment thread is where that understanding gets externalized. When the model wrote the first draft, it’s the only place that understanding exists in human sentences at all.

Reviewers Are Writing More Than They Used To

Back to the junior and the senior. A year ago, the junior would have typed the rate limiter themselves, probably after reading the Redis client docs for an hour. That reading was invisible training. The reviewer could skim the diff and assume the author had already wrestled with the obvious questions.

Assistants have changed the starting point. The author may not have wrestled with anything; the model produced plausible code and the author kept the parts that compiled. Now the reviewer carries the burden of asking the questions the author didn’t.

That’s why review comments across the industry have gotten longer, more exploratory, and more pedagogical. The reviewer is doing some of the thinking the author used to do alone.

Treat the Comment Like Writing, Not Ticket Chatter

Here is where that same PR either becomes an asset or a liability. Terse, directive comments (“change this to X”) close the thread fast and teach nothing. Comments that explain the reasoning, acknowledge trade-offs, and leave the decision with the author do the opposite. Google’s guide to writing review comments pushes reviewers toward courtesy, explanation, and letting the author choose between reasonable options rather than issuing instructions.

A few habits separate the useful comments from the noisy ones:

The Thread Is the Documentation Now

Six months after the rate limiter ships, an on-call engineer sees it misbehave under load. They open the file, run git blame, and land on the PR. What they find there is either a conversation that explains the design, or a wall of “LGTM” and emoji.

Design docs rot. READMEs go stale. The PR thread, pinned to the exact commit it describes, stays accurate because nobody can edit it after the fact. Teams that have figured this out stop writing separate change rationales and start writing them in the review, where they’ll be found.

The comment is the documentation. Writing it with a reader in mind is the cheapest documentation investment a team can make.