The First Adaptive Software Was a Virus

In 1975, a novelist named John Brunner published a book called The Shockwave Rider. The internet didn’t exist yet. The first personal computer had gone on sale the year before: a kit you soldered together yourself.

And yet, Brunner described in precise detail a program that could propagate across a network, survive in new environments, and resist being deleted. He called it a worm. Something that moved through systems the way a parasite moves through a host.

Brunner’s fictional program had a fixed purpose and a mutable form. The earliest imaginable definition of adaptive software.

Computer scientist Alan Kay brought Brunner’s vision to reality. Working at Xerox PARC in the early 1970s, where the politics were liberal and the hair was long, he designed Smalltalk. The unique thing about Smalltalk is offensively simple: the program never stops running. Typically, changing software meant stopping everything. Edit the code, recompile, restart the program, check if it worked, repeat. Kay eliminated that cycle entirely. You picked a running piece of code, changed it, and saw the effect immediately. Software in a constant state of becoming.

Researchers used Smalltalk to prototype the modern desktop with primitives like windows, icons, and the point and click interface that Apple would later take to market and sell back to the world at a considerable markup.

Kay had made software fluid for the people building it. What nobody had yet figured out, let alone articulate, was how to make it adapt autonomously. The program could only change when someone changed it. It needed a human to get the ball rolling.

Then, in 1991, a Bulgarian programmer known only as Dark Avenger shipped a piece of software called Mutation Engine, or MtE for short. This wasn’t a benevolent contribution to computer science. It was a tool that any virus writer could attach to their own creation to evade antivirus detection. Within a year, Norton had logged roughly 900,000 distinct variants of MtE-based viruses in the wild.

MtE was different from every virus toolkit before it because of what happened at the moment of replication. Each new copy encrypted itself with a different key and generated a completely new decryption routine. different structure, different signature, nothing stable to recognize. But strip away the encryption and the behavior underneath was always identical. The virus still did exactly what it was designed to do.

MtE ran circles around the antivirus software of the time. Those tools worked by recognizing signatures: specific sequences of bytes extracted from known viruses and stored in a database. It worked fine against viruses that stayed the same. MtE never stayed the same. The only constant was its purpose, not its form.

This was, functionally, the first working example of adaptive software. From sci-fi, through a legendary work of science, to a Bulgarian scam, it finally existed.

Viruses got there first because they faced genuine selection pressure, something that legitimate software almost never experiences. Antivirus tools inadvertently created an environment hostile to fixed viruses so only the viruses that adapted survived.

SaaS has never faced an equivalent pressure, until now. The vendor built and shipped a one-size-fits-all version of the software, and if the software didn’t quite fit, there was no real alternative. Building something custom was expensive and reserved as a service for high paying customers. But now, that’s changing, and software that doesn’t adapt to its users is increasingly easy to replace with something that does.

Large language models are both the cause and the cure. They made it cheap enough to build AI-native alternatives which is what’s killing SaaS. But they are also able to close the gap between what someone wants and what gets built.

Most companies are using AI to accelerate engineers, but it’s the wrong place to close the gap, because the drift starts the moment you ship. What you’ve built and what users need begin to diverge immediately, and keep diverging until someone schedules a sprint to close it. Software shipped as a single version is the best version for no one.

Existing tools can make software somewhat adaptive, but only get you partway there. Feature flags let you pick between states someone designed in advance, but they can’t generate a new one. A/B testing tells you which of two things users prefer, not what they actually wanted. Netflix can observe behavior and adjust what content surfaces to each user, but the UI and the backend are still fixed.

Closing that loop requires new infrastructure, with a way for an application to represent its own intent, understand user intent and the ability to serve them both without breaking things. These are not easy problems to solve. Most of what’s being called autonomous software engineering today is still build-time automation using agents that can write a pull request, not agents that can modify a running system in response to what users are actually doing.

For the first time since people have been describing this idea, the pressure and the means are finally converging. The environment is finally hostile enough to demand adaptation and we finally have the technology to make it possible. For the first time, the gap between intent and implementation can be closed not just at the moment the software is created, but continuously as the software runs.