Nix Maldonado

Human PR Reviews in the Age of AI

The Old Days

Back in the day, when humans were the only intelligent beings roaming the earth (defining intelligence as the ability to open a pull request), life was peaceful. All that mattered was a good cup of coffee to get you through the morning while you wrote and reviewed code at a human pace.

There was a slower cadence. Things took more time, and there was a certain craftsmanship pride in every line of code we added.

Not every coder took pride in their work. And oh boy, are those coders in for a ride now. You have to care more than ever, because without real intention and ownership of what you ship, the blast radius is bigger than anything we dealt with back then.

AI Enters the Chat

AI companions have been around for a while now, but it’s only in the last few months that we’ve started leaning on them heavily in our workflows. I’d say it clicked in early 2026: after the 2025 Christmas break, we’d all had time to tinker with these tools on a side project, and the message landed loud and clear.

Things were about to change.

It’s hard to believe how fast things have moved since the start of 2026. Writing code can’t go back to the human-only way. It doesn’t make sense anymore.

And you don’t have to take my word for it. Even Linus Torvalds has landed here, and he’s no AI hype man. This is the guy who called it “90% marketing, 10% reality.” His position, now baked into the Linux kernel’s official policy, is simple: use the tools if you want, but you own every line they produce. Tooling doesn’t matter. Accountability does.

A Couple of Months’ Work in a Week

After a couple of months at this warp speed, I’ve noticed something: we’ve moved the bottleneck.

Onto the pull request.

We have AI reviewing our PRs too, which is a whole topic of its own. Cloudflare’s approach is worth a read if you’re curious. I was generating far more code than before, and so were my coworkers. Reviewing that much code isn’t possible for a flesh-and-blood human. But that doesn’t mean we’re useless now.

Maybe I’m biased, but I truly believe we’re not.

Humans stay valuable because we hold the long-term goals and the context, the kind that doesn’t degrade between sessions the way an AI companion’s does.

So I built something to lean into exactly that. It’s a small command, /crux (as in “the crux of the matter”), that helps you navigate a large PR and pinpoint where the parts that actually matter live. It surfaces only two kinds of things, because these are what I think should stay in human hands no matter how much of the code generation we automate:

  • Business rules: the conditions, validations, state transitions, and thresholds that encode a domain decision.
  • Observable behavior changes: what shifts for a consumer of the code, like API contracts, response codes, persisted state, and new error conditions.

The discipline is as much about what it leaves out. Refactors that don’t change behavior, renames, formatting, import reorders, generated code, lockfiles: none of that is crux, so none of it makes the list. If a linter or a test would catch it, it doesn’t belong in front of a human. What’s left is the part that needs someone who remembers why the system works the way it does.

The instructions live in a plain .md file (of course). In them, I budget 50 lines of code as the target for a human to review closely, with a hard cap at 100. That’s deliberately tight. The classic SmartBear analysis of roughly 2,500 reviews at Cisco put the defect-detection sweet spot at 200 to 400 lines per review, with effectiveness dropping off sharply past that, a finding that’s held up for nearly two decades. But detection is highest in the first hundred lines, and the strongest teams keep their changes smaller still. So for the crux, the handful of changes that carry real risk, I wanted a budget a human can hold in their head in one sitting.

As a final touch, the whole thing is copied to your clipboard as markdown, ready to paste straight into the PR description. It looks something like this:

## For human reviewers: start here
_These are the highest-impact changes in this PR_

1. **<one-line description of the rule or behavior change>** — [path/file.go:NN](https://github.com/<org>/<repo>/pull/<pr-number>/files#diff-<sha256(path/file.go)>RNN)
2. **<...>** — [path/file.go:NN](https://github.com/<org>/<repo>/pull/<pr-number>/files#diff-<sha256(path/file.go)>RNN)

Running it is one line: /crux <pr-number>. Pass the PR number and every item links into the PR’s Files-changed tab, deep-linked to the exact diff line. Leave it off and it falls back to blob links against the current HEAD, which still resolve but drop you on the file instead of the diff, so I always pass it.

A PR number only exists once the PR does, though. So my flow is to open the PR as a draft first, grab the number, run /crux <number>, and paste the block into the description before I take it out of draft. Opening as a draft has a second payoff: it keeps the maniacal AI reviewers from swarming the second a PR shows up. They love to fire on creation, and I’d rather hand them, and the humans, a map of what matters before anyone starts.

Each item links to the exact line in the PR diff. It doesn’t jump quite as cleanly as I’d like, thanks to a well-known quirk: GitHub lazy-loads diffs in the Files-changed tab, so a deep link to a line in a file that hasn’t rendered yet has nothing to scroll to (others have hit the same wall). The fix is to Cmd-click and open it in a new tab. The full page load resolves the anchor correctly.

So that’s my humble contribution to the era of AI PR reviews. You can find the skill here, or install it straight from the command line:

npx skills add https://github.com/nixmaldonado/skills --skill crux