Have you noticed that a bunch of things that previously worked (and often which worked well!) suddenly, well, don’t? Google returns wrong answers. Websites and apps that were previously snappy and easy to use are now slow and clunky. Previously routine processes suddenly failing for no apparent reason. Spell check and text autocomplete seemingly becoming illiterate overnight. It’s even noticeable with things like the volume on a national sports broadcast fluctuating wildly mid-broadcast. It is uniquely horrifying to be a long-term unemployed software quality assurance engineer right now while all of this is happening, but that’s exactly the situation I, and countless others like me, find myself in.

As a software quality assurance engineer, a main focus of my job (when I have a job…) is to test things like software and websites. This includes things like verifying that all of the requirements for a given feature or piece of functionality have been met, making sure everything looks and behaves as intended, ensuring that any new changes have not broken existing features and functionality, and otherwise making sure that the product is ready to be used. Ideally, any issues will be identified by the QA team during testing and will be fixed by a developer before they are exposed to the end user. In addition to identifying and reporting any issues and defects, once a fix has been created, it’s the QA team’s responsibility to test to verify that the issue in question has been resolved.

Unfortunately, many companies treat QA like an afterthought at best, or as an active hinderance and even sometimes as an adversary at worst. That attitude isn’t new; those kinds of sentiments have been around since the dawn of programming. Treating QA like an unnecessary time and resource sink was already becoming more widespread as automated testing has become more ubiquitous, and it has only intensified in the age of products like Claude Code and GitHub Copilot. As more and more teams have adopted the language of shifting left, it seems executive suites are taking the opportunity to thin the herd. But that decision is leading to products that become exponentially worse and worse as time goes by.

As the enshittification worsens year after year, it seems less and less likely that our tech broligarch overlords will feel inclined to reverse course. Despite the steep decline in quality of almost every conceivable product and piece of software, there is a profound dearth of open software quality assurance roles. The vast majority of open QA opportunities that do exist actively add to the problem by way of training AI models that are intended to be used to phase out even more QA roles. Many of the open QA roles that aren’t for training AI are starting to require the use of AI tools “to increase productivity and efficiency.” The thing is, LLMs hallucinate by design, and accuracy is something that is genuinely integral to quality assurance, which means it’s actually not helpful or okay to use tools that will lie to you for that purpose.

I should acknowledge that hiring back QA is not the end-all, be-all solution for the problem of “everything is trash now.” However, to say that the current state of affairs is demoralizing is an enormous understatement. It’s impossible to have this professional knowledge and experience and to not be acutely aware of how badly people who do what I do are needed. Not to mention that it’s infuriating and depressing to watch everything deteriorate in real-time. The dissonance is almost painful, knowing that even though there is an enormous need for people in my profession, that I will likely hear nothing more than an automated rejection email back from the dozens or more resumes and applications I submit this month, just as it’s been for the last almost fifteen months.

But hey, surely at some point or another, companies might care about the quality of their products again, right? …right?