Pull Requests Are Trust Infrastructure

I’ve lost count of the number of one on ones with direct reports I’ve had where someone complains about another engineer’s pull requests. “Theyre chasing perfection” or “they’re cutting corners” being the two extremes the feedback pendulum swings between. The engineer asking for more tests thinks they’re protecting production. The engineer pushing back thinks they’re protecting delivery speed. Both think they’re defending good engineering.

It’s easier than I’d like it to be to wind up with a team stuck in a pull request standards debate that won’t resolve no matter how explicitly you define the rules. Teams rarely argue this long about standards unless something else is going on underneath.

When technical standards debates get stuck, the problem usually isn’t technical.

If I hear a team is engaging in pull request standards debates, I suspect a lack of trust because pull requests are usually where trust problems surface first.

Why?

Because PR reviews force engineers to answer heavy questions about their teammates like: Do I trust your judgment? Do I trust your testing habits? Do I trust your production instincts? Do I trust your ownership boundaries? Do I trust your definition of “done”?

Those are organizational questions disguised as formatting comments.

Pull requests are one of the places where trust gets tested most visibly. They force teams to make implicit expectations explicit.

Teams with trust merge faster because they debate and rewrite less. Not because they review less carefully, but because they can review more efficiently. They spend their attention on genuinely risky changes instead of re-litigating every convention.

Teams with little or no trust relitigate everything, over-specify standards, and escalate to managers.

I’ve seen this show up as reviewers asking for excessive test coverage from some engineers but not others, or pushing back on PR size from newer teammates but not experienced ones. Even just spending longer reviewing one engineer’s code than another’s. Those aren’t really standards disagreements. They’re signals about where confidence hasn’t caught up yet.

No matter how many review guidelines we wrote down, there was still a disconnect on the team. Our documentation may have changed, but the underlying trust didn’t. I have seen managers help guide teams out of this scenario by calibrating reviewers, reinforcing shared ownership, and building reliability confidence across engineers.

One place I’ve seen this show up repeatedly is when newer engineers join. They should participate fully on the team, and that includes reviewing pull requests. But with a steep learning curve around identity engineering, new reviewers may not yet have calibrated around expectations. In one case we kept review participation broad but preserved a smaller group responsible for final merge confidence until context caught up across the team. Over time the extra layer stopped being necessary because the trust gap closed.

Then standards suddenly became easy again.

I’ve been having more discussions around pull requests lately than I have in a long time largely because of the effect AI has had on them. From AI generated code to increased number of pull requests to AI review - people want to understand what these changes mean for our standards. 

AI is changing how code gets written and reviewed. But it hasn’t changed the underlying reason teams struggle to agree on standards. Organizations regularly add automated reviewers to pull requests because they’re great at enforcing the exact standards engineers used to debate about. Review velocity expectations are shifting.

But the trust layer underneath review standards is actually becoming more important, not less. Teams still need shared trust about what “good enough” means. AI can accelerate code review, but it can’t replace trust.

Before AI, pull request standards debates often looked like disagreements about correctness versus speed versus style. After AI, pull request standards debates should become about what counts as trustworthy engineering work when authorship is changing.

Now teams are still asking the same questions about trust but with a different target. Instead of trusting their teammates they’re asking even bigger questions: 

Do we trust AI-generated code?

Do we trust the engineers on our team to validate AI output? 

Do we trust engineers to know what they didn’t write?

That’s not process friction.

In a code review context, it’s the difference between “I trust this code works” and “I trust the process by which you decided this code works.”

Fix trust first. Standards will follow.