So, why would you review thousands of lines at a time? That means you didn't break the problem down appropriately. PRs should be around 100-200 lines of code, including tests. You build your tasks appropriately.
Reviewing thousands of lines at a time is always a failure state.
The number of lines you have to review at once doesn't matter.
Vibe coding is letting AI write code so you spend less time writing the same amount of code (ideally not more, in practice definitely more).
If more code is written you have to review more code. Doesn't matter if you break it down in 10 lines PRs or if you review a million lines at once, you still end up having to review all the code generated.
Is this a 1-person dev team? Because on teams, one person has to submit a PR and then someone else on the team has to code review it, right? So then you're doubling the review time of the code. If you wrote the code yourself, you would already know that it works, then you submit the PR, and then someone else reviews the code one time, not twice. And typically reading and understanding code you did not write takes longer than writing the code yourself. It does not seem like "AI" coding is really saving anyone any time, and is probably wasting more time than it saves.
It entirely matters. It matters because as humans, we can only keep so much context in mind. That means that if you are looking at 100-200 lines at a time, you can think about the architecture. You can modify the code, whether it's fixing or refactoring. It means that it can only get too far off base.
It also means that sometimes, you say "this is bad code," refine the prompt, and run it again.
Yes, it means that you as a code reviewer is a bottleneck. It means that you are limited to the productivity gain that can exist. We are talking 10-15% productivity gains per person in mature code bases, not some magic replacement.
But if you're worried about reviewing code, maybe we shouldn't allow junior programmers to contribute to codebases either. After all, you might make a mistake in reviewing that.
PRs are as long as they need to be and as short as they need to be. This idea that any problem can be decomposed into 100-200 line changes is ridiculous. That's not realistic in many cases (esp. for refactoring work, etc.)
There are certainly exceptions. And if a problem cannot be decomposed, then you have a "stop the world" formal code review with a team-wide multi-hour dive into the code.
In my world, though, we use the refactoring tools such as feature flags and incremental improvements. We can use stacked pull requests. It requires training and discipline but it's absolutely doable for 99% of tasks.
Reviewing thousands of lines at a time is always a failure state.