From Computation to Cognition

Software has always been capable of producing outcomes that appear intelligent from the outside. A navigation system can find a route through a city, a banking platform can detect whether a transaction violates a rule, and an enterprise system can determine which workflow should follow a particular event. Yet in most traditional software, the intelligence behind those outcomes was supplied before the software ran. Human designers and engineers determined which conditions mattered, which rules applied, how exceptions should be handled, and how outputs should be produced. The software executed those decisions at runtime, but it did not usually make them in any meaningful sense.

This distinction is fundamental. In conventional software, much of the judgment is embedded during construction. A developer may encode a threshold, define a decision tree, construct a ranking formula, or specify a sequence of conditions. Even sophisticated systems often operate this way. Their behaviour may be complex, adaptive, or statistically informed, but the space of possible responses is substantially shaped in advance by the structure humans have given them.

Runtime execution is therefore, to a large extent, the replaying of decisions already made during design and implementation.

Machine learning altered this model by allowing some behaviour to be learned from data rather than explicitly programmed. Predictive systems could estimate risk, classify images, rank recommendations, or detect anomalies without a developer writing every individual rule. This was an important shift, but the role of such models was typically narrow and predefined. A classifier could determine which category an input belonged to, for example, but the surrounding software still had to decide what that classification meant, what should happen next, and how the result should be combined with other information.

Foundation models extend this shift considerably. They make a broader range of cognitive capabilities available to software through a common computational substrate. A system can now be given an ambiguous request and infer what the user is trying to accomplish. It can compare conflicting evidence, interpret an unfamiliar situation, critique a proposed answer, recommend an action, distinguish relevant information from incidental detail, or weigh competing considerations before reaching a conclusion. These behaviours are not limited to one predefined prediction task. They allow software to participate in portions of the decision process that previously had to be encoded procedurally or delegated to a human.

The important claim is not that software now thinks as humans do. That is a much larger philosophical and scientific question, and it is unnecessary to resolve it in order to understand the architectural change taking place. The more practical observation is that software can now perform classes of cognitive work that were previously difficult to express as conventional program logic. What matters for software design is the capability itself: interpretation, reasoning, evaluation, and judgment can increasingly occur inside the running system.

This changes the location of decision-making. Consider a customer complaint.

Traditional software might search for particular categories, ask the user to choose from a predefined list, and then route the case according to a set of rules. A cognitive system can instead receive the complaint in natural language, determine what happened, assess its seriousness, compare it with policy and previous cases, and recommend an appropriate response. The developer no longer needs to enumerate every possible wording, circumstance, and combination of factors in advance. Part of the decision is deferred until the system encounters the actual situation.

The concept of judgment is therefore central to this paper. Here, judgment is used operationally rather than philosophically. It refers to the selection or construction of an appropriate conclusion or action where the correct result cannot be completely determined in advance by a fixed procedure over the available inputs. Some judgments are simple and low consequence. Others involve ambiguity, incomplete information, conflicting objectives, or meaningful consequences. What they share is that specifying the desired outcome is easier than exhaustively specifying the procedure that will always produce it.

This gives software a new kind of implementation material. Computation allows us to express procedures. Storage allows us to preserve state. Networks allow systems to exchange information. Foundation models increasingly allow us to delegate bounded forms of judgment. The significance of the Intelligence Age is therefore not merely that models have become more capable, nor that software can generate text, images, or code. It is that judgment itself can now participate in the construction of software.

That change creates a new architectural problem. Once judgment exists inside a system, it cannot be treated as an undifferentiated layer of “AI.” We need to decide which judgments should be delegated, where each judgment belongs, what information it may use, how its responsibility is bounded, how it interacts with deterministic software, whether it can be reused, and how its quality can be evaluated. Conventional software architecture was not designed around these questions because conventional software did not routinely contain this kind of runtime cognitive responsibility.

A new theory becomes necessary not because software has ceased to compute, but because computation is no longer the only kind of work being organised within it.