Three stories logged on this desk look unrelated on their face: IBM and CoreWeave co-designing controls for agent workloads, Pixel users unable to make tap-to-pay work, and Epic pausing product development to fix security bugs. The pattern that runs through all three is that software has stopped behaving like a finished product and started behaving like infrastructure that must be continuously maintained. The companies that built these systems are now discovering that the cost of keeping them working has become as significant as the cost of building them in the first place.
The shift from building to running
The IBM and CoreWeave story, reported by SiliconANGLE, describes a moment in which research teams are moving beyond training models to running code and testing agents. That transition sounds incremental. It is not. As the story notes, systems built for intensive computation must now accommodate workloads that interact with tools, storage and other services. Reinforcement learning and agent testing are not batch jobs that finish and free their resources. They are persistent, stateful, interactive processes that need isolation, access control and continuous coordination with the rest of the environment.
This is the same inflection point that arrived years ago for cloud infrastructure and again for container orchestration. A capability that was once a research demonstration becomes a production dependency, and the operational requirements change shape entirely. IBM Research's infrastructure, the story says, must support increasingly varied workloads as its model development practices evolve. That is a polite way of saying the old assumptions no longer hold.
Consumer software shows the same strain
The Pixel tap-to-pay problem, reported by ZDNET, looks like a different category of story entirely. A consumer feature stops working, users are frustrated, and there is no fix from Google yet. But the underlying dynamic is identical. A payment system that depends on near-field communication hardware, secure element firmware, a wallet application, a bank's tokenization service and a merchant terminal is not a single product. It is a chain of dependencies, and any link in that chain can degrade.
What is notable is the response pattern. ZDNET reports that there is no fix from Google yet, and that the workarounds offered are things that helped other users. That is the language of a system where the vendor has lost direct control of the failure mode. Tap-to-pay is now a service that must be kept running across many parties, not a feature that ships and stays shipped.
Security work is maintenance work
The Epic story, reported by TechCrunch, makes the point most explicitly. The health technology company, which makes the widely used MyChart system for accessing medical data, is pausing product development to fix security bugs for the next few weeks. A pause of that kind is a significant decision. It means the organization has concluded that the accumulated maintenance burden has become more urgent than any new feature it could ship.
For a company in Epic's position, this is not an admission of failure. It is a recognition that the security surface of a large, widely deployed system grows over time, and that the work of addressing it cannot be deferred indefinitely in favor of new development. The story frames the pause as a focus on fixing security bugs that risk patients' data. The risks are not hypothetical, and the decision to stop shipping in order to address them is the kind of trade-off that more software vendors are going to face.
