Code fixers have fired up the AI warp drive. Strange new worlds await

It is the best of times, it is the worst of times - especially if your job is keeping systems patched and up to date. Microsoft has gone from 60-90 Windows security fixes per month last year to a record of 600+ this July. Oracle and Linux are following the same path, and they are very much not alone. The good news is that a lot of bad things are getting fixed very quickly. The bad news is that patches can bring side effects of their own. There are two mechanisms at work, both driven by the source of and solution to all our woes, AI. The first is that the appropriate LLMs and their humans have got very good at bug hunting. Like demon archaeologists, they've started thrashing their way down through the stratified layers of long-established code bases, bringing a huge backlog of previously buried bugs to the surface. Complicating matters, LLMs are also writing an awful lot of code, some of which is not very good. It is making its way into production for all the old reasons - marketing-led deadline pressure, shape-shifting specs, and Brownian goalposts - until the implacable hostilities of reality spit it back out. The result is a very interesting dynamic of conflicting pressures that is changing the nature of patches. It's easy to assume that the current explosion of bug fixes will die down as the code bases are repeatedly refined and purified, and that this time next year we'll be seeing rather fewer patches than in the pre-AI days, let alone today. It's a nice thought. Similarly, with the old code in a new state of grace, attention can turn to properly generating and testing the AI-powered stuff, so that it too calms down. Other factors will work against this. Newer models may find new classes of bugs or start refactoring for efficiency or structural reasons. Not all patches fix bugs, and not all bugs are vulnerabilities. CVEs are easy to count, but aren't the full story. The pressure to release early won't go away either; better tools often encourage greater recklessness. Vibe check, anyone? Finally, the bad guys aren't going away and will be using all the new shiny to keep up their side of the arms race. This whole system of conflicting pressures in a morphing environment has not been well studied, and the future shape of patching is unclear. One analogy suggests itself, that of stellar evolution. Astrophysics fans know the score. After a star condenses out of gas and dust, gravity compresses its core until it becomes hot and dense enough for nuclear fusion. Hydrogen nuclei fuse to create helium, releasing energy that pushes outward against the gravity trying to squeeze the core further, and the star shines steadily. When the hydrogen in the core runs low, that balance changes. Depending on the star's mass, it may begin fusing helium and successively heavier elements before fusion becomes impossible. The possible endings include explosions visible from other galaxies, black holes, neutron stars, cooling relics, and more. In this analogy, patch generation is fusion pressure, bug generation is gravity, and the nature of bugs and patches evolves as the two interact and the code changes. If any unit of code, no matter how badly written, can contain only so many bugs, then the model tends toward the white dwarf outcome: a remarkably long-lived object that passes the rest of its existence without drama or intervention. It no more needs patching than a pebble does. It is certainly true that, despite the best efforts of many, code design and implementation are ultra-reliable compared with the days when Windows BSOD'd every other day - and on the hour if you installed drivers - and Big Three PC database company Ashton-Tate's industry nickname was Crashed and Late. If the object of the industry was to produce pristine versions of, say, Windows 10, then the white dwarf patchless future would be the most plausible. That is not the industry objective. If a star is big enough, its ending can be a supernova birthing a black hole, a singularity beyond observation where gravity has won. In this case, the battle to write ever-more complex yet bug-free and optimal code is locked in the attempts to find ways to break it, either as part of the production pipeline or in adversarial attacks. If models advance as hyped, iteration times could become so short, and constantly morphing production code so difficult to analyze, that the very model of patching breaks down. The daily build becomes the product, and you get the latest version every time you run it. That may seem an extreme cosmology, but it's not so far from what happens every time you fire up a cloud app. You've never had to patch Google Docs, but you've had features appear and disappear overnight without explanation or warning. This, then, may be the shape of patches to come, a universe where the increasing power of coding and testing models enables new and stranger commercial pressures to modify the software you depend on. You don't have to plot that path. Some software has a more steadfast physics. Not for the first time, those who navigate by the constant star of open source may have the safest voyage. (R)