Plenty of code is written and merged in without proper code review. It can work. There's a reason why it's called code smell not "broken code" or something to that effect. The lack of code review is a warning sign, not a harbinger of doom.
The solution to this problem is that there is no one solution to fit all cases that we can pack into a StackExchange style answer. It is the strong consensus of the software development community that code review is a crucial "best practice," and in this case it is being skipped. Your development is no longer in that narrow channel of "following all best practices." You will need to find your own way.
What is a "best practice" anyways? When you get right down to it, it's a set of practices which people generally think make code better. Do they make code right? Heck no! The internet is littered with stories from companies who followed "best practices" and got themselves jammed up by it. Perhaps a better viewpoint of "best practices" is that they are the "fire and forget" solutions of the software world. I can know nothing about your company, your project, your team, and be able to quip off "best practices" as things that will help you out. They're the general "do no harm" advice.
You have clearly deviated from this plan. Fortunately, you recognize it. Good job! They say knowledge is half the battle; if so, awareness is well over half of it! Now a solution is needed. From your description, it is clear that the business environment you are in has evolved to a point where the boring advice of "go do the code review, it's best practice" isn't going to cut it. For this, I recommend a key rule that I use when it comes to software best practices:
No software development best practice trumps a business need.
Frankly, they're paying your paycheck, and the business' survival is typically far more important than the quality of the software. We don't like to admit it, but perfectly written software is useless if it is trapped in the body of a company dying from its efforts to sustain that perfectly written software.
So where do you go? Follow the trail of force. You have pointed out that, for some unstated reason, it is unreasonable to undergo a code review for some task. In my experience, that reason is always temporal. It's always either "not enough time" or "not enough money to keep the salaries flowing while you spend the time." This is business; it's okay. If it was easy, everyone would do it. Follow the trail of force upwards, and find the management that is in a position to help you understand why a code review is not an option. Language is hard, and quite often a decree will trickle down from the upper management and get distorted. The solution to your problem may be hidden in that distortion.
The answer to this is, necessarily, a specific case scenario. It's akin to trying to predict whether a coin toss will be heads or tails. The best practices say to flip it 100 times and the expectation will be roughly 50 heads and 50 tails, but you don't have time to flip it 1 time. This is where the details of your situation matter. Did you know that a coin will typically land in the same orientation it was tossed from about 51% of the time? Did you take the time to observe which way the coin was before tossing? It could make a difference.
One general solution that may be available to you is to try to find a way to draw out the code review process and make it a very low cost effort. Much of the cost of a code review process is that everyone is 100% dedicated to the code review while you are doing it. This has to be the case because, once the code review is done, the code is blessed. Perhaps you can put the code in a different branch, and do the code review in parallel with development on the main trunk. Or perhaps you can even set it up so that the software does the testing for you. Maybe you are in a business environment where your customers can be running the "new" code in parallel with the old, and having them compare the results. This turns the customers into a bunch of use case creation devices.
A key to all of these running "maybes" is that you should strive to make your code easily broken up into pieces. You might be able to "prove out" pieces of the code without relying on a formal code review by using them in less mission critical projects. It's easier to do this if the changes are in smaller pieces, even if the sum total of them is too large to peer review.
In general, look for solutions specific to your project, your company, your team. The general purpose answer was "best practices." You aren't using those, so you should look for more custom tailored solutions to this problem, this time. This is business. If everything went the way we expected all the time, IPOs would be a whole lot easier to assign values to, wouldn't they!
