How much code is still needed ?

Introduction

AI is making software dramatically cheaper to build. At first sight, that suggests a simple conclusion: we will produce much more code. And in the short term, that is probably true.

But there is another trend happening at the same time. A growing number of tasks that used to require conventional software are increasingly being handled directly by AI models. That raises a more interesting question: How much traditional code will we actually need in the future?

Cheaper software means more software

The first effect is easy to understand. When software becomes cheaper and faster to build, the economic threshold for creating it drops. Projects that would previously have been too small, too specialised or too short-lived suddenly become worthwhile.

A company can build a custom internal tool instead of forcing a generic product to fit its process. A small organisation can automate a workflow that previously did not justify a development team. A niche market can support software that would once have been commercially impossible. In that sense, AI should create a large expansion in software development: Less cost per application means more applications get built.

But this is only half of the story.

The model becomes the capability

Traditional software exists because computers historically needed explicit instructions. If you wanted to recognise speech, translate a document, classify an image, extract information, generate a report or modify a photograph, somebody had to implement a procedure that performed that task.

That procedure might involve thousands or millions of lines of software. Increasingly, these capabilities have moved into an ai model. Instead of implementing a large amount of application logic, we can increasingly provide a model with input, context and constraints and ask it to produce the required result.

Image software is an obvious example. Traditional image editors expose a large collection of carefully implemented operations: selection tools, masks, filters, transforms, retouching tools and so on. An AI system can increasingly accept an instruction such as:

Remove the person in the background and make the scene look like it was photographed at sunset.

The underlying image-processing technology still exists, of course. But from the application's point of view, much of the capability has moved out of explicitly programmed user interaction and into the model. The same shift is happening in text, audio, video, search, data analysis and software development itself.

More domains will follow.

Less application logic

This could significantly reduce the amount of conventional application logic we need.

A traditional application might look roughly like this:

input → parsing → rules → transformations → output

An AI-heavy application increasingly looks more like:

input → model → output

with software surrounding the model to provide context, tools, permissions, state and validation. That distinction matters: the software has not disappeared, but its role has changed. The intelligence is no longer necessarily encoded in the program, it may live in the model.

The system still remains

Consider an insurance claims application.

A traditional implementation may contain substantial amounts of software for document recognition, information extraction, classification, routing, correspondence and decision support.

A future system might allow an AI agent to understand most of the claim directly. That does not mean the claims system disappears. Something still has to define what the agent is allowed to do.

For example:

• The agent may inspect these documents.
• It may query these external databases.
• It may request additional information from the customer.
• It may approve claims below a particular threshold.
• Larger claims require human approval.
• Every decision must be recorded.
• The agent may never transfer money directly.

Those constraints form a system.

And that system may be more important than the implementation of the intelligence inside it. As models become more capable, software increasingly becomes responsible for orchestration, state, policy, interfaces and control.

Less code per system, more systems overall

These two trends therefore pull in different directions. AI makes software cheaper to produce, so we will build more systems.

At the same time, AI models absorb functionality that previously required large amounts of explicitly programmed logic.

The likely result is:

less traditional code per system, but many more systems.

Whether the total number of lines of code in the world goes up or down is probably not the most important question. The more significant change is where the value moves. The valuable part of software development becomes less about manually implementing every capability and more about deciding what the system consists of.

Code becomes one implementation option

This also changes how we should think about software architecture. A component in a future system does not necessarily have to be implemented as conventional code. One component may be TypeScript, another may be an LLM, another may use a specialised vision model.

Yet another may call an optimisation engine or may wrap an external service. Another may represent a human approval step.

From the perspective of the overall system, these are implementation choices. The architectural questions remain remarkably similar:

• What is this component responsible for?
• What information may it access?
• What does it expose to the rest of the system?
• Which other components may communicate with it?
• What happens when it fails?
• What behaviour must remain deterministic?

Those questions do not disappear when code becomes less important. They become more important.

Intelligence versus determinism

One of the central design questions of future software may be deciding where intelligence belongs. Not everything should become an AI problem.

If a deterministic algorithm can calculate a financial transaction exactly, there is little reason to ask a probabilistic model to do it. Conversely, implementing thousands of rules to understand an unstructured document may make little sense when a model can interpret it more effectively. Future systems will therefore combine intelligent and deterministic components.

The job of the architect is increasingly to decide which is which. That creates a new kind of software-design boundary:

Where should the system reason, and where should it simply execute?

Architecture outlives implementation technology

This is important for how we think about Vizual Model and vmblu. vmblu should not depend on the assumption that the future consists mainly of coding agents producing enormous amounts of conventional application code. Models will change and agents will improve.

Some categories of code may disappear almost entirely, but systems will still need structure.

Whether a capability is implemented by handwritten code, generated code, an LLM, a specialised model, an external service or a human operator, it still needs a place in the architecture, it still needs responsibilities and boundaries, it still needs interfaces, it still needs controlled access to the rest of the system. That is the layer that remains.

From writing software to designing systems

Traditional software development has often followed a path like:

requirements → algorithms → code → application

The emerging model looks increasingly like:

intent → architecture → models + tools + deterministic components → running system

Code remains an important part of that equation, but it is no longer necessarily the centre of it.

As implementation becomes cheaper and intelligence moves into models, the scarce resource shifts upward.

The difficult questions become:

• What should the system contain?
• Which parts should be intelligent?
• Which parts must remain deterministic?
• How should they communicate?
• Where are the boundaries?
• Who or what is allowed to do what?

That is less a programming problem than a system-design problem. And that may be the most important consequence of AI for software engineering:

we may write less code per system, while architecture becomes more important than ever.