What I check in a PR that agents miss

I merged a PR this week that an agent had written and another agent had reviewed. The code compiled, the tests passed, the lint was clean, and the review summary said everything looked good. I read it anyway, because that is the part I have not figured out how to hand off, and I found two things. The first was a variable named data that held a list of guest names, which is fine until the next person has to figure out what data means in a file that also has table data and seating data. The second was a missing check for what happens when the guest list is empty, which the tests did not cover because nobody had written a test for an empty list. Neither one would have failed the build. Both would have bitten someone later.

Agents are good at the checks that have a right answer. Does it compile, do the tests pass, is the formatting consistent, is there an obvious bug. Those are real checks, and I am glad I do not have to do all of them by hand anymore. But a PR review was about more than those checks. The part I still do myself is the part with no right answer, only judgment, and judgment is the thing an agent cannot do for me because it does not know what I care about.

intent first

The first thing I check is whether the change does what the PR claims it does. That sounds obvious, and it is the easiest thing to skip, because the code usually does something, and something looks a lot like the thing it was supposed to do. I read the PR description, then I read the diff, and I ask whether the diff is the change the description describes. If the description says it fixes the sort order and the diff also refactors the filter, I want to know why the refactor is in this PR. Sometimes there is a good reason. Sometimes the author just felt like it, and the refactor belongs in its own PR where it can be reviewed on its own.

naming and the six-month test

The second thing is naming, and I mean it in the most boring way possible. Would a new hire understand this in six months? A variable called data fails that test. A function called handleClick that also saves, validates, and navigates fails it. An agent will not flag those, because the names are not wrong, they are just unhelpful, and unhelpful is a judgment call. I rename things in review more than I change logic, and every rename is me betting that the next person to read the code will be grateful.

the edge nobody tested

The third thing is the edge case nobody tested. The empty list, the single item, the user with no name, the network request that fails on the second retry. I look for the input the author did not think about, because the author was thinking about the happy path, and the happy path is the one that already works. An agent can generate test cases, and I use it for that, but deciding which edge matters is a product judgment. An empty guest list matters because a wedding with zero guests is a real state, not an error. A missing avatar does not matter as much, because the UI already handles it. Knowing which is which takes context the agent does not have.

scope and the tradeoff

The last thing is scope, and it is the one I care about most. Does this change belong in this PR, and is the tradeoff worth it? A PR that fixes a bug and also rewrites a component is two PRs, and reviewing them together means I cannot approve one without the other. A PR that adds a feature by copying a pattern from elsewhere is fine, unless the pattern was already the wrong one and now there are two copies of it. These are not bugs. They are decisions, and the person who makes them is the person who owns the outcome, which is me.

I do not think human review is going away, and I do not think it should. The agents took the checks with right answers, and that is a good trade, because those checks were the tedious part. What is left is the part that was always the actual job: deciding whether the change is the right change, whether the code reads clearly, and whether the tradeoff is worth it. I still read every PR myself, not because I do not trust the agents, but because the review is where I decide what the codebase becomes, and that decision is mine to make.