6 Predictions on How Software Will Change

Some time ago I read an article in a computer magazine whose author had put one of the first AI agents to the test — an agent that could take control of a web browser and carry out tasks on its own. One of the tasks could hardly have been more modest: design a simple graphic.

The agent failed completely. Modern web applications like Canva, which most people find their way around in an afternoon, were beyond it.

Eventually, though, it came up with an idea of its own. It wrote a small tool in HTML, JavaScript and CSS, used that to produce the graphic, and was done.

The author concluded that agents were not able to operate software. I read the same article and came to a different conclusion: most software will become obsolete.

Why would we still need Excel, if we can hand our raw data to an agent, ask it what we want to find out or have it build the report we need, and it writes a small Python program, runs it in its sandbox and hands back the result? Seen that way, the agent in the test did not fail at all. It skipped the software.

That thought has stayed with me, and it has grown into a set of predictions about how software will change. Here are six of them.

1. Most of today's software becomes obsolete

Look at what most application software actually is: a tool that helps a person do a job. Excel is an accountant's ledger sheet that calculates itself. Photoshop is a darkroom on a screen; its dodge and burn tools are still named after the techniques photographers used to lighten and darken parts of a print by hand. Word is a typewriter with an undo button. Each of them made people dramatically faster at a craft. None of them took the craft away. A person still had to know which formula, which filter, which layout.

An agent does not make you faster at the craft. It does the job. Theodore Levitt (again!) is usually credited with the famous marketing line that people do not want a quarter-inch drill; they want a quarter-inch hole. For forty years, software has sold us drills. Nobody ever wanted Excel. They wanted the number at the bottom of the column.

“Nobody ever wanted Excel. They wanted the number at the bottom of the column.”
Jörg Bröker

The same goes for pictures. Why use Photoshop, if I can describe the image I want, look at what comes back and ask for changes, without ever clicking on the magic wand? The tool in the middle, the one that only existed because a human needed something to work with, is the part that disappears.

Not every piece of software goes, and I will come back to what stays at the end. But the vast layer of tools between people and the results they want — most of what we open on an ordinary working day — has a much shorter future than most people assume.

2. Custom software becomes the norm

Software development is where agents already deliver the clearest productivity gains. Follow that to its conclusion: when building software becomes dramatically cheaper and faster, the old trade-off between standard and custom software turns around.

For decades, the rational choice for most companies was to buy standard software and bend their processes to fit it. Anyone who has worked on ERP projects knows the advice by heart: stay close to the standard, because every modification is expensive to build and even more expensive to carry through every upgrade. So companies lived with processes that did not quite fit them, because software that did fit them was out of reach.

That calculation is changing. When a new function costs days rather than months, companies will stop adapting themselves to their software and start getting software that is adapted to them. Custom software, for most of its history a luxury, becomes the normal case.

Once agents can write the code, though, the hard part is no longer the code. It is knowing what to write.

Take a company that wants a new function in its ERP system: an additional approval step, say, or a report nobody has built yet. Today that request travels through a chain of people. The department explains it to a consultant, the consultant writes a specification, a developer interprets the specification, and at every handover a little of the original intent gets lost. Most people in software have seen the old cartoon: a customer asks for a swing, every stage of the project gets it wrong in its own way, and the final panel shows what the customer actually needed — a tire hanging from a branch.

With agents, that chain shrinks to a conversation. The people who want the function describe it, and an agent works through it with them: asking the questions a good consultant would ask, raising the cases nobody thought of, showing a working prototype the same day instead of a document weeks later. Idea and specification evolve together until the specification is precise enough for a programming agent to build from. What comes out at the end is what the department needed, not what survived the translation.

Writing code is becoming the easy part. Describing what the code should do, precisely enough for a machine and correctly enough for the business, is the next problem to solve.

3. Users become managers

Most of what you see in a business application is an accommodation for human limits. A chart turns ten thousand numbers into one line, because a person can spot a trend but cannot read ten thousand numbers. A wizard spreads a process over five screens, because a person makes one decision at a time. A table shows twenty rows per page, because nobody can take in the whole list at once.

An agent does not share these limits, and the accommodations do nothing for it. It can read all ten thousand numbers, it needs no process cut into steps and no list cut into pages, and it does not need anyone to decide in advance which figures it gets to see. For the agent in the magazine test, Canva's carefully designed editor, with its handles to drag, menus to open and icons to recognize, was not an aid but an obstacle course.

What remains for people is the job of a manager. They hand out tasks, get reports back on the results, question them, send the work back for another round and decide what happens next. A new job needs a new interface, and it looks nothing like a cockpit full of instruments. It looks like the exchange between a manager and their staff: a task goes out, a report comes back, a question goes out, a better report comes back.

And it has to work wherever you are. Agents do not keep office hours; they report back when the work is done, not when you happen to be at your desk. If your feedback has to wait until you are back in the office, so does the next round. An interface for managing agents has to work on a phone just as well as at a desk.

4. Good ideas become the scarce resource

Until now, the distance between an idea and a product was measured in money and time. You needed a team, the capital to pay for it, and a year or two before anyone could use what you had imagined. Even the best idea in the world was hard to turn into reality, and most good ideas never made it — not because they were bad, but because the people who had them could not afford to build them. What got built depended as much on access to developers and capital as on whose idea was best.

With agents, that hurdle is disappearing. If I have an idea that is significantly better than what exists, I can now bring it to life, sometimes on my own and in a fraction of the time it used to take.

We have seen this happen before. As long as publishing a video meant owning a transmitter, what reached an audience was decided by whoever ran the broadcasters. When YouTube made publishing essentially free, it was decided by who had something worth watching, and plenty of people who would never have been let near a television studio turned out to have exactly that.

The flip side matters just as much. If building is cheap for you, it is cheap for everyone. A slightly better idea no longer buys you much, because a competitor can build it too, and quickly. A genuinely better one is worth more than ever. This, in the end, is what makes the one-person unicorn I wrote about earlier more than a slogan. It is not that one person can do the work of a hundred. It is that one person with a significantly better idea no longer needs a hundred people to find out whether it works.

5. Poor software stops being accepted

The same economics apply to everything that decides whether software is actually good: testing, review, documentation. It is unglamorous work, and it has always been the first to go when a deadline got close or a budget ran short. Every developer knows the tests that were never written, the edge cases nobody had time for, the documentation that still describes the previous version. None of that was ignorance. It was cost.

Agents change the cost, and what the textbooks have always recommended becomes the normal way of working: unit, integration and end-to-end tests for every feature and workflow, a regression test for every fixed bug, load and security tests, and a code review for every change, all of it running automatically. Agents do not get bored, and they do not push testing into the next sprint. When best practice comes at almost no cost, there is no reason left to skip any of it. It also removes one of the oldest arguments against custom software: a modification that is thoroughly tested can be carried through the next upgrade without anyone holding their breath.

So quality goes up, and expectations go up with it. Business users have spent decades learning to live with software that loses their input, needs a workaround for things that should simply work, and ships with a list of known issues longer than its release notes. They accepted it because there was no alternative. Once there is one, poor software will no longer be accepted, and the vendors who cannot keep up will hear it from their customers first.

6. Open source pulls ahead

Agents are at their best with text. A configuration file, a command line, an API: they can read it, change it or write it from scratch. In open source, nearly everything is text — the configuration, the commands, the documentation, countless discussions of every problem anyone ever had, and the source code itself. An agent setting up a Linux file server or a Docker container is working in its native language.

Much proprietary software keeps its settings behind admin screens and its inner workings behind a license. The agent has to guess what happens inside, and when something goes wrong, it waits for the vendor like everyone else. With open source, it can read the code when the documentation runs out and change it when the code does not do what is needed. That often makes a mature open-source project a better starting point for custom software than a blank page.

None of this will end proprietary software. But whether an agent can run something without a screen will increasingly decide which software gets chosen, and open source has a head start.

The software that stays

What becomes obsolete is software built to put a tool in a human hand. What stays is the software underneath, the part that actually does the work, and agents have good reasons to use it rather than rebuild it.

Start with the base technologies. Web servers like nginx, databases like PostgreSQL, Linux, the browser, the programming languages themselves: they work, they have been tested by years of heavy use, and agents know them inside out. There is no reason to reinvent any of them.

Then there is the tricky software. Nobody sensible will ask an agent to rewrite a billing system that has been sending out correct invoices for years, or payroll, or the general ledger. Systems like these carry a long history of corrected mistakes, special cases and legal requirements, much of it written down nowhere except in the code itself. Even if the risk of replacing them is small, it is unnecessary.

And services stay, even where their apps do not. When my agent books me a ride, it has no use for the Uber app — the map, the buttons, the little car crawling across the screen. But it still needs Uber: the drivers, the dispatch, the payment. So it books the ride directly through Uber's backend. The same goes for shipping a parcel, checking a customer's credit or paying a supplier. The screen in front of the service disappears. The service does not.

In every one of these cases the logic is the same. Cheap development is a reason to build what is missing, not to rebuild what works.

“Cheap development is a reason to build what is missing, not to rebuild what works.”
Jörg Bröker

The software that is missing

So what is missing? Put the predictions side by side and an outline appears, and it looks surprisingly familiar. It is how companies have always worked: one person delegates the work and reviews the result, another does it, and the tools are built for the one doing it. Only the cast has changed. People delegate and review, agents do the work, and the software has to be built for the ones doing it.

Much of what is sold as agentic software today starts from the other end. It takes software built for people and either bolts a chat window onto it, leaving a human to do the clicking, or lets an agent do the clicking itself, on screens designed for someone with a mouse.

That is the magazine test all over again: the very thing the author concluded agents were not ready for, and in my view never will be. Nor should they have to be. An agent working its way through screens will always be slower and more fragile than one that goes straight to the systems behind them.

Which is why I read that test the other way round. It was never a test of whether agents are ready for our software. It was a test of whether our software is ready for agents, and most of it is not.

We founded Last Loop to build the software that is.