Reviewing PRs in the Age of AI

𝗥𝗲𝘃𝗶𝗲𝘄𝗶𝗻𝗴 𝗣𝗥𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗔𝗴𝗲 𝗼𝗳 𝗔𝗜

There are more PRs than ever right now. And I’m starting to worry we’re merging code we don’t fully understand or even works.

The volume has gone up. I’m not convinced the validation has.

And if I’m honest… I’m nervous about the quality slipping, not because of AI’s ability to code, but because of how we’re validating that code, and the humans in the loop, both creator and reviewer.

I’m seeing more and more pull requests that look right, clean, well-structured, even “best practice” but don’t actually work. Or worse, solve the wrong problem or solve it in the wrong way. It's wrong for me to be catching them that late.

And it’s not a junior vs senior thing. It’s happening across all levels.

This isn’t just about AI generating code on its own. This is also about 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝘂𝘀𝗶𝗻𝗴 𝗔𝗜 𝘁𝗼 𝗯𝘂𝗶𝗹𝗱 𝗣𝗥𝘀 and their process.

AI has changed how we write code. But it’s also quietly broken some of the assumptions we used to rely on.

⚠️

𝗧𝗵𝗲 𝗮𝘀𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻𝘀 𝘄𝗲 𝗰𝗮𝗻’𝘁 𝗺𝗮𝗸𝗲 𝗮𝗻𝘆𝗺𝗼𝗿𝗲

We used to trust that:

◈ The engineer ran the code ◈ It works (at least locally) ◈ It solves the intended problem ◈ It’s in the right place

Now? None of those are guaranteed.

I’ve reviewed PRs where: ◈ The code is perfectly reasonable… but never executed ◈ The solution is clean… but incorrect ◈ The logic works… but lives in completely the wrong part of the system

It’s what happens when 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝗿𝗲𝗹𝘆 𝗼𝗻 𝗔𝗜 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗳𝘂𝗹𝗹𝘆 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗶𝗻𝗴 𝘁𝗵𝗲 𝗼𝘂𝘁𝗰𝗼𝗺𝗲.

In some cases, it feels like: prompt → commit → hope 🤞

𝗪𝗵𝗮𝘁’𝘀 𝗰𝗵𝗮𝗻𝗴𝗲𝗱

AI has made writing code faster. It’s made validation harder.

Because AI-assisted code: ◈ Looks convincing (even when it’s wrong) ◈ Mimics good practices without real understanding ◈ Can hide gaps in problem comprehension

So reviewing any code change with AI applied isn’t just about code quality anymore.

It’s about 𝗶𝗻𝘁𝗲𝗻𝘁, 𝗰𝗼𝗿𝗿𝗲𝗰𝘁𝗻𝗲𝘀𝘀, 𝗮𝗻𝗱 𝗽𝗿𝗼𝗼𝗳.

𝗪𝗵𝗮𝘁 𝗜’𝗺 𝗹𝗼𝗼𝗸𝗶𝗻𝗴 𝗳𝗼𝗿 𝗻𝗼𝘄

◈ Does this actually solve the problem? ◈ What evidence shows this works? (tests, logs, screenshots) ◈ Why this approach? Was there real reasoning? ◈ Is this in the right place and approach architecturally?

𝗧𝗵𝗲 𝘂𝗻𝗰𝗼𝗺𝗳𝗼𝗿𝘁𝗮𝗯𝗹𝗲 𝘁𝗲𝗻𝘀𝗶𝗼𝗻

“AI should make us faster.”

And it does… at producing code.

But speed without verification just shifts the risk downstream, to reviewers, QA, and production.

That’s the bit that makes me nervous. 😬

We don’t need to stop trusting engineers.

But we can’t rely on the 𝘀𝗮𝗺𝗲 𝗸𝗶𝗻𝗱 𝗼𝗳 𝘁𝗿𝘂𝘀𝘁 anymore, especially when AI is part of the workflow.

𝗦𝗼 𝗶𝘁’𝘀 𝗶𝗺𝗽𝗲𝗿𝗮𝘁𝗶𝘃𝗲 𝘄𝗲 𝘀𝘁𝗮𝗿𝘁 𝗮𝘀𝗸𝗶𝗻𝗴 𝗯𝗲𝘁𝘁𝗲𝗿 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀:

👉 What are you looking for in PRs now?

👉 Do you actually trust that code has been tested?

👉 Are you reviewing in a completely different way in the age of AI PRs?