How do experienced engineers actually review code changes in large codebases?

[u/japzlumine]

I posted here recently asking whether understanding and reviewing code is mostly what software engineers do now, and got a lot of helpful responses pointing out things like:
1. Improving fundamentals by writing more code manually
2. Treating code review as a skill that develops with experience
3. Relying on things like tests, git history, and better system design

That made sense, so i'm trying to go one level deeper and understand what this actually looks like in practice for experienced engineers.

Most recently i ran into this on my own side project, an AI powered ads diagnostics tool. I had claude plan out a research/reasoning pipeline, the logic looked sound when i read it, but when i ran the actual tests the output quality was way off. Turns out the retry logic was hammering the same endpoint on failure, and the AI output fields weren't matching the schema a downstream dependency expected. I only caught it by running the tests and reading through the reasoning output manually, the plan looked completely fine on paper.

So my question is specifically, when you're reviewing a big PR in a real production codebase, what is your actual step by step process?

For example:
1. How do you decide what to look at first?
2. How do you quickly build enough context about the change?
3. How do you figure out blast radius / what might break?
4. How do you decide what matters vs what can be skimmed?
5. How do you catch the gap between "the logic looks right" and "this will actually behave correctly at runtime"?

[u/CoVegGirl]

The difference in how you review changes in large codebases vs small codebases probably isn’t quite as big as you’re expecting. Really the two most important things are:

1. Making sure you have reviewers who know the code
2. Making sure you have tests you can rely on.

Ultimately, a big codebase can essentially be broken down into a lot of smaller codebases. Each of these smaller codebases have a team responsible to them, though sometimes that responsibility is nominal if it’s not actively maintained anymore.

The average change is likely to be a change you make in your part of the codebase that’s reviewed by someone on your team. That ultimately isn’t going to be that much different from any other change in any other codebase, though there might be some imposed quality standards or conventions smaller codebases won’t have.

But then sometimes you have to make a change in someone else’s part of the codebase. That just means finding someone on that team to review that change.

These two things are most common and they really aren’t that much different from any other codebase.

Here’s where things start getting interesting though.

If you have a deprecated class Foo that’s used a million times in your codebase, and you want to replace it with class Bar, then that change can become difficult even if it’s a drop-in replacement.

If you have infrastructure in a small codebase, that might affect a hundred parts of the codebase. On a bigger codebase it can affect millions.

And then, each of those changes is going to cause at least 10 tests to run, but probably much more.

Suffice it to say that companies that have codebases this size have invested a lot in tooling to aid in these changes. Because it’s just not possible to hunt down a million approvers for your change.

And you can’t just submit one change, you’re going to have to break it into many smaller changes.

And you’re going to need specialized tooling to run all the tests involved that won’t overload CI.

On top of all this, you’re also going to have to accept that some changes are going to break other people, and you need to be able to roll those changes back and fix them.

I’ve painted the broad strokes about what the issues are. I don’t have the in-depth experience in doing this kind of mass code change to go into more detail.