Architectural Deficit

Putting a smart engine in a broken car does not make the car smart. It makes the engine frustrated.

This is what most AI in education has been doing for the past decade. Companies take a product that was originally designed to distribute lessons and track completions, then they add a predictive model on top, then a recommendation engine, then a chatbot, and they call the whole thing adaptive. But the structure underneath was never built for adaptation. It was built for delivery. It assumes that learning happens when you push content at people, and that the job of the technology is to push the right content at the right time. The AI gets bolted onto this assumption and then fails in predictable ways, because no amount of clever inference can compensate for a foundation that does not leave room for the learner to actually be present.

The failure looks technical from the outside. The model is not accurate enough. The data is too noisy. The predictions do not generalise. These are real problems, but they are symptoms, not causes. The cause is architectural, meaning the relationships between the parts of the system were never designed to support what is now being asked of them. You cannot fix a foundation by polishing the roof. You cannot make a delivery system adaptive by putting intelligence on top of it. At some point, somebody has to be willing to rebuild the structure itself, and that is usually the part nobody wants to fund because it has no visible output for a long time. When you have seen technology fail to deliver on its promise, how often was the real problem deeper than the part that was actually broken?

Last week we looked at deadlock that systems cannot see. This week we look at why putting a clever engine on top of an old structure rarely produces something clever overall.