I think it very much depends on what you're working on, and how much you're responsible. For a web front end, not really. A backend where a single line can make a mess out of your data? Yes. Part of the issue too, is code review brings up things you the prompter didn't think about that another teammate may be thinking about. The value goes beyond making sure the code is "correct", but also that it makes sense in your domain.
The "we don't read/write assembly anymore" argument doesn't fit though. Given an input x we know without a doubt we'll get output y. With an LLM, that isn't the case no matter how many guard rails, specs, markdown files, diagrams you give it.
I actually read the frontend code much more than the backend code for the project I'm working on.
Backend code I'm fairly comfortable if the tests are good that it works correctly. It's a much more constrained environment. Obviously there can be things like performance issues that creep in or problems when it mocks too much of the environment.
Meanwhile frontend code I have to consider different browsers, screen sizes, a11y issues, and so on, which agents can certainly do but you have to be fairly explicit about it, and they don't always make the best tradeoffs.