By constantly learning from the bugs that you do push to production.
What if I told you that every engineer will push at least 100 bugs to production in his/her career and every bug is a learning opportunity to become a better engineer. Every time you delay pushing code fearing bugs, you are delaying some valuable learning. If you accept the fact that you will not push perfect code all the time, then it frees your mind to focus on other things, like monitoring or testing so that future bugs will be caught quickly. If you are repeating the same mistakes, then you should step back and think about whether you are actively learning from them. So, rather than worrying about preventing bugs entirely, you should focus on causing new types of bugs to progress as an engineer.
Here is another way to think of it. Rather than thinking of reducing absolute number of bugs, think of the ratio of positive impact of your features to negative impact of the bugs that you have pushed. So, if you can move quickly and push more features, then you can live with a couple of non-severe bugs along the way. But if you delay pushing features due to fear of bugs, then the amount of impact that you can have in a given period of time will also be limited. The bottomline is that your impact is not dictated by the number of bugs that you caused but the positive value of your total output.
This might seem counterintuitive but some major bugs are often caused by the very best engineers. This is because these engineers work on big, complicated projects which usually result in significant positive outcomes when things go well and huge negative impact when bugs happen. So, if you have the chance, just talking to them and listening to their war stories can help build confidence. Happy coding!