The future of software

In times like these there is no shortage of predictions about where the world of software is heading to. The end of SAAS. The end of software developers, everybody will be writing software and there will Software Factories, spec goes in, working software pops out.

Plus ça change, plus c'est la même chose

Without a doubt, a lot is going to change in software development, but, as they say "Plus ça change, plus c'est la même chose". Here is our two cents for where we think software development is going.

The past

If you have spent a long time in an industry where software development plays an important role, you have probably looked at coding agents like a cartoon character would: chin on the ground and eyes popping out in front of your face.

And then maybe you slap yourself on the front for having wasted so much time chasing bugs, doing code-marathons against deadlines, abandonning projects going nowhere etc.

As software started eating the world, learning serious software development methodologies became all important. But writing good software remained difficult, humans make lots of errors in the code they write, trivial and sophisticated alike. Uncountable tools have been developed to make this more manageable, and teams have used proven software as much as possible: libraries, frameworks and the like.

To build something, you need a good design.

But whatever methodology selected, the single most important thing always was that, to build a good system, you needed a good design.

The future

What has happened to software writing with the arrival of AI to is incredible, irreversible and absolutely fantastic. Developing software with AI is awesome. Not the part where you are waiting for the agents to finish while scrolling on your phone, but the part where you can finally boost your ambition again about what you are going to build. And a lot of software is going to be build, almost all of it with the aid of AI and to a large part designed to be used by AI agents.

More software, faster, with less errors and at a much lower cost.

It will become possible to design really big systems much faster, better and at a lower cost point then before. Many situations or processes for which it was hard to justify a targeted software development, will be reconsidered.

But we will have to change how the software is developed - we will have to get a grip on burning manpower and burning tokens. We will we need tools that help us to guarantee functionality, quality and safety of what we build. Real software development companies will not be in the business of selling tokens, but making sure that the tokens contribute to a working, maintainable system.

Is SAAS dead ?

Not necessarily: software that offers useful functionality to its users at a reasonable price will stay. Even if I can, why would I write my own version of whatever package if I can get a subscription for it at a reasonable price.

No more developers ?

Understanding software architecture remains very important. No Code of Low Code tools will grab a part of the market, but mainly at the low end for relatively simple apps. Traditional sw companies will embrace AI to increase productivity, but will not disappear.

Truism: software is a more then writing code

Building systems is a process, where you have to understand the domain for which you are building and try out different architectures for what you want to build, think about use-cases and the like. These are things devlopers are already accustomed to in their work today. Further downstream you have to be able to reason about testability, security, corner cases, behaviour under stress etc. All of which you do not want to have hidden somewhere in opaque software, but explicitely visible as deliberate choices.

Data shows a serious decline in entry-level job postings since 2022. If AI handles all the "easy" junior tasks (tests, boilerplate, simple bugs), the industry is struggling to figure out how to train the next generation of Senior Architects. However we also see the pendulum swinging back already as companies realize that the relation between productivity and AI is more complicated. People will be more productive with AI, not the AI by itself.

Domain knowledge and data

If you have data and domain knowledge you will be able to build on that by using AI and offer new services based on that: examples of this are medical records, legal data, hotel occupation data etc.

If you have the data, it pays to build the system.

This where we see a lot of the new AI companies. What also has changed is that where previously it could not be justified to build a possibly expensive system, this has changed completely.

Natural language interface

New software that faces an end user will have to have a natural language interface at least for the complicated interactions (often it is still easier done by a simple click). A lot of new software will no longer be end-user facing, but developed for agent interaction.

Goodbye to the traditional UI

We will no longer see UIs with endless menu cascades and popups. UI development will change drastically: simpler, more intuitive, a combination of clicks and natural language. A UI will also span several applications, so you do not have to switch between apps.

The Maintenance Debt Explosion

Customers will not longer accept / order huge projects that typically have budget overruns and delayed delivery milestones. Customers will still outsource but expect dramatically lower prices and better quality. This does not happen miraculously by spending enormous token budgets, but by clever design.

How to maintain AI generated code

AI allows us to generate code 10x faster, but it doesn't necessarily make it 10x easier to maintain. Companies are waking up to "AI Legacy Code"—mountains of generated software that no single human fully understands. Observability and Automated Refactoring are becoming the most critical parts of the stack.

Security

Security becomes more complicated. Letting an AI write the code can introduce unacceptable vulnerabilities in the code that need to be identified and eliminated. Opening up applications to AI agents makes the application vulnerable to prompt injection at scale or, intentional or unintentional, rogue behaviour by the agent. Companies must now acquire skills in "Agentic Guardrails" to ensure one agent doesn't trick another into leaking data or emptying a corporate wallet.

The present

Reality check

Coding agents are fantastic and will get better, but no matter how good they get, the developer needs to understand the code, the features, the quality and the security of it. Coding agents are no mechanistic compilers, so you cannot just assume that everything will be ok, but proofreading the entire codebase is no guarantee that something wrong, dangereous or harmfull will not have escaped your attention. And your attention will quickly get bored in the process as well.

Agents have strenghts and weaknesses

A second point that people have become aware of, is that coding agents are strong at certain points an weaker at others. Chasing and solving bugs is definitely an area where they have proven to be very efficient. But the design phase of a project is a much harder nut to crack for most agents and in our experience often results in elaborate bs whereby the agent gets lost in intricate details so that it sometimes takes a while before you realize he hasn't got a clue what the big picture is.

Also as systems become large, an agent has to keep a lot of context alive. This becomes inefficient and expensive as many dev labs have experienced.

Designing is hard

Designing is a high level function. As you start you only have sketchy ideas and then you make these more and more explicit. In the process you will often backtrack and change major aspects of the system. Another feature of systems design is that the design of a system with the same specs, done by two people will often be very different as there are a many degrees of freedom in a design even if you are guided by 'best practices'.

You need to understand the problem domain and the solution space

When you make a design you are faced with two challenges: do I understand the problem domain and do I understand the solution space. Only if you have a good understanding of both you can come up with designs that are relevant and performant.

We need new tools

It should be clear by now that we need to be able to communicate as clearly as possible what we want from a coding agent. And not just prompts, that can drift and get out of date, but a formal blueprint that is the actual representation of the artefact. A tool that I can use to easily find my way in the code to understand it. Where I can see what the subsystems are and how they interconnect.

The agent and the developer need a blueprint

The AI coding agent also needs that blueprint, so that writing the code for a big system can be divided in manageable pieces backed by an architectural reference to keep the big picture visible.

On top of that I want to be able to catch any security breaches from the code written by the coding agents in real time, so that no data leaves the system to unathorised destinations and the like. And if my software has an runtime interface to a user-agent, I want to be able to precisely control what it is allowed to do with the system.

You probably understood already: vmblu is that tool.

Conclusion

Writing software will never be the same again. And it would be wrong to try to slap old habits or old way-of-workings to the new challenges writing software is facing.

A lot has changed at the same time: natural language interfaces, coding agents, agentic software. But the fundamentals remain: you do need to understand and control what is being build and you do need a good design to build it. In that respect, "Plus ça change, plus c'est la même chose".