QA never meshed well with me. Their job seemed to be gaining context on what I was working on and then testing it for me, but if they caught a bug it was on me. QA catching something was treated as a negative reflection on the dev, so we still exhaustively tested everything before it got too QA, which made them seem pretty redundant.

This is certainly a data point, but there are a bunch of companies that have qa. The one thing I'll say is that there seems to be an inversion between was and fast ci/cd. When you have people turning over production worthy code daily, the idea of having dedicated resources to "check your work" kinda falls over. Anyone with sufficiently critical systems and doing regular deployments needs to be able to verify their changes as streamlined as possible, and using QA a staff with their own sets of problems, managers, standards, etc. seems to contradict the "ship it fast(if we need to)" mentality in ci/cd shops.

That said, there's room to help devs in this world, and I'm not entirely sure if this is a lack of software, or a need for a human in the mix, but there's certainly gaps that can be filled to help the quality of releases that go out the door in these shops.

That does seem to be a current trend. It actually might swing back though. It also depends on what industry you're in. If you can "move fast and break things", you may not need/want QAs. But in Healthcare and finance (for example), you probably want QAs.