Code Reviews do they really work in true Agile?

Question

So I started working for a large corp., one of those with 3 letters in the name, and they are trying to become Agile, but have tons of processes, which I don't feel are Agile.

The one that has me the most wound up are code reviews. My last job was with a startup that I would say is the most Agile development team I have seen, been on, and/or ever heard of.

Anyway, my argument is that Code Reviews are a waste of time in iterative or Agile development where the UX/UI is extreme/intense (think Apple/Steve Jobs perfection). Maybe someone here can help understand before they fire me?

Here is my development process and the one at my last startup... very Agile.

We do the early feature work to sort development task/todos. We would mock a couple versions up and present to users, team, and marketing to get feedback. We then do another mockup iteration to get one round in from the same stakeholders above. Then we divvy up the work and get started. We have milestones and dates to meet, but we keep plugging away. We have no code reviews during any of this. Several times during the weeks of our development we hold sesssions with the stakeholders again to see if they still agree features/functions/UX/UI are still a fit and on target.

As we approach the end of the 8 week iteration cycle QA starts testing, then it goes to alpha users, and finally to beta users. But during the alpha and beta developers are going over the new features and older features making iterative daily or hour changes to the UI to improve the UX. So a feature that was being developed this release, might end up being changed 3 more times the last four weeks to improve and perfect it or add a few tiny features (e.g. make the component a little slicker or smarter). Sometimes the changes might be superficial meaning no CRUD operations are changed or modified, but all UI only changes.

So with this type of development process, extreme Agile, wouldn't code reviews be a waste of time? Meaning if I had another developer or two review my code, but then that code changes 3 more times before it goes out the door, because of all the UI/UX improvements, are we not wasting our time for first 3 times they reviewed it the code as that code/component/UI was scrapped?

We never had many quality issues with this process and yes if a developer left all the knowledge walked out the door, but we always found smart developers to pick it up and takeover.

And yes, we have a lot of testers because they may have to retest things 3 or 4 times. Also please don't get hung up on asking why all the UI/UX changes...thats just how things are done... been then thats why the app wins tons of awards for UI/UX and the users will kill for the app. The thought process is if I can make a even a 2% improvement in something because I have an extra hour then do it. Users will be happier, which means more $ or users. And yes, our users are ok with the app changing continuously because thats how its been done since day one so they don't see it as bad or a negative.

Hope this post doesn't come off as pompous, but I just can't see how Code Reviews aren't wasteful. Maybe 2% of all our code in the code reviewed has bugs. Each release we might find 3 bugs via code review. So it ends up being 40 hours of code review per developer per release (4 x 40 = 160 hours) to find 3 to 5 bugs? Chances are 50% those 3 to 5 bugs would have been picked up by QA anyway. Wouldn't it be better to spend that 40 hour per developer adding a new feature or improving the existing ones?