Software Is Not Dead. We Have Barely Invented It.

The current debate is too small

Will AI replace software engineers?

It is a strangely narrow question.

It assumes that software itself is a finished object: human-readable source code, organised into applications, maintained through versions, and shipped as persistent products. The only variable is who types the implementation.

That assumption already looks unstable. Modern coding agents can traverse repositories, edit code, run checks, and work asynchronously. GitHub’s Copilot coding agent, for example, lets developers delegate tasks that return as draft pull requests for human review.

Evidence on productivity is mixed. METR’s randomized trial of 16 experienced open-source developers completing 246 tasks found that early-2025 AI tools increased completion time by 19% in that setting. A February 2026 follow-up found some evidence of speedup but warned that selection effects made the estimate unreliable. Faster code generation has not yet produced uniform engineering gains.

This tension points toward a deeper discontinuity.

The important question is not only whether AI can produce existing software faster.

It is whether AI will expand the set of things that can become software at all.

Code is not software

Code is one representation of software. It is not the thing itself.

Software is organised behaviour operating under constraints. It receives state, transforms state, exposes interfaces, obeys permissions, produces consequences, and fails in particular ways. The same behaviour can be represented in different programming languages, compiled into different machine forms, or distributed across different services.

For most of computing history, implementation remained central because implementation was expensive. Human beings had to write it, understand it, debug it, maintain it, and coordinate around it. Source code became both the executable material and the main cultural record of what the system was supposed to do.

AI changes that economy.

When implementation becomes cheap enough to generate, rewrite, and discard, code can no longer be the only stable object in the system. Something above the implementation must preserve what the software is allowed to mean and do.

That stable layer may contain:

• the entities that exist in the domain;
• the relationships between them;
• the states that are legal;
• the transformations that are permitted;
• the evidence required before an action;
• the authority attached to each participant;
• the invariants that must survive implementation changes;
• the conditions under which the system must stop, abstain, or ask for help.

The implementation can change. The contract cannot silently mutate with it.

This suggests a different definition for the AI era:

Software is stabilised cognition made executable.

A system reasons through a problem while the structure remains uncertain. Once a transformation becomes repeatable, bounded, testable, and economically cheaper to execute than to rediscover, it can harden into software.

Software is not the death of cognition. It is cognition that has become stable enough to leave the expensive reasoning loop.

Human limitations shaped the software we know

Modern software carries the fingerprints of the human minds that built it.

We favour representations humans can read. We split systems into modules humans can reason about. We design interfaces in advance because changing them is expensive. We package functionality into applications because a product must justify the cost of development and maintenance. We preserve versions because teams need stable points around which to coordinate.

These are not mistakes. They are adaptations to human bandwidth.

But they are not necessarily the final shape of software.

When an AI system can generate an implementation from a deeper specification, several forms of software become economically possible:

Temporary software can exist for one task, one investigation, or one decision, then disappear after returning a result and a trace.

Personal software can be generated around one person's context, constraints, permissions, and working habits rather than forcing millions of people through the same interface.

Adaptive software can reorganise its surface around the present objective while preserving a stable behavioural contract beneath it.

Domain-native software can be generated from an explicit model of a field rather than from a manually assembled feature list.

Cross-domain software can coordinate several systems of meaning at once, such as clinical reality, legal authority, database state, organisational policy, and human judgement.

The amount of software may increase precisely because less permanent code has to be written for each unit of behaviour.

When code changes, what remains true?

This is the central engineering problem.

If an AI can continuously generate and rewrite implementations, then the source code cannot be trusted as the sole description of the system's identity. The stable object must move upward.

A future software pipeline may look less like this:

requirements -> source code -> application -> release

and more like this:

intent -> domain model -> constraints -> generated behaviour -> observed consequence

Code still exists. It becomes one compiled projection of a deeper structure.

This is where ontology engineering—and the broader practice of cognition engineering—may move from specialist disciplines toward the centre of software creation.

Why AI-generated software needs ontology engineering

An ontology defines the meaningful objects in a domain and the relationships among them. In a hospital, that may include patients, diagnoses, treatments, contraindications, clinicians, permissions, records, and responsibilities. In an industrial system, it may include assets, processes, failures, schedules, operators, and safety states.

Ontology engineering is not new. The W3C’s Web Ontology Language (OWL) formally represents rich knowledge about things and their relationships so software can check consistency and make implicit knowledge explicit. Current AWS guidance on semantic layers for agentic AI likewise treats ontology management as an engineering surface for services and agents.

What changes in AI-generated software is the ontology's position in the stack.

Today, an ontology is often a supporting artefact beside the application. In AI-generated systems, it may become part of the generative substrate from which implementations are produced.

Trustworthy generated behaviour requires, at minimum, a declared model of the world in which it will operate:

What exists?

Which distinctions matter?

Which relationships are valid?

Which state changes are reversible?

Who may propose an action, and who may commit it?

What counts as evidence?

What must remain true even when the interface, code, or model changes?

An AI that can generate code without answering these questions is not generating software. It is generating implementation-shaped speculation.

But ontology engineering alone is not enough.

An ontology can describe a world. Operational software must also translate meaning between representations and systems.

An ontology describes a world. A synthetic language makes worlds interoperable.

A healthcare system does not live inside one representation.

A clinician expresses an intention in natural language. That intention refers to a clinical ontology. It must become software constraints, database operations, interface states, legal responsibilities, and eventually a human or physical consequence.

Each layer has its own primitives, rules, tolerances, and failure modes.

Natural language carries enormous implicit context. Programming languages offer precision, but usually inside a computational frame. An ontology defines entities and relations, but does not automatically preserve how a transformation should survive movement from one abstraction layer into another.

We use the term synthetic language engineering for that gap.

A synthetic language is not merely a new vocabulary and not merely a shorter programming syntax. It is an engineered compatibility layer through which selected relationships can survive changes of representation, scale, and domain.

Its purpose is not compression alone.

Its purpose is translation survival.

human intention
    <-> domain ontology
    <-> synthetic language
    <-> executable behaviour
    <-> evidence from the world

The arrows are the hard part.

A relationship that appears in prose may need to remain recognisable when expressed as a constraint, a state transition, a software action, and a later audit record. The surface form can change. The declared meaning, permissions, and consequences must not silently dissolve during translation.

This is also why meaning cannot be treated as a label stored behind a word. For engineering, an expression matters because of what it makes easier, harder, visible, recursive, forbidden, or executable.

The same term can produce different effects in different contexts. A synthetic language therefore needs more than symbols. It needs scopes, grounding, transformation rules, uncertainty, provenance, and a way to expose what was lost.

That is the bridge between ontology engineering and the future of programming.

Ontology engineering establishes a machine-interpretable model of the world.

Synthetic language engineering establishes how worlds can think and act through one another.

Software becomes the executable consequence of that translation.

The boundary between AI and software will move

We often talk about AI and software as if they were separate categories: conventional software as bounded and deterministic, generative AI as flexible and probabilistic. That distinction is operationally useful, but technically incomplete.

Some tasks are novel, ambiguous, under-supported, or sensitive to meaning. They still require open reasoning. Other transformations recur. They become predictable, bounded, and testable. Reconstructing them through a large model every time becomes wasteful.

The system can then move stable work outward into executable structure:

open reasoning -> recurring behaviour -> tested structure -> software

When the environment changes, assumptions fail, or observed behaviour diverges from the contract, the movement should reverse:

software -> detected mismatch -> reopened reasoning -> revised structure

This creates a moving frontier.

If nothing stabilises, the system repeatedly pays to rediscover the same cognition and forgets its own work.

If everything stabilises permanently, the system becomes a brittle museum of yesterday's assumptions.

The stronger architecture keeps familiar behaviour cheap while allowing unfamiliar pressure to become thinkable again.

This is a fundamentally different vision from an AI assistant that merely writes functions on request. The AI is no longer only generating software. It is participating in the developmental boundary between fluid cognition and stable execution.

Programming moves above the implementation

The role of the engineer therefore changes, but it does not disappear.

Current AI coding tools are already pushing developers toward orchestration: defining tasks, permissions, checks, review boundaries, and handoffs. That is real, but it may still be a transitional stage.

The deeper role is not merely orchestrating agents that write familiar code.

It is engineering the representational environment from which valid behaviour can be generated.

The future software engineer may increasingly work as a combination of:

• ontology engineer;
• constraint designer;
• verification architect;
• authority mapper;
• synthetic language engineer;
• system governor;
• designer of the conditions under which software may change itself.

The scarce skill moves from expressing every instruction manually toward defining what the system must preserve.

That includes deciding which objects are canonical, which transformations are legal, which evidence can promote a proposal into action, which failures must remain visible, and which changes require human authority.

Programming does not vanish.

It climbs an abstraction layer.

Generation is not authority

There is an obvious danger in this future.

If code becomes cheap, failure becomes cheap too.

AI can generate many implementations before a human team has properly understood the domain. A malformed ontology can make the wrong categories appear natural. A synthetic language can conceal semantic loss behind elegant symbols. A dynamically generated interface can manipulate the user while technically satisfying a feature request. A system can repeatedly produce plausible behaviour and still misunderstand what it is allowed to change.

The central governance law is simple:

A generated structure is a proposal, not an authority.

A model may propose an implementation, a relation, a workflow, or a new abstraction. That proposal should acquire durable or operational power only after the relevant evidence, constraints, tests, permissions, and failure boundaries are satisfied.

This distinction matters more as software moves above code.

In traditional engineering, a code review can inspect a relatively stable artefact. In generated systems, the review target may include the ontology, the behavioural contract, the translation layer, the permissions, the generated implementation, and the evidence produced after execution.

The assurance surface expands.

Human-readable source code will therefore remain important, particularly in safety-critical, high-performance, cryptographic, embedded, and formally verified systems. Not every layer should become fluid. Some systems benefit precisely from being small, deterministic, and difficult to mutate.

The future is not a universal replacement of traditional software.

It is a larger software ecology with several phases of stability.

We have barely invented software

The current AI coding debate is still trapped inside the source file.

It asks whether a model can write a feature, fix a bug, review a pull request, or replace a programmer.

Those questions matter. They are also the shallow edge of the transformation.

The deeper shift begins when implementation stops being the only stable representation of a system.

Then software can be generated from explicit models of reality. Ontologies define what exists. Synthetic languages preserve relationships as they move between domains. Constraints and evidence determine which generated behaviours may become real. Stable reasoning crystallises into executable structure. New mismatch reopens the structure to cognition.

Our prediction is that, by the early 2030s, some production software systems will treat source code as a generated artefact rather than the primary specification.

Their canonical centre will sit higher:

world model
+ intent
+ constraints
+ authority
+ invariants
+ evidence

Code will remain essential. It will no longer be sovereign.

Software is not dead.

The code-centred era may only have been its first recognisable anatomy.

We have barely invented it.

References

• GitHub: Copilot coding agent is generally available
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• METR: We Are Changing Our Developer Productivity Experiment Design
• W3C: OWL 2 Web Ontology Language — Document Overview
• AWS Prescriptive Guidance: Ontology Engineering for a Semantic Layer for Agentic AI