Code reviews matter in the sense that you need to check the code is reasonably sane occasionally, but that's not the same as doing PRs. Leaving checks to the end has always been a dubious strategy - it's a lot easier to catch problems if you're designing the code up front and then reviewing that things are on track during the dev process. Finding that there's a problem at the end is the worst possible time to change something.

AI has solidified notion that for me. When your team are cranking out PRs at a rate of several a day (not building faster; making small, atomic change requests of independent bits) you'll never have the bandwidth to review everything by hand. You need time at the start to understand the change, lots comms during the process of making the change, and lots of automation around deterministic tooling (linting, formatting, unit tests, integration tests, e2e tests, fuzzing, property testing, smoke tests, etc) to make sure your AI change hasn't broken anything. If you have that in place the need to review at the end of a change is greatly reduced. Down to zero in my opinion but your milage may vary.