The biggest issue I can see is that you probably won't reduce the bug count by any significance, but you will increase the pressure and stress on individual developers.
What you need to look at is why and how these bugs are occurring and getting through to production.
First up, communication. Do your developers talk to each other as they work on tasks? Do you talk about architecture and solutions in your scrum/sprint planning? Or does your team just agree to a bunch of stories at the start of the sprint and then work separately with just the morning standups?
Try to encourage pair programming - this will help with information flow, and should have a direct impact on big count. It doesn't need to be a full time thing - but you should try for at least 25-50% of the time. It might seem counterintuitive (two devs on one task!) but it can speed up development time with the information flow, and reduce bugs.
And document - make sure work is properly scoped in a way that covers potential side effects and impact. Also try to score stories and tasks such that they are as small as possible. Small changes have less side effects, and are easier to review (more on that later).
Next up is process. Automated testing and continuous integration is a must in modern software development, and has a pretty low bar for implementing these days.
Have your developers run a linter before they push code to catch silly mistakes like missing semi-colons. Get a static analysis tool to help identify issues with loops and conditionals and so on.
Agree to a coding style - having a standard style helps decrease bugs by ensuring things like all if blocks should be braced even if they're just a one liner (making it is harder to accidentally add a line of code that should also be in that conditional - a famous Apple bug), or switch statements must have a default. Have a tool that tests that style and automate it.
Implement automated testing. Try and do as small a unit as you can in these tests, but don't slavishly aim for 100% coverage. Sometimes a feature test is better than heavily mocking an MVC framework, for example. Testable code is also usually better structured and easier to change safely. Use tools that let your developers quickly and easily test what they're working on, without needing to run the full suite all the time.
Automate all your testing so that changes are tested by your developers before they push, and also on your repo after they push. Github, Bitbucket, and Gitlab all have CI pipelines to help with this.
Make sure your developers are rebasing their branches from master regularly (or at least before opening a pull/merge request) so that they can test their code against the latest master.
Have code reviews. Again, tested, documented, and tightly scoped work will make this easy. Larger changes should be reviewed as a pair between the reviewer and the original developer. I've heard of places that have a six-eyeballs rule - so, it a feature is developed as a pair, then a third person must review it. If a feature is solo developed, then it must be reviewed by two people.
A lot of this may seem like it would slow development down, but having good processes in place will reduce bugs, and will speed up development.
If the odd bug or two still gets through, look at what may have broken down in your process and try to change it. If it turns out that a particular developer is bucking the process, then hold them individually accountable. But until that point, bugs are the whole team's problem.