There are two ways to build software with AI

A while ago one of us sat in on a lecture at RWTH Aachen. It was about how AI is currently reshaping software development, and at some point it got to the part where we recognised ourselves.

The speaker put two ways of working side by side, two ways software gets built today. Both of them work. They are simply made for very different things. The more demanding of the two has even picked up a name by now: agentic engineering.

For us that was less a piece of news than a confirmation. We have been working like this for quite a while. We just did not have a word for it.

Two ways, and neither one is the bad one

The first way is open to everybody now. You tell the AI what to build, you look at whether it runs, and you take what comes out. No programming required. For experiments, for demos and for everything you are going to throw away anyway, this is a fine thing, and we work that way ourselves when we want to find out quickly whether an idea is worth anything at all.

The second way starts one step earlier. The point is not that something runs, but that you can depend on it. The AI does not get shouted instructions, it gets specifications. What it produces is checked rather than believed. And there is a fixed process nobody steps out of, not even when things are in a hurry.

That is the way for software a business actually works with. For data that is nobody else's business. For customers who pay for it.

Where exactly the line between the two runs is usually something you notice afterwards. It runs at the point where somebody first starts depending on it.

We wrote down what we know

The AI we work with is available to anyone on a subscription. So it is not the thing that sets us apart. What sets us apart is what it gets from us.

Twenty five years in this profession leave you with a lot of knowledge that is written down nowhere. Which shortcut comes back to bite you. Where you never trust an input, on principle. How to build something so that you can still touch it in three years without breaking something else next to it. That used to live in our heads, and it got passed on whenever the occasion happened to come up.

Today it is written down. A set of rules that sits in the project, and the AI reads it at every step. It is not allowed to deviate from it.

It never gets smaller. Whatever we learn goes in, and from the next day on it is in everything we build. A person could not keep all of it in mind at once. The machine forgets none of it.

Nothing here happens just because

Before a single line of code exists, there is a plan. Every task gets described, gets a fixed number and a place on a list that always says what is open and what is done. That sounds like admin. It is the reason nothing gets left lying around here, and the reason nobody has to guess where a project currently stands.

The building then happens in small steps, and after each one an automated check runs. If it finds something, nothing moves on, however harmless the thing looks. On top of that comes our own reading of it, because some things no check will catch, only somebody who has run into that kind of mistake before.

The last step always belongs to a person. The machine proposes, we approve. That is not a formality. It is the reason somebody can stand behind the result at the end. A machine cannot do that.

Why we document so much

For every step we record why it was done that way. Not just what was built, but what we discarded and why, and when it would make sense to do it differently later on.

That sounds like paperwork, and to be honest we would have thought so ourselves once. By now it is our most valuable tool, for two reasons.

The first has to do with the AI. It reads those records along with everything else. So it does not start from nothing on every task; it knows the backstory, what has already been tried here, why something looks the way it looks, where the traps are. The better we document, the better the work that comes out of it. Documentation is not an appendix to the work here. It is the memory.

The second reason belongs to you. Those records make you independent of us. What you end up with is not just a piece of software, but one somebody else could carry on with. Software only its builder understands is not an asset, it is a dependency. We would rather you stayed because you want to.

What you get out of it

From the outside you cannot tell which way a piece of software was built. On day one they look the same. That is the annoying part.

The difference shows up later. When the data grows and everything suddenly turns sluggish. When somebody enters something nobody planned for. When numbers appear on a screen that not everyone should be seeing. Or when you want to change one small thing two years on and nobody remembers why the thing is built the way it is built.

Care at the start costs time, no secret there. What it saves is the crises afterwards. After twenty five years in this profession we can say the trade is almost always worth it.

And if you are currently putting something together with AI yourself, to work out what you actually need, then carry on. You will be able to say what you want far more precisely afterwards, and that is worth more than any concept document. If it turns into something your business depends on, get in touch.