I think it's good to challenge received best practices like this - even if in this case the alternative seems to hinge on something that most teams struggle with even more -- writing sufficient good tests.
I favour a less automated solution: code previews.
The biggest reason I've seen for code reviews taking a long time, is that they're surprising. If an engineer has implemented a full solution without communicating their intention ahead of time, reviewing it is really hard because the reviewer is often starting from zero.
1. Communicate your plan ahead of time
2. Check in with the team whenever meaningful progress has been made, and during/after key decision points (you can use draft PRs for this).
3. When it's ready to land, hopefully enough incremental reviews have been done that the final review is simple box ticking (and yes, perhaps it can be fully automated with CI).
Essentially, I think getting humans to look at your code is important, but it doesn't have to be done in a way that feels like a roadblock.
I favour a less automated solution: code previews.
The biggest reason I've seen for code reviews taking a long time, is that they're surprising. If an engineer has implemented a full solution without communicating their intention ahead of time, reviewing it is really hard because the reviewer is often starting from zero.
1. Communicate your plan ahead of time
2. Check in with the team whenever meaningful progress has been made, and during/after key decision points (you can use draft PRs for this).
3. When it's ready to land, hopefully enough incremental reviews have been done that the final review is simple box ticking (and yes, perhaps it can be fully automated with CI).
Essentially, I think getting humans to look at your code is important, but it doesn't have to be done in a way that feels like a roadblock.