I think your question creates something of a false dichotomy. In reality, the decision is not binary ("do I code slowly and carefully, or quickly and recklessly?"), but is rather on a spectrum. The two options you presented are at either extreme.
Exactly where on the spectrum you want to be depends a lot on the particular product you're working on and what your customers expect from you. You need to examine the constraints you're working with and then make an intelligent decision about what kind of process you want to use.
For instance, if you're in a position where it's very expensive to correct mistakes, or where failures are potentially catastrophic, you want to be closer to option #2. Embedded software, missile guidance code and medical tools are good examples. When fixing a bug would mean recalling millions of dollars worth of hardware, or when your mistake might result in people dying, you need to make sure that you get it right the first time.
The other end of the spectrum is when the business environment demands rapid code changes, but it's easy to fix mistakes and the penalties for failure are low. Web applications often fit this description. Your users are clamoring for new features and business logic changes, and they want them implemented yesterday. If a small mistake in the code is made, it takes fifteen minutes to edit the offending script, get the change code reviewed, and hotfix it. In this case, as long as you manage user expectations properly, they'll learn to ignore the occasional bug as long as you're responsive to their needs and maintain a quick turnaround time. Of course, even when taking this approach, you should still have safeguards in place to prevent against catastrophic failures: keep backups, do code reviews, and make sure you've got a good hotfix/revert process.
I think the reality of software development is that most projects lie somewhere between these two extremes. You usually want to be diligent about preventing bugs, but you may not want a year-long release cycle due to a burdensome QA process.
Aside from the environmental factors I mentioned earlier, I think the best way to figure out exactly where you should be is to evaluate feedback from users. If they're frustrated by long wait times for new features, you may want to trim the QA process a bit in order to be more responsive. Just make sure that you're extra quick about fixing any bugs you may introduce. On the other hand, if they're demanding absolute reliability, then make sure you've got enough safeguards in place to meet that demand as best you can.