When is software actually good?

Software is, at first, just consistent rule-following

That sounds more banal than it is.

Classic software does what we taught it. When a user clicks a button, something happens. When an invoice is approved, the next step starts. When a field is empty, there is an error message. When an order comes in, it is saved, checked, processed and at some point delivered.

There is nothing wrong with that. Quite the opposite. A great deal of good software works exactly like this.

The problem usually doesn’t start with the basic idea, but where reality gets messier than the model. People don’t stick to ideal processes. Data comes from different systems. A special case suddenly turns out not to be a special case after all. And it is in places like these that you see whether an application only works on paper or holds up in reality.

What we mean by software intelligence

We don’t use the term to make software sound artificially bigger than it is.

Nor does it automatically mean AI. Software doesn’t become intelligent just because a chat window appears somewhere or a model is allowed to write a text.

For us, software intelligence begins where a system can do more than blindly manage inputs and work through rules. Good software understands the business context in which it is used. It connects information that was previously separate. It takes unnecessary intermediate steps off people’s hands. It makes processes more stable. And it doesn’t immediately behave as if the person must have made the mistake just because reality doesn’t fit the original requirements specification.

In the end this is often less spectacular than many debates about AI, but in companies it is usually much more useful.

A good system notices, for example, which information is needed in the next step and brings it together in time. It doesn’t force anyone to enter the same data in three forms. It integrates into existing processes without simply cementing their weaknesses digitally. And it stays understandable even when someone has to change it years later.

That is exactly what we mean by software intelligence: not magic, but well-thought-out software.

Where AI fits in and where it doesn’t

Of course AI plays a role in this now.

There are tasks where language, image recognition, semantic search or agentic workflows really help. And it would be silly to pretend this has nothing to do with modern software architecture.

But the two should be kept cleanly apart.

AI can be part of good software. It does not, however, replace a system’s actual software intelligence. A badly built process doesn’t become good by putting a language model on top. And an application that doesn’t have its data, permissions and responsibilities under control won’t suddenly become sensible with AI, either.

That is precisely why, with modern software, we very deliberately care about the metadata of processes. That is, the information behind the actual information: who may do what? What status is a case in? What does a certain value mean in business terms? What dependencies are there? What is only a draft right now and what is already a decision?

That sounds dry at first. But it is quite decisive. Because if AI in a company is to do more than word things nicely, if it is to support or prepare things in a really useful way, it needs exactly this structure. Otherwise it has data but no reliable context. And loose data rarely leads to good decisions.

You could also put it like this: AI can add capabilities. But the quality of software is still decided by architecture, data flow, metadata, understandability, maintainability and whether the system can be sensibly used in a real organisation at all.

How to recognise good software

Perhaps not by how loudly it announces itself.

Good software often stands out because less goes wrong. Because there are fewer queries. Because fewer workarounds appear. Because a process becomes clearer, not just more digital. Because people get ahead faster without having to adapt to the system more than the system adapts to them.

And internally you recognise it because it doesn’t only work today but can still be built on tomorrow. Without an archaeological dig in the code. Without collective fear of every small change. Without the quiet knowledge in the team that you’d better never touch that one area again.

For us, software intelligence is therefore not a product label of its own. It is more of a yardstick. A good question for every project: are we just building software that somehow runs? Or are we building a system that understands the context, copes with reality and will still have been a sensible idea later?