Prior to AI, this would be an easy answer. If the code is well written, small, covered by tests, the PR has a clear spec of what it is doing, and the author is trustworthy (meaning they know, or seem to know, what they are doing), most of the time you just scan the code to check it won’t hurt anything and merge. With AI, it gets trickier: the person submitting the code may not be the one who wrote it. How do we trust that?

This is exactly what I asked a few of my team leaders a couple of weeks ago: “What would it take for you to merge a PR without even looking at the code?” We had a bunch of answers, and in the end the conclusion was that it’s not different from what it was prior to AI. Namely:

• small, well-tested changes
• all CI checks pass
• a clear goal
• the PR is sized to the problem, no bigger, no smaller

Those are the PRs that are easy to merge, and that shouldn’t change regardless of whether AI or a human wrote the code.

If your process wasn’t mature before AI arrived, you won’t be able to capture the speed benefits AI offers. AI will produce far more code than we can ever review, and we have to be able to move fast. That means we have to be able to verify quickly if the code is harmful or not. That can only be achieved by automation, checks that verify (among others checks):

• the code does not introduce new security problems (Dependabot, Snyk, etc.)
• the code does not add excessive cyclomatic complexity, duplication, or similar code-smell signals (SonarQube, CodeClimate, etc.)
• the code is not doing something it was not supposed to be doing (This point is trickier and still need a human reviewer to judge.)

For the first time in my career, a developer has zero excuse: not to write tests, not to write meaningful and succinct documentation, and not to ship an end-to-end test that proves the fix works across the stack without introducing regressions. We should leverage that.

We should use these tools not only to produce more code but also to produce safer code, that is better covered by tests than ever, and code that, even if humans aren’t reading all of it, is easy to replace when the time comes. I’ve said more than once on this blog that good design is easy to change. That remains the core of good architecture in my book. With AI, even more so. If something is hard to change, if a change is touching way too much code and moving way too many parts, you probably should step back and check if that’s the direction you want to go. The design principle hasn’t changed.

Conclusion

Your answer to “what would it take to merge a PR without reading every line?” shouldn’t depend on whether AI wrote it. With a mature process, tests, coverage, and a clear understanding of the change, the decision is easy. Without those criteria, it’s not a PR worth merging. There will always be PRs you want to review carefully because they are bigger, more impactful, or riskier.

But there will also be PRs that are small, incremental steps forward, and it should be easy to scan them, merge, and move on. With AI we should have those on steroids, many small, incremental changes moving forward. If your process or tools don’t allow that, go back and fix them; otherwise you’re going to miss the speed this thing can bring us.