From Software as Object to the Engine as Centre |
For years we built software the way you build a building. First the walls, then the rooms, then the corridors that tell people where to walk. The application sat at the centre, and intelligence — when it was present at all — lived in the fixed logic of the product itself: not in something that could be corrected or deepened over time, but in paths the designer had drawn before anyone arrived. Whether that made sense or was simply the only thing available — and those are not the same — was not a distinction you could easily see from inside it. Now something has broken open. I cannot say it precisely without either exaggerating the rupture or diminishing it. I include myself among those who still have not fully registered it. Knowing that a framework has changed and actually having the replacement framework are not the same thing. They are coexisting right now — in me and in most of the people I see building in this space.
The application is no longer necessarily the heart. It is becoming a surface — a doorway — while the real operational weight shifts inwards, towards a core that can be trained, corrected, governed.
That is the movement. And instinct has not caught up with it. The old instinct was: we need an application, and inside it we will place some intelligence. What is now appearing works almost the other way round — you have an intelligent engine, and if necessary you give it an interface as a layer of access. Some teams are still building the building while the centre of gravity has already moved. That is not a failure of intelligence. It may be a failure of the available vocabulary, which is not the same problem.
I have sat in rooms with technically capable people — people with real formation, people who were not lost — who still could not answer, with any precision, questions such as these: how do you keep training separate from detection once the system has been running for six months and the boundaries have blurred? How do you reconstruct context after an interruption without quietly importing the contamination of the previous session? How do you audit what went wrong when the failure was not a crash but a slow drift in behaviour that nobody noticed until it had already accumulated? I am putting those questions in a cleaner form than they actually arrived in, which is already a distortion. Databases, APIs, front ends — none of that disappears. But the new centre is not something their formation prepared them for. I do not mean prepared in a merely correctable sense. I mean that the entire direction of the formation pointed elsewhere.
The designer faces something adjacent — not the same problem, and I want to resist the parallelism because it flattens a different difficulty. For a long time design meant screens, journeys, user roles, the texture of interaction. Now it has to reach inside the operational order, and that changes the designer’s relationship to uncertainty. You have to define what the system........