Can We Still Trust Our Software?

A few hours before starting to write these lines, I experienced something I hadn’t seen in almost a decade. Visual Studio Code – probably the most used code editor globally, and what I had been using for almost 10 years at this point – crashed. The entire window just died shortly after an update with a catastrophic error, and everything had to be reloaded.

Now, a simple crash should not cause such a hefty judgment as is the title of this article. But if it just was this error, I would hardly be writing these lines. No, it is just the most recent instantiation of an issue that I observe with increasing frequency, and possibly a pattern that we may witness more frequently going forward.

Crashing Software

Software crashes are neither new nor uncommon. Software crashes every day, everywhere, and it did so since the day software was born. The bugs of today may be more metaphorical than literal, but the impact on the functionality of the tools we use every day has stayed the same for decades.

I remember when I first started working on computers, I experienced software crashes multiple times a day. Be it Microsoft Works, video games, or the operating system (Windows 95) itself. Nothing seemed stable. But back when I started playing around with computers, this was acceptable. Everything important was still written down on physical paper. Software crashes were annoying, but even if the computer was so broken it took days to get it back up, this was nothing to worry about, since we (back then school children) had plenty of non-computer activities to choose from.

Later, I also experimented with Linux. In 2005 or 2006, I decided to try out the brand-new Ubuntu distribution for myself. It took me about two weeks (!) to get all the necessary drivers installed so that the OS would properly detect the basic hardware that was present. This was not a nice decision, and, being a teenager, I quickly went back to Windows so that I could get my games to work. Windows wasn’t great either (until Windows 7 came around), but it worked better than Linux.

There is a certain stickiness to the trust we place in technology. I have been burned so much by malfunctioning software that I even hesitated to get smartphones when they came out. When Apple released the first iPhone in 2007, I could not be bothered less. I remember vividly the day I got my first own smartphone, an HTC. I believe it was some time in 2014. Until then, I used a Nokia 3310 (of course), and after that a Sony Walkman phone. All of them had physical buttons. First, it was a necessity (because there were no “smartphones”), then a habit.

It took me years to buy an all-touchscreen phone because I feared what would happen if the touchscreen broke. I really wanted to have hardware buttons because I believed that they would be more reliable than virtual (software) buttons. But, alas, we all have to go with the times, and as such I got an all-screen phone once they were relatively cheap to get, and I had the necessary funds.

Trusting Software

From then on, something changed. I started to trust software to do its thing. Just as I came to realize that, no, touchscreens “just work” unless something so bad happened that would also wreck hardware buttons (like a car running over it), I also started to rely on software more. Besides the fact that term papers and presentations just couldn’t reasonably be made with just pen and paper, software wasn’t as unpolished anymore.

The times of having to pray to the gods of C# that your software let you at least save your work before it died in a fulminant blue screen of death seemed to be over. And it just went better. A year after getting my first all-touchscreen phone, I decided to get a used 2011 MacBook Pro and try out the Apple ecosystem. The switch from Windows to macOS (I’m sorry, Mac OS X back then) was eye-opening. Suddenly, I was actually able to use a Unix operating system without having to spend weeks installing drivers. And, moreover, it quite literally “just worked.” Software crashes seemed to be a thing of the past. While I did retain my habit of shutting down my laptop every night until a few short years ago, I don’t think that this was a necessary precaution to prevent computer crashes.

And every piece of software that came afterward just got better and more stable. By 2017, I had even forgotten that software could crash. Yes, it could still have bugs, and I wasn’t as naïve as to think that I shouldn’t keep any backups anymore. But the frequency with which I had to resort to my backups went to zero very quickly. Aside from a few instances of data loss that, for the most part, could be attributed to my own doing, there was nothing to fear. Software was perfectly stable. I could trust software. Not superficially, but deeply.

The Watershed

And this golden age of software stability would continue for years. Even – or especially – during the pandemic, software was reliable and stable. Whatever I did to my computer, I was unable to make the software budge. I started getting more adventurous with installing untested and highly unstable software on my computer (in early 2021, that was PyTorch with its more than experimental Metal backend support), but alas – it just continued to work.

The same also counts for my cloud setup. I run quite a few servers, the oldest of which is now running almost uninterrupted since 2015. Both the server and the applications on it have worked almost without any hiccups for more than a decade at this point. No matter where I ran software – my computer, my phone, my server – everything just worked; incredibly stable and without many notable issues.

And it continued to work up until 2025. We had a glorious decade of incredible software stability.

But then, something changed.

At first, I didn’t pay too much attention because it just affected the Windows ecosystem.¹ Windows – especially Windows 11 – got worse again, after a phase in which Microsoft did a good job at improving the OS. The watershed for Windows 11 came probably some time around late 2024. Reports started to mount that the quality of Windows was beginning to deteriorate. Users complained about being forced to link their Microsoft accounts to their computers; advertisements in the start menu; more frequent crashes and blue screens.

Microslop

And then, Copilot happened. After Microsoft acquired a large share in OpenAI and thus got exclusive access to its Codex model, they started incorporating Copilot functionality into every corner of the operating system. At least for the general consumer. My computer, which runs on Windows 11 Education (thanks, LiU), has neither seen any ads in the start menu nor Copilot popups. But that may change at any time. In any case, Microsoft has clearly doubled down on pushing generative AI into every corner.

And this has affected every Microsoft software. And I (have to) use a lot of Microsoft software in my day-to-day work.

For example, GitHub. I use both their mobile app, and the platform itself. The platform is still relatively robust. There are no major issues that I could identify, and I use GitHub heavily. But there weren’t any meaningful improvements either. Their mobile app is pretty much in the same shape as a few years ago, too, when Microsoft acquired them. Many of the issues that plagued the app back then still plague the app today.

But what has changed in the meantime is the Copilot integration. And boy, were they aggressive.

The first sign of Copilot being shoved down our throats was when, all of a sudden, a big, fat round button appeared in the GitHub app after an update a few months ago. I certainly did not activate this myself. Instead, it was an on-by-default feature. Since I don’t use Copilot and would like to decide when I do, I quickly turned this off in the settings. The wording for that setting is instructive: It is called “Hide Copilot.” As if it was an integral feature of the app that one could hide if absolutely necessary. Also, one is always enrolled in what Microsoft calls “Copilot Free” – insinuating a subscription that I never signed up for. The wording itself is maddening.

What is worse is when I was authoring a quick change to one of my README files some time ago via the website. When I clicked on “Commit…” all of a sudden, something was filling in the commit message for me. I hadn’t even touched the keyboard, but some text suddenly appeared in the text field. It turns out that Microsoft decided to add a new on-by-default setting that would let their GPT-model auto fill-in commit messages without being asked. And you know the best part? When I immediately headed into the settings to turn this nonsense off, the website told me that I had allegedly “used up” some amount of my “free tokens” for the month. All by the magic of some unquestioned management decision that I sincerely believe the developers implemented regretfully.

Since then, it has been an uphill battle to keep Copilot out of every corner of Microsoft products that I have to use. And I have to use a lot of Microsoft products:

• My university has fully bought into the Microsoft ecosystem and as such, I have to deal with the eternal bugs of Sharepoint every single day.
• This also means having to deal with the insane brittleness of the Active Directory SSO system. Every three to four days I have to fully reset all website data from all Microsoft domains in Firefox to be able to log into Outlook, because of a bug that has been unfixed for 3 years at this point that, when I log in to Outlook, will trigger a logout loop that I cannot escape otherwise.
• On top of that, the usability issues of the GitHub mobile app and the constant new Copilot buttons in every free space on the GitHub website.
• The shenanigans Microsoft pulls with its code signing system.

At this point, I’m actually quite happy that the bugs of its Office suite – Word, PowerPoint, and Excel – have remained the same for the past ten years. Indeed, I have started to appreciate the reliability of Microsoft Office. Yes, it has bugs, but it has predictable bugs, so once you encounter them, you develop a muscle memory to avoid them.

Which brings me back on track.

The Downfall of Software

While my little Copilot rant was somewhat off-topic (I really just needed to vent, apologies), it is also very much on-topic for the broader phenomenon I seek to describe. I don’t want to insinuate that software should be bug-free, both because that’s completely unrealistic, and because that’s not what’s important. Instead, I believe that the big issue plaguing software these days is that previously stable features started to break.

When software has shortcomings, we can account for that. We learn quick ways to work around bugs. A shortcut doesn’t work as intended? We’ll be able to learn a workaround using the mouse that is, while slower, reliable and does what we need. Pasting text directly into an app doesn’t work? Simply leave a text editor window open and paste text in there first. Certainly not as quick as directly pasting into the app we want to, but it’s workable.

But there is also a regression in software behavior that is starting to become noticeable. The biggest example of this is macOS Tahoe. I will never forget how Apple purposefully cut their keynote in such a way that at some point we had, I believe Tim Cook, stand in such a way in front of the logo that it just read “hoe.” And indeed, while I personally think that there are many good reasons for “Liquid Glass,” the issue is that during this revamp of the user interface, a bunch of stuff broke in other places.

One bug that is entirely new to Tahoe 26.3.1 is that keyboard layout switching is broken. As a refresher: I still use a MacBook with a German keyboard layout (a mistake I will fix with the next purchase), all my keyboards use the American ANSI layout.² This means that I have to frequently switch layouts between en-US and de-DE. Thankfully, Apple has made that as painless as it can get: Simply press Ctrl+Space. This will toggle between the two keyboard layouts I have configured. Or rather, it should. Since the last update, I have noticed that this isn’t as straight-forward anymore. Today, when I need to switch between layouts, I first have to press Ctrl+Space for a second or more, then release the keys, and then press it again. If I’m unlucky, I have to repeat this process a few times until the operating system will actually switch to the other keyboard layout.

I am not going to bug you with any additional macOS bugs, since these have been documented plentiful elsewhere. Instead, I want to draw a bigger picture here. The big issue with Tahoe was not that it had a somewhat bumpy launch, and that the new design system faced issues. This is to be expected and not dramatic. Every new feature has a bunch of bugs that need to be ironed out. No, the problem with Tahoe is that it has broken things that previously worked well. If you introduce a new feature and that has a bug, users can adapt and develop workarounds. But if you have a feature that has worked for years prior, and suddenly that once reliable feature breaks, this is an issue. Because users have developed muscle memory, and if that muscle memory betrays them, this is a big deal. Because this will have a halo-effect on the rest of the software for years to come. Users still haven’t forgotten the regression in the iOS virtual keyboard that led to it quite literally typing the wrong keys.

This is what I believe to be the biggest issue right now: That once stable features start to deteriorate. What was once reliable and safe suddenly is brittle and could fail at any time. It seems impossible to trust your software.

Betraying Trust

And this is a bigger trend I wish to draw attention to in this article. I may be salty about Microsoft sprinkling Copilot everywhere you don’t look, but Copilot is usually a new feature that wasn’t there before, so we have no expectations towards it. Some may like it, some may not, but we all see it initially as a new feature that could be buggy, and so we don’t trust it. If it at some point starts working perfectly reliable, we will eventually start to trust it.

But the opposite is what is more concerning: When once stable features suddenly, and out of the blue, stop working.

A few weeks ago, such a thing happened, and I am still surprised by the fallout it had. A few weeks ago, Zotero 8 launched. As is customary with every new major version, I spent some time to study the Changelog before updating, and carved out an hour or so to be able to mitigate any issues. So I pulled the plug, and updated Zotero. And it worked well.

But a few days after the official release, I started seeing reports on the Zettlr forum that the citation key autocomplete was broken. For me, it wasn’t, so I was very puzzled why that may happen. Was it a bug I overlooked? No. A few hours later, a colleague sent me his also broken citation library. I loaded it into Zettlr and realized what was wrong: Somehow, citation keys were missing. I have written about the issue elsewhere, so here is the gist: With Zotero 8, the developers finally added a dedicated field for storing citation keys; a feature that for the past decade has been provided by one of the staples of Zotero – a plugin called Better BibTex (BBT). However, apparently this change was not at all communicated beforehand. Indeed, if you study the changelog for Zotero 8.0.0, you will not even find an entry announcing this change. It was silently done.

Since BBT was providing its own citation key logic, the plugin and Zotero were suddenly competing for attention. And this was an issue, because BBT is installed of thousands of Zotero installations globally, and therefore broke a lot of users’ setups. On the one hand, plugins always come secondary, and will need to adapt to whatever the main software decides. But BBT is one of the core plugins for Zotero. And apparently, Zotero didn’t communicate this change at all. Cue three weeks of frantic back-to-back updates for both Zotero and BBT in an attempt to re-harmonize how the plugin works with Zotero. Zotero itself even released a patch that explicitly disabled unstable BBT versions. That’s how bad that got.

And users were left wondering: Why was Zettlr’s citation key autocomplete broken? Or, worse (this happened to me), why are all my cite keys gone? Indeed, in my case, after restoring the cite keys, some (where authors and years of multiple items were the same) even got swapped, meaning I will have to carefully double-check every citation for those papers not yet published to ensure I actually cite the right stuff at the right time.

In short: It was a mess. And a significant breach of trust. Because the citation key feature worked so incredibly reliable that I didn’t realize that Zettlr, for the entirety of its existence of almost 10 years at this point, simply could assume that whatever CSL files Zotero would spit out with BBT, they would be properly formatted. I never heard any complaint about that in the past decade. And now, suddenly, my users were all over the place because stuff started to inexplicably break. And my software had to stop assuming, or trusting, that Zotero’s outputs were all well-formed.

This is not compartmentalized to this one anecdotal episode with Zotero. The casus belli for writing this article has been another piece of software, the one I started the article with. Visual Studio Code, or VS Code is the default development IDE today, having supplanted most of its competition over the past ten years. I myself use it, too, exclusively. It works for my PHP workflows, for my Node.js workflows, and my Python workflows. Hell, it works almost as well as RStudio in R workflows.

But for the past year, VS Code has seen a serious downgrade in terms of support. Previously, every monthly upgrade would have a bunch of fixes and features scattered over the user interface. But ever since Microsoft decided to go Microslop, the changelog of VS Code every month was a disappointment: 95 % “Copilot improvements,” and 5 % “Miscellaneous bug fixes.” Now, don’t get me wrong: Please, if you want to, add a bunch of AI-related features to your apps. I don’t care too much. And in the case of VS Code, I am able to disable all of it with a single setting.³

No, the real problem with VS Code is that the energy of the developers is turned so much towards Copilot improvements that existing and previously reliable features just break. Within the past 48 hours, I experienced (a) the built-in terminal disintegrating, and (b) the app outright crashing. What makes these two issues so detrimental is not that software is not allowed to have bugs. No, it’s because neither of these issues has happened in the past 7 years of me using the software daily. I have come to trust VS Code to just work. It has never crashed, and the terminal has never malfunctioned before. Again, mind you: I use the software for hours every day.

If you allow me (in this very long article), one final example: Nextcloud. I have been using Nextcloud for more than a decade at this point to keep my important documents available both on my computer and on my phone. And it has always worked pretty flawless. One setting the app has is that you can tell it to not automatically sync folders over 500 MB. This setting has worked well for the past eleven or twelve years. But a few days ago, I noticed something weird: A file that I knew I had placed in the correct folder was nowhere to be seen when searching for it on my phone. It was a PDF of a new research paper that I added to Zotero. So once I was back home, I double-checked: the file was indeed where it should be. It just wasn’t synchronized. And that’s when I noted a yellow exclamation mark next to the folder. Hovering over it with my mouse told me what was going on: “Ignored folder.” Why would it suddenly ignore a folder that has synchronized for years prior?

What I assume must have happened is that a recent Nextcloud update has messed with the setting of which folders to not sync. And this has led to quite a few folders never synchronizing. Without telling me. After fixing these settings in the app, the next problem occurred: Because some files have been heavily edited (*cough* papers in R&R *cough*) after Nextcloud decided to stop synchronizing them, I now of course had merge conflicts. And of course, it came at the worst time: Shortly before a deadline. Thanks to meticulous backups, I only lost about an hour of work. But it was still an hour of work that nobody could ever give back to me. Nextcloud, too, betrayed me.

When VS Code crashed this morning, I didn’t lose any data. At least the data retention of VS Code is remarkably reliable, so that feature is still not lost. But it was the one instance too many that finally made me stop and think. Our software is disintegrating, and if things go really awry, data loss in VS Code may become a thing in the future.

Final Thoughts

What do we make of this? Can we still trust our software? For now, we can. In this article, I barely enumerated instances of where software went wrong. I left out the much more plentiful instances of where software just works. But I think these few instances are a canary in the coal mine. We are not dead yet, but the bird is telling us to better get out. Yes, we still can trust software. But if these instances aren’t some spurious blips, software is starting to deteriorate — primarily consumer software. And once consumer software deteriorates further, what shall we do? Go back to pen and paper? Mistrust touchscreens? I highly doubt it.

I also do not think that these signs of deterioration are all caused by the advent of AI. That would be a wrong conclusion. Yes, AI certainly has made sloppiness part of the daily developer business, but the causes of the issues I have outlined here go far beyond this. There are middle managers forcing developers to implement features nobody has asked for, diverting scarce resources away from maintaining core functionality. There are communication issues that could be avoided by understanding the user base better. And there is what developers frequently call “software rot,” when software issues just don’t get fixed because the application is too large to have anyone keep an overview over it. There are simple hiccups that cause deterioration, and there is cohort change, where old senior developers leave with a bunch of intrinsic knowledge that the next generation has to start building up first.

The causes of software deterioration are as plentiful as there are applications on the market. But one thing is clear: Something has changed, and that is causing more and more issues across apps. The question is: what will we do? Will we just continue as we were, hoping that our data at least won’t be lost in a catastrophic crash? And what will developers do? Will they be forced to work on new shiny feature that some focus group has shown may increase user retention, instead of finally fixing that one absurdly outdated dependency with ten CVEs?

I honestly don’t know, and I’d argue that this article is more a rant than an analysis. I don’t like the developments I see, but I also lack the data to put a proper causal mechanism behind this. Is it just a fluke? Possibly, but given the amount of errors the many pieces of software I use every day exhibit I doubt it to be a simple coincidence. However, I also strongly believe that there is no monocausal explanation for what is happening.

We will have to see where all of this leads, but I hope that the software we all trust gets back on track soon. Yes, we can still trust our software. The question is: will we be able to trust it in ten years from now?