= 2026: Software is dead, long live software :date: 2026-10-22 :summary: How we're living in interesting times :category: Featured A personal account, followed by thoughts on where we could be going. // Trying to describe the feeling I got from LLMs. [quote, Alan Kay] Inverse vandalism: the making of things because you can. == Introduction Imagine amassing complex problems for a large part of your life, only to see them... become simple. Imagine having strong opinions about how things should be done. Then one day, you tell a machine about them, and it just... gives you what you wanted. It gets you, it knows what to do. And even if neither of you knows exactly, you quickly figure it out together. This is slowly becoming my reality. My world is turning upside down. // "I think the introduction could also be the start of a review of a sexbot." == An example I'm writing this in a ‘vibe-coded’ text editor slash word processor slash knowledge base of my own design. I had been planning to make it for many years. Then at some point, I needed to quickly ‘waste tokens’ of an LLM subscription that I had forgotten to cancel, so I chose to make a prototype--a custom knowledge base was one of my two main priorities at the time. Well. I didn't expect to be done in a week. Not with the prototype, _with the whole thing._ Does it have issues? Certainly. Just like anything I could have written by hand. They're usually fixed quickly. Do I understand it? Kind of; it followed my design document. But the fact is, _I don't think I need to._ I'll touch upon that later. == Thinking larger Okay, maybe the editor wasn't a particularly representative sample, because I intentionally made it about as simple as it needed to be. Before that project, I had spent several months making the perfect cross-platform image viewer. Everything fought me. Despite building on top of an earlier project of mine and leaving much of the work to the machine, I still waded through all the complexities of modern GUIs, battled integration problems with different systems, and took care of miscellaneous stuff needed for actual shippable software. After an initial stream of intense activity fuelled by seeing the basic shape of my dream materialise so rapidly, I had to push myself to make a presentable release while burning out. I questioned why I even bothered--and whether computers and their consequences haven't been a disaster for humanity. Except for a certain short-sightedness, the machine did fine, bearing the brunt of the work. The bottleneck was me--overwhelmed by what remained for _me_ to do: the overall design and vision, verification on various hardware, documentation, complexity management, funding. I wanted fewer bugs? I asked it to find some. I wanted to clean up? Same story. If I didn't like something in the code, I added a comment right next to it in passing, however vague. It then made sure to consider all of these comments as we iterated. In the same vein, terrible design decisions eventually show up as patterns. Guess what's also good at recognising patterns. (Though I've never tried to automate this at a higher level.) I'm somewhat romanticising here. That's how memory works. At the very least, I'm skipping model shopping and their evolution--this doesn't represent how development went over the whole period. It's roughly where I'm at now. // Anything that cannot push back irks me, as does reading that I'm right. == Outclassed The most astonishing part is how effortlessly LLMs handle things which to humans are at best distractions, and at worst almost physically painful. First and foremost, the debugging and reverse-engineering skills are _surreal_. One day, I got tired enough of an elusive bug where my menu bar icon on macOS sometimes exploded in size. I briefly described the behaviour and hinted at possible triggers. Since the LLM had little source code to work with, it automatically proceeded to _decompile the OS_. Of course, it also triggered the condition and gave me a one-line fix. Or a direct comparison. EIZO firmware updaters embed an obfuscated decryption algorithm, which I spent a few hours trying to reconstruct. Unsuccessfully, despite the binary naming its functions. Then I gave it to an LLM: it went through it like a knife through butter. Perhaps the task is visual. For example, there was a neat screenshot of a certain historical programming environment, of which all I could find was a bunch of different _scans_—slightly skewed, cropped, dirty, and fuzzy. I wished to have the actual source bitmap. So into the magical problem solver they went. Its methods might not have been optimal, but the result was _exact_, and I could spend that time on something else. == Have the problems always been simple? What I've just talked about in the last section is almost mechanical. It requires more tinkering than knowledge. And you can observe the machine being dumb throughout, offsetting it with persistence. But how does it manage to materialise complex code without a reference? Even a small model like Qwen3.8-Flash-Next 125B--the frontier is well over an order of magnitude larger--was happy to write me an AsciiDoc processor in AWK from bits and pieces in its memory. I watched it painstakingly reason the program into existence in an amusing monologue.footnote:[I wrote such a program myself. But the output wasn't my child.] Hypothesis: most software is just rehashed ideas and concepts, composed a bit differently to fit specific environments, and to address specific problems. We keep building largely unoriginal castles in slightly different styles (different programming languages, libraries, operating systems). The parts aren't interchangeable--we can't do any better. But the machine sees past it, remembering even that which we obfuscate. We could see past it as well, if only we could be scaled up in the same way. _Then_ comes the advantage from before: the machine never gets tired. How much real entropy is there in any given program? I wonder.footnote:[I'm reminded of Martin Povišer, who in his youth wanted to ‘algorithmically compress’ programs. It sounded funny to me back then.] == Unbeliever When I first heard ‘I don't even write code anymore’ at my previous job, I couldn't comprehend it. We may have had access to Claude Sonnet, or at best Claude Opus 4.5 at the time. Those models seemed _too dumb_ for that. Not too long after, I found myself in the same place. I suspect two things are at play here, other than the models becoming progressively smarter. First, I lacked deep domain knowledge at the company, and ran into obstacles acquiring it. That made it hard to task a subordinate entity, or to evaluate its work. Second, I let perfectionism get in the way. == What level of understanding do I want? With personal projects, I started out slowly: I finished the Qt code in my TOTP authenticator, generated a macOS port of my music player's UI, added an X11 frontend to my IRC client. I clung to the idea that I needed to understand whatever foreign input I took before letting it into a project that bears my signature. For good reason, perhaps, because it was often very poor, or it had surprising properties. As I've already mentioned, that is changing. A model like Opus 5.5 knows pretty well what we're making together and how, and it can be easily directed in the right way. The embarrassing latent bugs and misbehaviour have become much less frequent. Instead, a new problem appears. When I spent time on understanding the proposed changes, then moulding them into the ‘right shape’, I could still work on the project myself--I had the mental models. If I merely glance over the changes to check that they aren't completely insane, I never gain this knowledge. The bigger the project becomes, the greater the reliance on the machine. (It doesn't help that LLMs like to make multiple copies of all information: in code, comments, tests, and in any documents they can get their tools on. What was cheap for them to synchronise won't be as cheap for you.) There's a choice: do I want the result faster, or do I want to _own_ it? == Symbiosis While working on mostly ‘vibe-coded’ projects, in the back of my mind I keep expecting the whole thing to collapse in on itself: too many issues, with the cost of change skyrocketing beyond sustainability. I find that this never happens, at least not suddenly. What does happen is that I may need to pay back a small portion of the time debt, if I may call it that, and I can continue as before. All slop can be deslopped, understanding regained. The machine lets me move between and focus on different kinds of expertise as needed: breadth vs depth, high-level design vs implementation. And even if I want to be the sole author of the resulting code, I can employ the machine as an independent researcher, as an assistant. It never gets burned out (unless it gets psychotic)—no matter how tiresome the task--and it asks for relatively little, so long as I'm modest. The value of getting me unstuck _alone_ is incalculable. Machine intelligence is becoming cheaper, better, faster. Even if it doesn't fully leave the data centre to become something we can truly own, it is here to stay as a companion. == A new age The economics have changed. What used to be reasonable to buy, _or even just download and reuse_, may now be better generated anew, with a bit of direction. Or distilled and reimagined. Making the computer follow your wishes has never been simpler, in direct contrast to the market's pull towards computing that's standardised and impersonal. Which brings me to another view of the situation. When I look at the past in this field, I see people solving problems in truly original ways. They didn't have as many precedents around, and there was little to build on top of, so they followed their imagination and experimented. Things have settled since then. To put it harshly, true progress has stalled. It's largely because software doesn't live in a vacuum. Developers want to write software that runs on as many systems as feasible, and users want a system that runs the software they need. UI metaphors work the same way. Switching between a Mac and ‘a PC’ is painful enough; even if an objectively better way to operate a computer exists, it will cause friction. Which is not to say that changes don't happen. When most people move to a different kind of computer with different constraints and expectations--as has happened with mobile phones--software tries to converge on a new middle ground. Progress is expensive. Both hardware and the systems have grown complex, as has properly integrating with them. Take user input: you used to expect a physical keyboard and a mouse. Today, you can get a touch screen, a multitouch touchpad, a pressure-sensitive tablet, or voice. Or text: instead of simple bitmap fonts in a few select code pages, there's now the monstrosity of Unicode to handle all possible scripts of the world at once, and the fonts are shape-shifting. The screen can be of low or high pixel density, in different sizes and orientations, with different gamuts, or HDR. And so on. It's no wonder that a universal abstraction like the web browser is winning out, even if it solves just a subset of problems. We've pushed the complexity to barely manageable levels: there can be millions of lines of code behind the façade of a trivial to-do application. Machine intelligence lowers or annihilates the barrier to restructuring the whole stack to fit new paradigms, including transplanting the applications. The concrete gives way to the abstract. Old software gives way to new. // Even if models are trained to overfit to current conventions, we're not designing for aliens. == Open questions I'll get back to the epigraph. It's not just me who has received this ability: to make many more things because we suddenly can. LLM-assisted software is popping up left and right--to such an extent that the landscape is becoming hard to navigate. And we're only beginning. I ultimately hold no particularly strong opinion here. It remains to be seen where this boom will lead. Hardware manufacturers getting caught off guard with a huge spike in demand is a transitory phenomenon helping to hold things back for a while--the real fun is about to begin. And so I'll finish this off with some food for thought. // Originality has intrinsic value. * Who will curate all this software? Of all that ends up published, a smaller part than usual will receive the care and attention people have been giving their creations. Though let's be honest for a moment: it was nowhere near as rosy as people want to paint it. + Does it need to be curated in the first place? The machines can gobble up whatever shows up and at least in theory extract the abstract original parts, then reproduce on demand. (This task will be complicated by them feeding on their own output. Blanket rejection by LLM watermark throws the baby out with the bathwater.) + Further, if something survived for a decade, that probably indicates _some_ level of quality. Similarly, sustained maintenance is a signal. * Will the SaaS model that's currently under heavy pressure fight back, protecting its IP in a particularly restrictive manner? Can that possibly help in the first place? How long will such moats last? Are they going to boil down to hardware renting and providing islands of stability? Or closely guarded data like ML weights? Secret standards between vendors? + What about packaged software? Anything you release becomes a transparent specification--a recipe to recreate the same thing while circumventing copyright. Software patents are mainly a US matter. Obfuscation is a game of whack-a-mole. Adjusting legislation seems late and pointless. * Complexity will naturally rise to even greater levels to match the new ceiling. What are we going to do with the sudden possibilities? Like I said, we shall see. ''' _Ho boy, I don't like writing essays. Let this be a record._ As an interesting sidenote, I have found out that Claude Opus 5.5 remembers my code in great detail, which is something I even support with my licensing. It's now in its weights. For example, it can derive an ASCII art rendition of my MPD client's UI, with high accuracy.