The Intelligence Ladder

How Much Intelligence Do We Really Need?

An intelligence ladder for software, and an alternative to the coding agent economy.

I have been thinking about a simple question:

How much intelligence does it actually take to build software?

Not how much intelligence is available. Not how large the latest model is. How much do we need for the particular thing we want to build?

Take a chat app.

It needs an interface, a message stream, channels, membership, and some notion of who is online. These are familiar pieces of software. Engineers have built them thousands of times.

Yet if I ask a coding agent to build the app, I often get an estimate that is little more than a guess.

The model starts working. It writes code, runs tests, fixes errors, and tries again. Sometimes it succeeds. Sometimes it gets stuck. The cost depends on how long the loop runs and how much intelligence the model needs along the way.

That is a strange way to buy software.

A builder can estimate a kitchen. A printer can quote five thousand flyers. But with coding agents, we are often asked to start a conversation and hope the bill makes sense at the end.

I think there is another way.

The intelligence ladder

Imagine that software could be built from a library of existing behaviors.

A behavior might be a message stream, a login screen, a search field, or a dashboard. Someone has already built it, tested it, and made it reusable.

Now imagine asking for a chat app.

The system looks at the request and asks:

• Which parts already exist?

• Which parts can be assembled from existing pieces?

• Which parts need a little adaptation?

• Which parts are genuinely new?

This is where the intelligence ladder comes in.

Think of it like a ladder of effort. At the bottom, the work is already known. At the top, the system has to invent something.

The lower the request lands on the ladder, the less intelligence it needs.

That sounds obvious. We do this everywhere else.

A factory does not redesign a chair every time someone orders one. It uses the same components, the same machines, and the same process. The work becomes cheaper because the knowledge is stored in the process.

Software can work the same way.

The missing piece is a way to store and reuse the behavior of a program.

Behaviors are the building blocks

For the past year, I have been building a system around this idea.

The unit of work is a behavior: a reusable piece of a program, with its state, events, and data.

A behavior might describe how a chat message appears, how a channel is selected, or how a user joins a conversation. Behaviors can be combined to form larger behaviors, and larger behaviors can form an application.

The important distinction is that the behavior is not just a piece of text or a code snippet. It is a thing the system knows how to build again.

Once a behavior exists, we should not need a powerful model to rediscover it every time someone asks for the same thing.

That is the foundation of the intelligence ladder.

I have been building this into Almadar Studio, which is currently in beta and free to use.

Four rungs, from replay to invention

The ladder has four levels.

1. Replay

The exact application, or the exact plan for building it, already exists.

The system rebuilds it from its stored behaviors.

No model calls are needed. The work is deterministic.

This is the cheapest kind of software creation: the system already knows what to do.

2. Full hit

The requested application closely matches something in the library.

Perhaps you want a chat app with different labels, a different color scheme, or a few additional fields.

A small model can fill in those differences. The rest comes from existing behaviors.

The expensive part of software creation has already happened.

3. Partial hit

Some parts of the request already exist. Others do not.

The system reuses the known behaviors and sends only the missing pieces to a stronger model.

If the chat app needs a familiar message stream but a new kind of conversation policy, there is no reason to reinvent the message stream.

Reuse what is known. Spend intelligence where it is needed.

4. Miss

Nothing in the library is close enough.

Now the system needs to author a new behavior, validate it, and repair it if necessary.

This is where a strong coding model earns its place.

And this is the important part: not every request should reach this level.

Today, coding agents often treat every request as if it were a fresh programming problem. Even when the work is familiar, they start writing.

The ladder turns that upside down.

What this looks like in practice

The Almadar library currently contains a little over a thousand behaviors, including atomic components and larger components composed from them.

A real-time chat app, for example, can be assembled from behaviors for:

• The message stream.

• Channels.

• Channel membership.

• Online users.

• Conversation policies.

These use shared components such as the application shell, browse lists, detail panels, search, confirmation dialogs, and notifications.

None of those components needs to be written specifically for chat.

They were built once. They can be used again.

This is the difference between asking a model to write an application and asking a system to assemble one.

The first approach starts with a blank page.

The second starts with a library.

The cost of intelligence

I have been testing this locally on my own machine, using different coding models.

The results are early, but they show why this matters.

One fresh e-commerce application took 62 model calls, around 1.1 million tokens, and 13 minutes on a 30-billion-parameter coding model. The estimated cost was about eight cents.

The same request on a 27-billion-parameter general model took 127 calls, around 3 million tokens, and timed out after 41 minutes. No application was produced.

A small edit to an existing dashboard took 12 calls and about four minutes on that same general model. On a smaller model, the edit took three calls and 21 seconds.

These are not production benchmarks, and the numbers will change as the system improves. But they illustrate something important.

The cost of software is not just the cost of the model. It is the cost of how much of the work the model has to rediscover.

When the system can reuse known behaviors, the amount of intelligence required falls.

And when the amount of intelligence falls, the cost falls with it.

The library compounds

This is the part I find most interesting.

Every new behavior added to the library can make future applications cheaper to build.

A message stream built for one application might be useful in a dozen others. A dashboard component built for a business app might become part of a school management system. A conversation policy might be reused across entirely different products.

The library becomes a kind of shared memory for software.

The more it contains, the less often the system needs to start from scratch.

This creates a different economic model for coding agents.

Instead of paying a model to recreate the same knowledge over and over, we store the knowledge and reuse it.

Instead of treating every application as a new programming project, we treat it as a composition of known behaviors and a small amount of new work.

The intelligence ladder is how we measure that difference.

Software should become cheaper to make

There is a larger question behind all of this.

Who should be able to build software?

Right now, a lot of the industry is organized around access to expensive intelligence. The latest model is better. The hardware is more expensive. The subscription is higher. The application is built through a long conversation whose cost is difficult to predict.

That may be a useful business model for the companies selling the intelligence.

But it is not necessarily a good model for the people who want to build things.

I would rather see software creation move in the opposite direction.

More shared components. More reusable behaviors. More local execution. More predictable costs. Less dependence on a frontier model for every small task.

A small business should not need access to the most expensive model in the world to build a useful internal tool.

A developer should not need to pay for a long sequence of model calls to recreate a component that already exists.

And a community should be able to build on the work of others without having to buy the same intelligence again.

That is what commoditizing technology means to me.

Not making intelligence less valuable.

Making it unnecessary to spend expensive intelligence on work that has already been done.

The alternative to the coding agent

I do not think coding agents are going away.

They are useful. They can write code, explore ideas, and solve problems that would otherwise take a lot of time.

But I think we have made a mistake by treating the coding agent as the entire software development process.

A model sitting in front of a blank project is not the only way to build software.

We can build systems that know what has already been built.

Systems that can measure the work before they start.

Systems that use small models for familiar tasks and strong models only when something genuinely new is required.

Systems that get cheaper as their libraries grow.

That is the direction I am exploring with Almadar.

The goal is not to build a better chatbot that writes more code.

It is to build a system where software knowledge can be stored, shared, and reused.

Where the next application does not begin with a blank page.

Where the intelligence required to build something is proportional to how new the thing actually is.

And where the cost of building software moves closer to the cost of assembling it.

The future of coding agents might not be about making models more intelligent.

It might be about making them need less intelligence in the first place.