Trajectory for compositional development

Software development is moving toward a strange constraint.

Models keep getting better. They reason for longer, use more tools, navigate larger codebases and complete increasingly complex tasks. Getting more intelligence out of these systems also requires enormous amounts of compute.

The obvious response is more infrastructure. More GPUs, larger clusters, new data centers and more power generation. This will continue. There is enormous value in making inference cheaper and increasing the amount of compute available to models.

But there is another part of the compute equation: how much computation we repeat.

Today an agent can spend millions of tokens understanding a codebase, exploring implementations, correcting mistakes and eventually arriving at something that works. When another agent encounters the same problem, much of that reasoning happens again.

We are very good at scaling computation. We are still early at preserving its useful results.

That is beginning to change.

Skills are the early layer

Skills are one of the first visible signs of a compositional development model.

Instead of explaining the same process to an agent every time, a process can be packaged and provided when the task appears again.

A skill can teach an agent how to review a pull request, deploy an application, migrate a database or work inside a particular framework.

The important part is what happens next.

Instructions still require the model to interpret them and produce an implementation. Once a working implementation exists, preserving the exact code can be substantially more efficient.

Exact code is easier to implement than to adapt from a description. The difficult reasoning has already happened. Architecture has been chosen, edge cases have been discovered, APIs have been understood and an implementation has been tested.

The next agent can start from that result.

This expands reuse beyond traditional libraries. Agents can reuse procedures, implementation patterns, debugging strategies, architecture decisions and complete working implementations that previously disappeared into repositories or context windows.

The expensive thinking happens once

This changes where model intelligence needs to be spent.

A strong model might spend significant compute discovering how to solve a difficult task. Once that solution has been validated and preserved, the same level of reasoning should not be required every time the task appears.

The expensive model solves the unknown part.

Future agents retrieve the known part, adapt it to the local environment and verify that it still works.

As the amount of preserved work increases, smaller and faster models can perform a larger percentage of development tasks. They are operating with the result of reasoning that has already been performed by stronger models.

The model starts further ahead.

From generation to composition

Development then becomes increasingly compositional.

An agent receives a task and searches through existing work before generating something new. It retrieves relevant code, skills, patterns and previous solutions, understands the local constraints and composes them into the required implementation.

Generation becomes concentrated around what is actually novel.

This matters for compute because repeated reasoning is expensive at scale. If one million agents independently discover the same implementation, we have paid for essentially the same reasoning one million times.

If the implementation can be preserved and reused, the expensive part can happen once.

Compute begins to accumulate.

A model run produces an immediate output, but successful work can also become an input to future model runs. Each solved problem increases the amount of existing material future agents can compose from.

A shared layer of solved work

The effect becomes much larger when this happens across a community rather than inside a single developer's environment.

One developer solves a difficult integration. Another discovers a reliable architecture for a particular workload. Someone else finds an edge case and improves the implementation.

Their work becomes available to future agents.

The useful output of expensive models can gradually become shared infrastructure for cheaper models.

At sufficient scale, a large portion of everyday development could run on smaller models, including open-weight models running locally or on inexpensive inference infrastructure. They would not need frontier-level reasoning for every task because much of the difficult reasoning would already exist in the environment around them.

Frontier models would continue pushing into unsolved territory. Their successful work would flow downward into reusable artifacts that increasingly capable smaller models could compose.

Where this goes

This starts to resemble the history of software itself.

Developers stopped building everything from first principles because useful abstractions accumulated. Operating systems, libraries, frameworks, packages and APIs turned previous engineering effort into building blocks.

Agents are beginning to develop another layer on top of that stack.

Skills are early.

Working implementations are more powerful.

Eventually the reusable unit can contain the code, the procedure that produced it, the constraints it depends on, the tests that validate it and evidence about where it succeeds or fails.

A task enters the system. The agent determines what has already been solved, retrieves the relevant pieces, reasons about the remaining uncertainty and produces the smallest amount of genuinely new work required.

That new work becomes another building block.

The frontier still requires enormous compute. Data centers will continue to grow because the frontier itself keeps moving.

But everyday software development does not need to repeatedly live at the frontier.

As solved work accumulates, more development can move toward smaller, faster and eventually open-weight models composing from a growing body of work that has already been figured out.

The long-term compute story is therefore partly infrastructure and partly accumulation.

We need more capacity to solve new problems.

We also need the work produced by that capacity to compound.