/wakamoleguy

When It's OK Not to Understand Your Own PR

Here's an increasingly common scenario: you are reviewing a PR from a colleague, and it becomes clear while reading comments that you're not talking to them at all but to their AI agent. Oh, no! Your colleague has become a meat proxy and left you to deal with it.

As a reviewer and a manager, my initial response to this was to remind folks that they were responsible for their code. They should be taking the time to understand the code as well as if they authored it themselves. Then, the traditional code review model should work fine, right?

Et tu, Will?

Then, the other day, I was working on a large change to our sync system, and a PR was spuriously failing to deploy to our staging environment. Rather than retry the deploy and move on, I fired up Claude to investigate. It found the issue: a leaky lock blocked migrations from running against our Neon database. The fix: swap the migrations config to use a direct connection string instead of going through Neon's PgBouncer pool. I put up the PR, sent it for review, and returned to my main task.

The review came back: "Why do we use PgBouncer at all? Should we be using the direct connection for everything?" I had no idea. Let me just ask Claude...

Wait, am I the villain here? I just shipped code that I didn't fully understand and asked my colleague to review it.

I think that is OK?

It's easy to say that I should have taken more time to understand the ins and outs of the PgBouncer change. But...the entire task was a side quest in the first place. The alternative is not whether I fully understand the code or not; it's whether the issue is fixed or ends up in a backlog for a "someday" when I have time to read about Neon and PgBouncer. And in the latter case, our staging deployment remains flaky.

So, there is a practicality here. It can take a long time for a human author to understand the code well enough that they could have written it themselves, especially in areas outside their comfort zone. That delay might very well cost the team more than shipping code more frequently, even if the code is lower quality.

The question then is, how do you support more agent-driven code changes effectively, while raising the quality bar as high as practical and without frustrating reviewer experiences and meat proxies?

Framing the review

First and foremost, the code review still has to be an interaction between the reviewer and the author, not the reviewer and the author's agent. The author is asking for the reviewer's time and attention, so they should be willing to at least engage at the same level. Delegating that role to an agent is disrespectful.

Second, while the author may not understand the code at a level where they could have written it themselves, they should still understand it as a reviewer. Treat it like the agent is the author and the human author is the first reviewer; don't pull somebody else in until you're satisfied first.

Third, when the author does request a review, they should set expectations. If there are parts they are unsure about, flag them. I have found it best to frame the review as a two-way discussion between reviewers rather than as feedback from reviewer to author.

Where you run into trouble is when the reviewer is treating it as a traditional code review, the author hasn't communicated otherwise, and instead tries to pretend that they still understand it when they don't.

As always, communication is key

This isn't one-size-fits-all, and no blanket rule will properly balance speed and safety across every change. Some areas need more careful attention to detail. A non-production database config is low stakes; a change dealing with auth or billing demands more care. As an author, remember that it's OK to say things like:

That was obviously true before AI agents existed, and it's still true today.

Cheers!