Everyone agrees that constant updates keep games alive. Seasonal content, balance patches, new features rolling out every few weeks. It's the modern standard. Publishers love it. Players expect it. The whole industry has settled into this comfortable rhythm.
But that consensus is masking something we're not talking about enough: updates have fundamentally broken how games get tested before they reach players.
We've seen the symptoms lately. A Vatican app promoted by the Pope running on infrastructure so shoddy it became a phishing vector. User-created content in a major game distributing malware. These aren't isolated incidents. They're proof that the pressure to ship constantly has eroded the gatekeeping function that used to exist between "finished product" and "public."
The old model had friction. Games shipped when they were done. Quality assurance teams had time to break things. Certification boards existed. Publishers could afford to wait. There was this buffer between creation and consumption.
The live service model eliminates that buffer. Everything is live. Everything is iterative. Everything is customer-facing testing.
We tell ourselves this is fine because "updates can fix things." And technically, yes, they can. But that philosophy inverts the entire relationship between developer and player. It treats end-users as QA contractors who aren't being paid.
More importantly, it's created a blind spot in how we talk about game security and stability. When a game launches with bugs, we call it a disaster. When a live game needs an emergency patch because malware got distributed through its mod tools, we call it a growing pain.
The difference is just a matter of framing. The problem is identical: code made it to production without adequate human review.
The update cycle itself is the accelerant here. When you're committed to pushing new content every two weeks or every month, you don't have time for the kind of thorough testing that catches systemic vulnerabilities. You optimize for speed. You automate what you can. You hope your monitoring systems catch the rest.
Sometimes they don't.
The regulatory angle is coming, by the way. Governments are already poking at loot boxes and gambling mechanics in games. When they start looking at user-generated content distribution systems as potential security risks, publishers are going to wish they had invested in better testing infrastructure now instead of waiting for mandates.
Here's what actually needs to happen: live service games need to separate the concept of "update deployment" from "feature release." Not everything that goes live needs to go live to everyone immediately. Not every piece of user-generated content needs to be instantly accessible. There's room for staged rollouts, for moderation checkpoints, for the kind of intentional friction that quality control requires.
This doesn't mean slower updates. It means smarter ones.
It means accepting that "move fast and break things" works fine for a social media feature. It doesn't work for infrastructure that players are trusting with their time and, increasingly, their security.
The live service consensus got us good games and engaging communities. But it also got us complacent about the actual mechanics of quality assurance. We stopped asking "is this ready" and started asking "can we push this and patch it if something breaks."
Those are not the same question.
Until we rebuild the testing layers that constant-update cycles stripped away, we're going to keep finding out about problems the hard way. And for players, that's an unnecessary bet.