By Tapio Äijälä, Chief Strategy Officer, Oivan

I’m increasingly interested in this question:

As AI helps us write more software, are we also getting better at preserving the understanding behind it?

Why was something built a certain way? What led to a particular architecture or design choice? Which lessons did the team learn the hard way?

In large enterprise applications, people come and go. Systems stay.

That’s why something Solita’s Tuomas Tuunainen wrote in his recent blog post resonated with me: “Build the memory, rent the intelligence.” It feels particularly relevant to developing software that keeps evolving for five, ten or fifteen years.

Saudi Arabia is a good example. More than 15 years ago, it was already putting service-oriented architecture into practice at a national scale, connecting government agencies through its Government Service Bus and enabling them to share data and services.

In my view, that shared foundation helped enable the rapid digital transformation in the KSA we’ve seen since. But connecting services also creates dependencies that teams need to understand and maintain for years.

A single GovTech platform can depend on tens of integrations: Identity, government records, payments and more. Each connection comes with rules, exceptions and a history of things that didn’t work as expected. Some have changed several times as legislation, policies and the connected services evolved.

The code tells you what happens. It rarely tells you the whole story of why.

Why does this transaction need an extra check? Why do we handle one agency’s response differently? What happened the last time someone tried to simplify that workflow?

Working with long-running platforms at Oivan, you realise how much of that understanding sits with particular people. Over a decade, developers, architects, client teams and vendors change. The service still needs to work every morning, and the next team needs to keep improving it.

For me, this means capturing the reasoning as we work. Link decisions to code changes. Keep integration documentation and operational lessons current. Turn important exceptions into tests. Record what we learned from users alongside the design decisions it informed.

That gives future teams, and the AI agents working alongside them, knowledge they can find, use and question. They also need a way to trace an answer back to evidence and see whether it still applies. An old decision without its date or context can be as misleading as no explanation at all.

Human judgment still matters. Yesterday’s sensible choice may need revisiting today. You need a way to trace an answer back to evidence.

I’d like us to get better at leaving the next team both working software and enough understanding to keep moving it forward.

Inspired by Solita’s blog post: https://www.solita.fi/blogs/company-brain-build-the-memory-rent-the-intelligence/