What Becomes Scarce When Software Gets Cheaper to Build?

START WITH THE MECHANISM

Interactive companion and laboratory update: 12 November 2026. The editorial date places the topic on the timeline; this current explanation and its measured evidence retain their actual preparation and execution dates.

THE FULL INVESTIGATION

What Becomes Scarce When Software Gets Cheaper to Build?

Dates and technology context

This is a retrospective editorial timeline. Topic context: 24 October 2026. First publicly available: 12 November 2026. Current text, visuals and laboratory revisions were prepared on 12 November 2026.

The inspectable-evidence examples were executed after the October2026 context, on November12; they do not establish historical personal or customer experience.

Prepared on 12 November 2026, this retrospective essay explores the question through the lens of 24 October 2026; it does not imply that the essay existed or was published then.

Imagine that tomorrow you could build every application on your list. The internal dashboard, the personal research tool, the customer portal, the small product idea you have postponed for years. Suppose the initial implementation cost falls enough that creating them is no longer the difficult decision.

Would you use them all? Would anyone else? Which would you trust with important work? Which would you still maintain after the novelty passed?

These questions reveal a limit in the popular story about cheaper software. Lower creation costs can expand what people attempt, but they do not make every attempt valuable. They change where the difficult choices occur.

My hypothesis is that as implementation becomes easier in more settings, attention, trustworthy judgment, distribution, and responsibility for continued outcomes become more important constraints. This is a conditional argument about how value can move, not a claim that all software is already cheap or that development skill has lost its value.

The useful question for an engineer, founder, or advisor is where that movement leaves work worth doing.

Begin with the cost that actually fell

Software has several costs: deciding what to build, creating an implementation, integrating it, earning adoption, operating it, and changing it when circumstances shift. A reduction in one cost does not establish an equal reduction in the others.

Even the implementation gain varies by task. METR's original July 2025 study provides a useful warning that perceived acceleration and measured completion can diverge in a particular setting. It should not be generalized into a universal verdict about AI productivity. METR, original study.

So the argument begins with a condition: where AI lowers the effort required to produce a useful first implementation, what happens next?

One likely possibility is more experimentation. Another is more competition among similar offerings. A third is that organizations create more internal tools. These outcomes need not occur equally, and none guarantees a profitable business.

The cost reduction changes the set of feasible actions. People must still choose among those actions and bear the consequences of the choice.

This distinction protects the discussion from both exaggerated optimism and defensive dismissal. A tool can create significant opportunity without making every existing constraint disappear.

Abundance makes selection consequential

01 / See the idea

A lower creation cost leaves other questions

Enlarge diagram

Consider a hypothetical buyer evaluating several tools that solve the same administrative problem. Each has a credible interface and a convincing demonstration. Creating another comparable interface may be relatively easy.

The buyer's difficult questions lie elsewhere. Which tool understands the actual workflow? Which can be integrated without creating another reconciliation task? Who will respond when an important result is wrong? Can the buyer leave without losing access to their own information?

These questions concern the relationship between software and the work it promises to support. They may remain difficult even when the visible product is easy to reproduce.

For the founder, this changes the meaning of differentiation. A feature can still matter, especially if it solves a neglected problem. But a long feature list may be a weak defense when alternatives can add similar capabilities quickly.

A clearer understanding of the customer's situation can be more valuable. So can reliable operation, a coherent product boundary, or a credible way to resolve failure. None is free. Each requires sustained work that may be less visible than a launch demonstration.

Abundance increases the value of selection only when someone is willing to accept responsibility for the selection. A recommendation that simply lists every available option leaves the hard decision with the buyer.

Attention cannot be generated for the recipient

An organization may become able to produce more proposals, reports, and applications than its members can evaluate. The output expands, while the recipient still has limited time to decide what deserves attention.

This creates a practical scarcity. A person who can identify the few items that matter, explain why they matter, and make them easy to assess provides a useful service.

That service should not be confused with louder promotion. Capturing attention briefly is different from earning continued attention. A dramatic claim may bring a reader to an article while teaching them to distrust the next one.

For a technical author, the implication is editorial restraint. Publish a claim with a clear boundary. Explain what the reader can do differently after reading it. Preserve the evidence that makes the recommendation inspectable. Avoid expanding a small observation into a universal prediction merely because a stronger headline is available.

This is a proposed strategy for earning trust, not a guarantee of audience growth. Distribution also depends on relationships, timing, and many circumstances outside an author's control.

The controllable part is whether the publication respects the reader's attention by delivering something worth the time it asks for.

Trust is accumulated through consequences

02 / A concrete example

Two proposals can sell different commitments

Enlarge diagram

A new product can claim reliability immediately. A customer learns whether that claim deserves confidence over time, especially when something goes wrong.

In a hypothetical service business, two providers can generate similar technical proposals. One makes broad promises and leaves assumptions implicit. The other identifies the uncertain parts, defines a bounded investigation, and explains what evidence would justify the next commitment.

The second proposal may look less spectacular. It may be more useful to a buyer who needs to understand the consequences of proceeding.

Trust in this setting is not a feeling of warmth toward the provider. It is a reasoned willingness to depend on their work within a particular boundary. That willingness can be supported by clear methods, relevant artifacts, honest limitations, and a process for correction.

For someone without a long public portfolio, the right response is to build inspectable evidence. A reference implementation can demonstrate care. A laboratory investigation can show how a question is tested. An essay can expose reasoning. None should be presented as a customer outcome it does not represent.

Cheaper creation makes fabricated authority easier to perform. It also makes genuine evidence more important for anyone trying to distinguish themselves without pretending to have a history they do not have.

Distribution remains a relationship

The ability to build a product does not create access to the people who need it. Those people may already use an incumbent, distrust unfamiliar suppliers, or lack the time to evaluate alternatives.

In a hypothetical market, a small tool could solve a real problem and still struggle because the buyer encounters it at the wrong moment or cannot explain its value internally. A technically weaker alternative might fit an existing procurement relationship and therefore be easier to adopt.

These possibilities do not prove that distribution always dominates product quality. They show why the route to the customer belongs in the product strategy.

For an engineer moving toward advisory or entrepreneurial work, this means learning how a useful idea reaches a decision. Who experiences the problem? Who can authorize a purchase? What evidence does that person need? What change would adoption require from others?

Answering those questions does not require abandoning technical depth. It gives that depth a path into practical use.

It also helps avoid a familiar trap: building more features because implementation feels tractable while the adoption problem remains uncomfortable. More software cannot automatically resolve a missing relationship with the buyer.

Responsibility becomes part of the product

Suppose a hypothetical company can generate a custom internal application cheaply. It still needs someone to own access, data quality, operational failures, and future changes. If nobody accepts those obligations, the application may become a dependency without a dependable owner.

A supplier who accepts a clear responsibility can therefore offer value beyond the initial code. The customer may be paying for a maintained outcome and a defined response when the outcome fails.

This does not justify vague service promises or unlimited liability. Responsibility needs a scope. The supplier should explain what is monitored, what is supported, which decisions remain with the customer, and how changes are handled.

The commercial opportunity lies in making the boundary credible. A narrow promise that can be maintained may be more valuable than an expansive promise supported only by a persuasive demo.

For an investor or advisor evaluating a business, this suggests a question about the operating model: what obligation will customers continue to value after similar code becomes easier to obtain?

The answer might involve expertise, integration, data stewardship, or dependable execution. It might also reveal that the business has little beyond an implementation advantage. That is an analytical lens, not a claim about any investment activity or return.

The strongest counterargument is new demand

03 / Watch the mechanism

Value continues after the first implementation

Enlarge diagram

Static view. Play to see how the mechanism unfolds.

An abundance argument can become too pessimistic about creation. Lower costs may unlock needs that were previously uneconomic to serve. People may build highly specific tools for small groups, personal workflows, or temporary situations.

In those settings, distribution may be simple because the creator is also the user. Formal operating commitments may be unnecessary because the tool is disposable. The primary value may indeed come from being able to create the artifact at all.

That is a genuine opportunity. It means the constraints differ by setting, not that the constraints vanish everywhere.

A personal script, a shared internal workflow, and a customer-facing service should not be evaluated with one business model. The moment other people rely on the result, questions of ownership and continued behavior become more important.

The argument would also weaken if AI substantially reduced the costs of verification, integration, distribution, and operation alongside implementation. That is possible in particular workflows and deserves observation. The appropriate response is to follow the changing constraints rather than declare a permanent hierarchy of value.

Scarcity can move again. A useful strategy watches the movement instead of turning today's bottleneck into an eternal principle.

Inspectable evidence is not the same as an impressive portfolio

01 / See the idea

A claim register can preserve unknowns

Enlarge diagram

Contemporary laboratory note, prepared 12 November 2026. The next four sections connect the October argument to subsequently executed reference work. They do not imply that these results were known at the earlier context date.

The evidence-pack laboratory builds a claim register from preserved technical artifacts. Its executed packet distinguishes six accepted claims, two rejected claims and five unknown claims under explicit predicates. It checks artifact hashes and the relationships between claims and evidence. It does not recommend an investment, estimate a business return or turn a technical fixture into a customer outcome.

The unknown category is especially important to the argument here. A portfolio can contain many working demonstrations while leaving adoption, operating cost and business value unestablished. That does not make the demonstrations worthless. It means their evidential value depends on which question the reader is asking. A verified implementation can show that a mechanism was exercised. It cannot, by itself, show that a market needs the product or that a supplier will operate it well over time.

This creates a different standard for public technical work. The goal is not to accumulate artifacts that appear to answer every question. It is to make each artifact useful for the question it can actually address. A reader should be able to tell where the source ends, where the measurement ends and where the author's judgement begins. The boundary is part of the work, not an apology attached to it.

A hypothetical buyer may prefer a smaller collection of relevant, inspectable examples to a large gallery with unclear provenance. Another buyer may care primarily about a supplier's operating history. Neither preference proves a universal commercial rule. The author controls something narrower: whether the material accurately represents what was done and what remains unknown. A fabricated customer story would destroy that distinction precisely where the reader needs it most.

Technical depth therefore includes restraint. It is possible to explain a sophisticated mechanism without presenting it as a production achievement. It is possible to show an adverse result without converting it into a success through wording. When implementation becomes easier to display, the harder editorial choice may be deciding which conclusion the evidence is entitled to support. That choice gives a portfolio intellectual coherence even before it gives anyone a reason to buy.

Responsibility begins where a successful operation stops answering the question

The agent spending-authority laboratory examines a controlled external-effect boundary. Its evidence includes a receiver effect followed by a lost response, with the reservation retained until reconciliation. Reopening and reconciling the fixture does not duplicate that receiver effect. These are bounded technical observations, not a claim about a live payment provider or customer money.

The business relevance lies in the distinction the mechanism preserves. A missing acknowledgement does not necessarily mean nothing happened. If a product promises to perform an action, someone must decide what to do when the outcome is uncertain. Repeating immediately may duplicate an effect. Declaring failure may tell the user something the system does not know. Reconciliation is work that remains after the attractive part of the demonstration has finished.

This gives responsibility a concrete meaning. It is not merely being available to apologize. It includes designing the uncertain state, preserving the evidence needed to resolve it and assigning authority for the next action. A product that exposes these boundaries clearly can make a narrower and more credible promise than one that treats every non-success response as interchangeable.

The same principle applies outside payment-like examples. A hypothetical document service might acknowledge an upload while indexing remains incomplete. A dashboard might refresh successfully while showing an old published snapshot. A generated proposal might compile while its acceptance conditions remain unresolved. The initial operation is real, but the maintained outcome requires more than the operation's local success.

This does not prove that responsibility will always command a higher price than implementation. It is a reason to examine what the customer actually depends on. If the task is disposable and reversible, a thin implementation may be enough. If other people organize their work around the result, uncertainty handling and continued ownership can become central to the product. The important question is which promise survives contact with failure, not which promise sounds most comprehensive before failure occurs.

Scarce judgement can be shared rather than concentrated

02 / See the idea

Make expertise inspectable

Enlarge diagram

There is a problematic version of the scarcity argument in which a few experts become indispensable gatekeepers. If every important decision requires their personal attention, the organization may merely exchange an implementation bottleneck for a judgement bottleneck. Celebrating expertise without examining how it scales can produce dependence rather than capability.

A better ambition is to make parts of expert judgement transmissible. A well-designed laboratory exposes the question, method, result and limitation so another engineer can assess it. A clear decision record identifies which requirement mattered. A useful workshop teaches how to distinguish a supported claim from an attractive inference. These artifacts do not eliminate expertise, but they reduce the amount of trust that must rest on a person's reputation alone.

This is not the same as assuming every judgement can be reduced to a checklist. Some decisions involve conflicting goals, incomplete evidence or a responsibility that an organization has explicitly assigned to a person. A checklist can prepare that decision without owning it. The aim is to separate what can be inspected and repeated from what still requires accountable interpretation.

Consider a hypothetical architecture review. One expert could announce the preferred design and ask the team to accept their experience. Another could explain the workload boundary, show the adverse case that ruled out an alternative and identify the condition that would reverse the choice. The second approach may take more preparation initially. It also leaves the team better able to revisit the decision when circumstances change. This is a normative comparison, not a measured claim about review speed.

For an author or advisor, the implication is demanding. Do not build an identity around being the only person who can interpret the evidence. Build one around improving the quality of the shared interpretation. Trust can then attach to a method of work: clear premises, reproducible observations, proportionate conclusions and visible correction. That kind of reputation remains compatible with readers learning enough to challenge the author, which is exactly what a serious public body of work should enable.

Cheap verification would change the argument, not end it

The strongest future challenge to this essay is not that implementation will remain expensive forever. It is that assistance may also make verification, interpretation and operation substantially cheaper. If a system can generate tests, identify contradictions and prepare a useful evidence packet, then some work currently described as scarce judgement may become easier to distribute.

We should welcome that possibility rather than defining expertise so that it is protected from automation by assumption. The relevant question is which responsibility the improved mechanism actually absorbs. A tool that checks an explicit contract can reduce repeated inspection. A tool that proposes better experiments can improve investigation. Neither automatically chooses the contract's business meaning or accepts the consequences of an unresolved case.

The distinction is visible in the reference claim register. A deterministic predicate can classify a bounded claim using preserved artifacts. The choice of which claims matter and whether their scope is sufficient for a business commitment remains outside that predicate. If future systems improve that wider judgement too, the boundary should be reconsidered. There is no reason to preserve a human task merely because it used to require a human, but there is every reason to ask what evidence supports transferring its authority.

Abundance can also reduce the need for formal responsibility in some settings. A person may create a temporary tool, inspect its output once and discard it. No buyer, operator or long-term promise is involved. It would be a mistake to impose a service-business model on that useful activity. The argument concerns the transition into dependence, not a moral obligation to turn every script into a maintained product.

This makes the practical strategy more flexible than a prediction about permanent scarcity. Look for the next unresolved boundary in the actual outcome. Sometimes it will be implementation. Sometimes it will be choosing among alternatives, integrating with existing work or resolving an uncertain effect. The valuable contribution is to make that boundary tractable without pretending it has disappeared. An expert identity can be built around this disciplined movement between code, evidence and consequence rather than around a claim that one category of work will always remain beyond automation.

Choose the promise before expanding the output

For a professional building a public body of work, the implication is concrete. Do not compete only on how much material you can produce. Decide which questions you want readers to trust you to investigate, then create evidence that deserves that trust.

For a founder, define the maintained outcome before expanding the feature list. For an advisor, make the decision and its consequences legible. For an engineer, develop the ability to identify the boundary where a plausible implementation becomes a dependable system.

These choices may lead to fewer artifacts than the tools make possible. That can be a sign of discipline rather than a failure to exploit the technology.

Return to the opening thought experiment. If you could build every application on your list tomorrow, which would still deserve your attention a year later? Who would depend on it? What would you be willing to promise them?

The answers locate the work that remains valuable after creation becomes easier. They also reveal the responsibility that begins when a useful possibility becomes something another person trusts.