To me, this is a bad idea because it has no upside. If changes can wait for two months, then they may be important but are not urgent. But unless you always write bug free code, something will go wrong and you will be singularly irresponsible. To put it another way, it sounds like your organization has adopted a sound engineering practice -- that's what code review is. That makes going around code review bad engineering at a higher level than code quality. Engineering is creating things fit for purpose and here the purpose is the business operations of a particular business.

If you're unhappy at your job, more conventional steps such as talking to supervisors or looking for a new job are often more appropriate than going cowboy. Trying to see the role of your code in the larger engineering context or even the complete business operation might lend a useful perspective. ....gaining an understanding of why the company is both willing to pay you to produce the code but is not rushing it into production will probably give you a sense of what drives the organization's culture. Even if you leave, such knowledge will provide intuition for evaluating opportunities throughout your career because there are patterns.

Good luck.