Foundations

The question this section answers: why propose a different way of consuming software delivery, and why now?

The other sections explain how the model works. This one explains why it exists. It follows one line of argument in four steps.

The line of argument

1. Software delivery today. Turning an intention into usable software takes work before, during and after implementation: understanding the request, representing alternatives, forming conditions, coordinating decisions and recognizing the delivery. That work has a cost, and it recurs around every commitment.
2. Why AI changes the model. The enabling cause. AI could change the economics of learning, specifying, experimenting, coordinating, producing and evaluating. Technical capability is not the same as economic viability, and the argument keeps them apart.
3. The abstraction problem. For those gains to survive the hand-over between activities and executors, the meaning of a demand has to stay usable. This step explains why the buyer still has to organize too much, and how a better representation of the demand could change that.
4. From capacity to outcomes. The consequence for what is bought: buying useful advances and choosing scope and investment, while keeping capacity, delivery and benefit of use apart.

Where to start

Read the pages in order if you want the argument. If you want to see the idea at work first, the model follows one demand through, and intent to production tells the same story in full detail.

What this section does not claim

The four pages keep the broad scope of “software delivery”, the conditional nature of any gains from AI, and the distinction between a technical delivery and a business effect. Their coherence as an argument is not empirical validation, and it does not confirm that the idea is new. The hypotheses and how they could be tested are in the model’s viability conditions.