Mikkel Freltoft Krogsholm
Menu

A mind, not a brand.

AI · mennesker · fremtidKøbenhavn · Danmark
Essay
10 min read

The Engine Changes While We Drive

The AI engine is changing faster than organisations can rebuild. Stability must therefore lie in direction, memory and replaceable parts.

Mikkel Krogsholm betragter et køretøj, der får skiftet motor, mens det stadig bevæger sig.

Many years ago, I visited the car museum in Stuttgart. I especially remember the part of the exhibition that traced the development of the car from the first experiments with an internal combustion engine to the vehicles we know today.

One of the early vehicles did not really look like a car. It looked like a horse-drawn carriage that had lost the horse and gained an engine instead. That was the world the inventors knew. If something was to carry people along a road, it had tall wheels, a carriage body and seats like those of a horse-drawn carriage. The engine was new. The idea of the vehicle was old.

It is easy to smile at it today. We can see everything that had yet to be invented: the shape of the car, the steering wheel, the dashboard and the entire infrastructure around it. But the first people with an engine could not leap directly to the modern car. They had to put the engine into something they already understood, drive it and discover what had now become possible.

I often think about that carriage when I look at how we use AI.

We put a language model into the email client. We give it access to customer service and let it suggest a reply within the workflow the employee already follows. We place an agent in an old organisational chart and give it a job description resembling that of its human colleague. We have acquired a new engine, but much of what we build around it still resembles the horse-drawn carriage.

That is not necessarily foolish. A large field study among customer service agents found that a generative AI assistant increased productivity by around 14 per cent, particularly among less experienced employees. There can be real value in simply putting the engine into the existing carriage. It is also where we learn what it can do, where it fails and which parts of the work we have taken for granted until now.

The later form of the car was not conceived all at once either. It emerged through the interplay of speed, roads, materials, regulation, accidents, petrol stations and needs that only became visible once people began to drive. The new became understandable through the old before it could take on a form of its own.

There is just one difference between the first car and the AI we are working with now. The engine in our carriage keeps changing while we are driving.

An organisation cannot reinvent itself every three months

New AI models do not merely get slightly better along a calm and predictable curve. They acquire new capabilities, become cheaper for some tasks and can suddenly work for longer without assistance. METR has tried to measure this development by looking at the length of bounded software, machine-learning and cybersecurity tasks that the best models can solve. Historically, the models’ time horizon in that measurement has roughly doubled every seven months.

This does not mean that entire jobs can be automated every seven months. METR’s tasks are cleaner and easier to verify than much of the work found in a real organisation. But the measurement says something about the pace. What was a reasonable design decision at the beginning of an AI project can become a constraint before the project has even been rolled out.

The obvious response is to think radically. Break down the work. Forget the old process. Rebuild the company around the intelligence that has now become cheap and available.

It is a useful exercise, but it cannot be repeated from scratch whenever a new model is released. If the organisation must be torn down and rebuilt around each new engine, it will do little else. Nor can it wait for the technology to settle down. Stability may be many years away, and perhaps it will never arrive in the form we are used to.

So the question is not only what we can build with the best model right now. It is how we build something capable of surviving the fact that the best model keeps changing.

The living answer

Biology has been working with a related challenge for far longer than we have.

A living organism does not stand still. It repairs damage, replaces parts, responds to its surroundings and learns through its immune system. Yet we do not wake up as a new person whenever the body has replaced some cells. Identity does not depend on every component remaining unchanged. It lies in the patterns, relationships and processes that hold the whole together over time.

Biologists who study robustness point, among other things, to modularity, redundancy and different responses to the same disturbance. If one pathway through the system fails, another can sometimes take over. If the surroundings change, the organism can adapt its behaviour without having to reinvent itself from scratch.

Biology is not a fairy tale in which all adversity makes us stronger. An organism can be overwhelmed, become ill or die. Robustness applies only within certain limits, and it always has a cost. But life shows that stability does not have to mean unchanging parts. Something can preserve its identity precisely because it is able to change.

Nassim Nicholas Taleb calls the stronger form of this quality antifragility. Something robust withstands the disturbance and remains more or less the same. Something antifragile, within a certain range, benefits from variation. A muscle is the simple image: after an appropriate load, it does not merely remain a muscle. It adapts and can carry more afterwards.

An organisation does not become antifragile merely because it lives in chaos. If each new model creates stress, lost work and yet another management presentation about transformation, change has not become a strength. It has merely become a recurring bill.

The change has to leave something behind that the organisation can use next time.

When a model fails, the failure can become a test. When an experiment succeeds, the workflow can be documented. When a supplier is replaced, the experience can remain in the company’s own data, quality criteria and evaluation sets. Each technological leap then begins to make it a little cheaper and safer to absorb the next one.

What microservices taught us

The software world already has a practical language for parts of this idea.

Large IT systems were long built as monoliths. Many functions lived in the same application and were tangled together. That could be efficient as long as the system was manageable and the world around it stable. But a small change in one place could require the entire system to be tested and released again.

Microservices emerged as an attempt to divide the system into smaller parts with clear boundaries. Martin Fowler and James Lewis describe them as services built around a business capability that can be deployed independently. The point is not that small services are always better. The point is that one part can actually be replaced or upgraded without requiring the rest to be rebuilt at the same time.

A related pattern is called a circuit breaker. If a service begins to fail, calls to it are interrupted before the failure can spread throughout the system. The system is given time to recover, and the other parts can continue. It is the software equivalent of a fuse in a house: a fault needs a boundary.

Translated into an AI organisation, this means that the model must not become the place where the company’s entire memory, logic and quality reside.

Imagine a company that uses AI to handle customer enquiries. The slow core might be the company’s responsibility towards the customer, its product knowledge, the rules for when a person must take over, and the test examples showing what a good answer looks like. The model itself, the prompt and the connection to the supplier can be the fast part.

When a better model arrives, the company should be able to run the same test enquiries through it, compare the answers and move a small share of the traffic across. If quality falls, it should be able to roll back. If the model reveals a new capability, the company should be able to test it in a bounded area without turning every customer into a test subject.

It sounds technical, but the organisational idea is simple: make the change local, make the consequence visible and retain the option to go back.

It is possible to have fifty services and still end up with a distributed monolith in which no part can change without affecting all the others. The same thing can happen with AI agents. A large diagram of specialised agents may look modern, but if they share hidden assumptions, opaque memory and the peculiarities of one particular model, the organisation is still coupled in a fragile way.

Modularity cannot be measured by the number of boxes. It only reveals itself on the day you try to replace one of them.

The slow core

It is tempting to make everything fluid when technology moves quickly. But some things become more valuable by standing still.

The organisation’s purpose should not change with the model version. Responsibility for a decision cannot be passed to whichever supplier happens to provide the intelligence this month. Customers and employees need to know which promises apply. Data, test history and experience must be able to outlive the model that helped create them.

The slow layer is therefore the purpose, responsibility, relationships, memory and criteria for good work. The fast layer is the models, prompts, integrations and the specific ways in which the task is distributed.

If the two layers become mixed together, every model leap becomes an identity crisis. If they are properly separated, the new engine can be connected without the company forgetting who it is or whom it serves.

There is also a human boundary here. A company is not antifragile if its owners reap the benefits of rapid change while employees carry the uncertainty, constant restructuring and mistakes in front of customers. Then the fragility has merely been moved out of the spreadsheet and into people.

Bounded experiments, clear stopping rules and the ability to roll back are not caution in opposition to innovation. They are what make it possible to experiment again tomorrow.

Economists have described a productivity J-curve around general-purpose technologies such as AI. Before the gains become visible, companies have to invest in new processes, products, business models and human knowledge. At first, this work can make productivity look disappointing because the organisation is building something the accounts cannot yet see properly.

The horse-drawn carriage phase is therefore not merely an embarrassing interim stage. It can be the place where we gather the experience that later makes the car possible. But only if that experience is preserved. Otherwise, we simply install a new engine in the same carriage every six months and call it another transformation.

While we are still on the road

At the museum, I could see the development as a completed sequence. The carriage stood at the beginning. The modern car stood later. The distance between them looked almost logical because other people had already taken all the strange intermediate steps.

That is not how technological change feels when you are in the middle of it. We do not know what AI’s car will look like. We do not even know whether the organisation will remain the right vehicle, or whether near-free intelligence will create forms for which we still lack words.

We cannot therefore draw the final construction. We can do something else. We can build clear connections between the parts, ensure that failures do not topple the whole, and let every experiment make us wiser about the next one. We can hold on to purpose and responsibility while allowing the tools around them to change.

The AI organisation of the future should not be built around the best model. It should be built so that it becomes better every time the best model changes.

The engine changes while we drive. The engine itself can no longer be the stable element. Stability must lie in our ability to replace it without losing our direction, our memory or the people along the way.

Sources and further reading