The tools are great such as Cursor, Windsurf, . but they only work upto a point of complexity. Beyond that, developer expertise comes into play. The tiny nuances of the application like which version of API to use, how to use them extra is dependent on the developer prior experience.

Tools like replit are idea to product and feel like it is prompt to a fixed typescript kind of stack based product.

The argument for the vibe coding side could be that best developers are able to write better prompts. But based on my experience, that stuff works only till mvp or medium complexity code and not for complete framework level code.

Also, regarding microsoft, I use Windows 11 home Edition of Microsoft and it crashed two times via updates. Although, i was able to restore it via restore point. A paid software product that doesn't cover user data protection in its warranty is not really a great product.

A lot of this is also recreating tooling. A mature framework like Ruby on Rails solves things like

> "when I hit save, my data disappears."

out of the box, because it has evolved to make these things automatic and easy to implement as part of its convention. Whatever full stack JS framework is hot for startups these days doesn't do this out of the box because it hasn't been around long enough and focuses on other things.

The number of times you are going to run through the new functions of your software during QA is in the hundreds. Automated testing only counts as one test because it does the same test over and over... it is a solid practice, but it is a safety net against regressions, it is not actually putting the software through new environments, scenarios, and usage.

But get that software out in the field, grow its userbase, run it for years, and you have thousands if not millions of different uses of it. Take all the bugs that come out of that, fix them, and you have software that is less buggy.

So sure, inexperienced teams put out bugs. I do, too... more than I should. Hopefully the egregious one's where it simply does not work never get to production. But the more nuanced bugs and their eventual fixes come from the software running in the wild.

So if you are the pilot user for new products, you will see all those early bugs.

Writing good software takes a good amount of time - you can catch bugs like this in so many ways but ultimately they should be being caught, tests should be failing in their deploys or their commits or whatever, but they will only be caught while companies invest in good software practices. We're in a midway point between humans being undesirable to do this work, and AI not quite being good enough by itself (yet), so I think buggy software will have a golden age the rest of this decade lol!

I m more surprised by old programs that worked being updated with obvious bugs. Right now , when you open any youtube video on a web browser, the video settings menus pop up for a second or so (probably some kind of css not hiding it). This is one of the most visited sites on the planet.

Years ago, before the Internet, software was expected to be rather buggy. It took a long time to research and fix. Releasing software was expensive, you had to put it on physical media and ship it. QA was critical role, it was way less expensive to test the hell out it and fix it than it was to ship new code. The idea that computers could be trusted to perform tasks well was easily shattered when things went wrong, and the additional optics of losing customer trust went a long way into driving QA.

Fast forward to today, and it's way cheaper to ship code with bugs to prove out an idea works than it is to spend even a few minutes writing test cases and doing even a modicum of QA.

Ultimately, it's a not just a combination of all 3 things you've mentioned, which are all contributing factors; the real problem is any level of QA before proving an idea is seen as a waste of time and money. As someone who started in tech support & QA 30 years ago, it's really tough to see.