Building used to be expensive. That forced us to choose.

Artificial intelligence has reduced the cost of generating code, screens, copy, and automations. Today, small teams build products that once required entire organizations, and a good decision can reach people in days.

That speed is a real opportunity. It also shifts the boundary: when building is no longer the hard part, the hard part becomes deciding what deserves to exist and what using it should feel like.

Building software has become less expensive. The cost did not disappear: it shifted to the person using it. It is paid in attention, learning, and decisions no one came to make.

When building is inexpensive, a weak idea quickly becomes an extensive implementation, and product ambiguity becomes behavior that appears finished. The code may be correct and still leave the person to handle the complexity the team did not resolve.

The thesis fits into one idea: the product is not the software, but the progress a person achieves with it. That is why experience is not a finishing touch added at the end; it is part of the function.

A system that delivers the correct outcome but forces people to interpret the interface, remember conventions, or fear making a mistake has still not solved the problem. It has only transferred it.

The principles are not aspirations. Each one must be able to change a decision, stop an implementation, or require more evidence; if a statement has no practical consequences, it serves no function. Each principle has its own page, with its tension, meaning, an example, a counterexample, and the questions for using it in an actual review.

A principle is useful when it changes what is done. There are three ways it can act on a specific decision.

It changes a decision. A home screen presents five actions with the same weight. With P06 on the table, the question is what the person needs at that moment: one primary action remains, and the rest appear where the context makes them relevant.

It requires evidence. A story says, “As a student, I want to receive hints for solving derivatives.” With P01, the question is when the blockage appears and how progress would be recognized. Until there is an observation to support it, the story is a hypothesis to be tested, not a requirement.

It stops an implementation. An assistant rewrites copy and publishes it without a preview. With P10, the implementation stops until the person can review, accept, or reject the change before it is published.

The principles become practice through a method: an authoritative product foundation, Job Stories as the reference form, an eight-step workflow, artifacts that exist only if they answer a question, a contract for coding agents, explicit reasons to stop, and a definition of done that is not satisfied with correct code.

See how to build with AI.

The manifesto may be applied with any method. A reference implementation brings it to SpecKit: the core governs an operational constitution, that constitution constrains the coding agent, and SpecKit, adapted without modifying its code, organizes the specification, plan, tasks, analysis, and implementation. How the adaptation works.

To continue: read the complete manifesto, explore the principles, see how to build with AI, or learn the status of the adaptation.