TL;DR
AI has made generating code dramatically cheaper, but it has not made defining quality, proving conformance, or accumulating real-world trust cheap. The cost structure of software is shifting: implementation is becoming abundant, while explicit definitions, validation, traceability, and operational evidence remain scarce. AI can generate candidate implementations near instantly, but a product's value does not disappear just because its code can be reproduced cheaply.
The claim I keep hearing
"In the AI era, the value of software artifacts goes to zero."
The reasoning usually goes: AI writes code fast and cheap, so anyone can regenerate any product, so the product itself is worth nothing. Only the idea, the spec, the "definition," matters now.
I think this claim sounds right because it mixes up two things: the cost of producing an artifact and the value of that artifact. To pull them apart, I need a model of what development cost is actually made of. This article builds that model step by step, then applies it to the claim.
1. Development cost = defining quality + producing conformance
Start with Philip Crosby's definition from Quality Is Free (1979): quality is conformance to requirements.
If you accept that definition, a chain follows:
- Quality means conforming to requirements.
- So writing requirements is defining quality.
- Development means building something that conforms to those requirements.
- So every piece of development work is either defining quality or producing something that conforms to that definition.
This is not the usual view. In the classic Cost of Quality model (Feigenbaum's Prevention / Appraisal / Failure), quality cost is one slice of total cost, and the rest is "just production." Here, quality is not a slice. It is the axis the entire cost is split along.
A layer above: deciding how to define quality
Defining quality is not always a single step. When requirements are uncertain, you have to choose a process for discovering them: prototypes, beta releases, staged rollouts. This is old wisdom. Boehm's spiral model is a risk-driven meta-process: in each cycle, you assess risk and pick the process that fits.
That gives three layers:
| Layer | What it does |
|---|---|
| 1. Process decision | Decide how to define quality (explore or commit?) |
| 2. Quality definition | Define quality, including exploration when needed |
| 3. Conformance production | Build something that conforms to the definition |
Two consequences:
- Exploration costs belong to the definition side. A throwaway prototype looks like "building," but its purpose is to settle the definition. A beta release goes further: it partly outsources defining quality to users.
- You can only plan exploration for known unknowns. If you know you don't know, you can budget for a prototype. Unknown unknowns show up later, as rework. So the process layer needs two things: an upfront judgment and a way to detect mid-course that the definition is breaking.
Where does verification go?
Checking that the product conforms to the definition belongs on the product side. Conformance isn't established by building alone. It is established when it is confirmed. A product is really artifact + evidence of conformance.
But "checking" needs to be split, and Boehm's V&V distinction does it cleanly:
- Verification: Are we building the product right? (Does it match the definition?)
- Validation: Are we building the right product? (Is the definition itself right?)
| Activity | Question it answers | Side |
|---|---|---|
| Designing acceptance criteria | What counts as quality? | Definition |
| Running verification | Does it conform? | Product |
| Validation (prototype/beta evaluation) | Is the definition right? | Definition |
The same act of "testing" lands on different sides depending on what it is testing against.
This matters for AI. If acceptance criteria are vague, whoever runs the check has to interpret them on the spot. That means definition work is leaking into the product side. When an AI runs the check, the AI can end up defining quality without anyone noticing. That makes the assumptions it introduces a first-class engineering concern: they need to be made explicit, reviewable, and traceable.
2. Definition and product make each other testable
My first instinct with this model was to say: "Fine, so value moves from the artifact to the definition." That is also one-sided. Here is why.
- Whether the product is right (verification) can't be judged without the definition.
- Whether the definition is right (validation) can't be judged without a product. You have to run it.
- So the definition makes the product evaluable, and the product makes the definition testable.
- Neither one has a basis for claiming correctness on its own.
- So value lives in the relationship between definition and product, not in either side by itself.
This is exactly why prototyping exists. If definitions could be validated without products, nobody would build throwaway prototypes.
There's a second kind of product value: provability. Two products with identical features are not equal if only one of them can repeatedly demonstrate which definition it conforms to (through traceable criteria, tests, observability). In the AI era this gap widens:
- AI produces code in large volumes, cheaply.
- The more code there is, the harder it is to tell which code is correct.
- So what becomes scarce is not code but proof of correctness.
Running the checks can be delegated to AI. What holds value is the structure that ties criteria to the product so the proof can be reproduced at any time.
3. The hidden premise: "we can build the successor ourselves"
Now look at what a one-sided value claim actually implies.
- "Only the definition has value" assumes the product can be cheaply regenerated from the definition.
- "Only the product has value" assumes the definition can be read off the existing product.
Either way, the missing half is assumed to be cheaply reproducible. Put that premise into practice and it means: we can build the successor to this existing product ourselves.
That premise fails on both sides:
- Definition → product: the new product has to prove the definition all over again. The operational track record of the old product doesn't transfer.
- Product → definition: in long-lived systems, much of the definition is implicit, buried in code as edge-case handling and fixes from past incidents. Observation recovers what is visible. The rest leaks out as unknown unknowns.
So building a successor means paying twice over: once to re-acquire the definition, and again to re-prove it. That gives a rough way to measure an existing product's value:
Value of an existing product ≈ the cost of re-acquiring its definition + the cost of re-proving it
AI lowers the cost of conformance production. It barely touches those two terms. None of this is new: Joel Spolsky's "Things You Should Never Do" (2000), written about Netscape's full rewrite, made the same point. Old code quietly accumulates bug fixes and knowledge.
A stress test: Linux and Windows
Could you say "we have the definition, so Linux or Windows is worthless"?
The definitions exist: POSIX, the Single UNIX Specification, Win32 API docs, the Linux syscall ABI. Yet reimplementations from those definitions have taken decades and remain partial (Wine, ReactOS). The strongest case is Microsoft itself. WSL1 (2016) reimplemented Linux syscalls on top of the NT kernel. WSL2 (announced 2019) switched to running a real Linux kernel in a VM. An organization with enormous resources tried "build from the definition" and chose "use the actual product" instead.
The reason is Hyrum's Law: with enough users, every observable behavior of your system will be depended on by somebody, whatever the spec says. Follow that through:
- Users come to depend on behaviors beyond the documented spec.
- Those behaviors become part of the de facto quality definition.
- For an OS with a huge user base, the definition expands to cover almost all observable behavior.
- The only complete record of that behavior is the product itself.
- Definition and product become inseparable.
You can see this in practice. Linux's "we don't break userspace" rule protects behavior that apps depend on even when the spec says otherwise. Windows ships large numbers of per-application compatibility shims.
Successor vs. replacement
"But Linux replaced Unix!" It did, but that doesn't count as a counterexample. Linux didn't reproduce any particular Unix's full behavior. It adopted a narrower standard, made its own decisions, and users migrated to it. That is a new quality definition, not a successor.
| Successor | Replacement | |
|---|---|---|
| Quality definition | Same as before | New |
| Behaviors outside the new definition | Must all be reproduced | Dropped |
| Cost of what's dropped | — | Paid by users as migration cost |
Replacement is new development: it restarts from the process layer. And a successful replacement doesn't prove the old product was worthless. It proves someone paid to give up part of the old definition.
The "we'll just rebuild the SaaS in-house with AI" stories usually fit here. When they succeed, it is typically because the team narrowed the definition to their own needs. That can be a perfectly rational choice. But the reason it works is the narrower definition, not that the original product had no value.
4. Quality stabilizes with stakeholders, and stable quality has no cost-free substitute
Why is a widely used product so hard to replace? Two mechanisms run together.
The definition gets pinned down:
- Each stakeholder depends on some behaviors (Hyrum's Law).
- Each dependency becomes a constraint on the definition.
- Changing a behavior affects someone who depends on it.
- The more stakeholders there are, the fewer changes are harmless to everyone.
- So the definition becomes fixed.
The proof piles up:
- Every real use is one more validation: "this definition works here."
- More stakeholders means validation under more varied conditions.
- So the evidence that the definition is right grows thicker.
"Stable quality" means both at once: harder to change, and better proven.
And under the same quality definition, stable quality has no cost-free substitute:
- Stable quality means every stakeholder's dependencies are satisfied at the same time.
- That set of dependencies was formed by history: who used it, when, and how.
- A substitute would need to satisfy the same set and earn the same proof.
- Earning that proof requires the same stakeholders to use the new product.
- That is migration, which is replacement, which is a new definition.
- So obtaining the same quality from a different product means paying again for migration, verification, validation, and renewed operational proof.
The mechanism is real enough that engineers design against it. Protocol ossification froze parts of TCP because middleboxes depended on header values. QUIC encrypts most of its headers, and TLS's GREASE mechanism (RFC 8701) sends deliberately random values so that nobody can depend on "this value never appears." These designs assume stakeholder dependency will lock quality in place, and try to control it.
That also shows the cost: stable doesn't mean correct. It means immovable. Hard-to-replace quality is also quality you can't easily change.
This gives the "value goes to zero" claim a gradient:
| Stakeholders | Definition lock-in & proof | Cost to rebuild |
|---|---|---|
| Few (internal tools) | Weak | Low: re-agreeing the definition is cheap |
| Many (OSes, infrastructure, industry standards) | Strong | Very high: requires migration and renewed proof |
The claim is most wrong exactly where the most people depend on the product.
5. Not just software: social contracts work the same way
This isn't specific to code. Documented agreements such as laws, contracts, and standards follow the same pattern:
- The document is the quality definition.
- How society operates under it (transactions, disputes, rulings) is the product that proves it.
When a document is first written, three kinds of defects remain, and usage surfaces and removes each one:
| Defect | How it surfaces | How it's resolved |
|---|---|---|
| Gaps | A situation the text didn't anticipate | Case law, supplementary rules, amendments |
| Ambiguity | Parties read the text differently and dispute it | Rulings and official interpretations |
| Redundancy | Provisions overlap or conflict | Precedence rules, consolidation, removal |
Some examples:
- Japan's Civil Code was enacted in 1896. Its law of obligations ran for about 120 years without a major overhaul, with gaps and ambiguities filled by case law. The 2017 reform (effective 2020) largely wrote that accumulated interpretation back into the text.
- The ISDA Master Agreement is used across the derivatives market. Decades of disputes and rulings have settled what its clauses mean. Firms use it not just for its wording but because outcomes are predictable.
- IETF RFCs accumulate errata and get obsoleted by revisions. RFC 2119 exists purely to remove ambiguity from MUST / SHOULD / MAY.
The same conclusions hold. The real definition is the text plus the accumulated interpretation, so the text alone can't reproduce it. That's one reason international contracts so often choose English law or New York law: a newer, better-written law can't offer the same predictability until it has gone through the same volume of disputes.
One caveat: removing defects never finishes. New technology creates new gaps, accumulated interpretation creates its own redundancy, and stability turns into rigidity. Defects shrink over time only while the environment stays fairly stable.
6. So what actually changed with AI?
Here's the part I think most people miss.
What writing code used to do
Because writing code was slow and expensive, two things were hidden:
- Definition costs were buried inside production. Most of the budget looked like building.
- Writing code doubled as definition discovery. As developers wrote, they hit questions ("what happens in this case?"), found gaps and ambiguities, and went back to stakeholders. The slowness of writing was, in effect, the time and the checkpoints for settling the definition.
What AI changed
- Conformance production got cheap. This change is real.
- Exploration got cheap. Prototypes can be built quickly and repeatedly, so definitions can be tested against products more often. This change is also real.
- The definition-discovery time disappeared. This is the one people overlook. When writing time vanishes, the "hit a gap and ask" loop vanishes with it. The AI fills gaps and ambiguities with its own guesses, and it can define quality silently.
What AI did not change
- Defining quality still requires agreement among stakeholders.
- Validation still requires stakeholders to use the product.
- Stabilization still requires many stakeholders and time. AI cannot compress stakeholders' time.
Why this isn't like past productivity gains
High-level languages, frameworks, libraries, and open source all cut the cost of writing code too. But they worked differently:
| Libraries / frameworks / OSS | AI code generation | |
|---|---|---|
| Why cost drops | Reuse of quality stabilized by many other stakeholders | Fresh code generated per request |
| Proof | Inherits a track record | Starts from zero |
| Net effect | More of your system is proven | More of your system is unproven |
Following that through:
- Using a library meant borrowing quality that many stakeholders had already stabilized.
- So writing less code also meant having more proven code.
- AI-generated code is new on the spot. It has no stabilization history.
- So AI lowers the cost of writing while increasing the volume of unproven product.
- Proving correctness becomes a bigger share of the work, not a smaller one.
On the surface it looks like the next step in a long trend. Underneath, it runs in the opposite direction.
Three common misreadings
"Development time will shrink in proportion to coding time."
Even if AI accelerates several production activities, total speedup is still bounded by the work that remains serial and human-dependent: agreement, validation, migration, and stabilization. This is the relevant Amdahl's Law effect. And because the old definition-discovery loop no longer happens automatically while developers write code, some of the saved production time has to be reinvested deliberately in definition work.
"Artifacts are worth zero."
Value lives in the definition–product relationship, and stable quality has no cost-free substitute.
"We can easily rewrite legacy systems with AI."
A successor requires re-acquiring and re-proving the definition. Most "successful rewrites" are replacements with a narrower definition.
Summary
- Development cost splits into three layers: deciding the process, defining quality, and producing conformance. Verification belongs to production. Validation belongs to definition.
- Definition and product make each other testable. Neither is sufficient on its own. Provability becomes scarcer as AI produces more code.
- Claiming only one side has value hides the premise "we can build the successor ourselves". Its real cost is re-acquiring and re-proving the definition.
- A successor keeps the definition. A replacement creates a new one. A successful replacement doesn't show the original was worthless.
- Quality stabilizes with stakeholders and time, and under the same quality definition it has no cost-free substitute. The same holds for laws, contracts, and standards.
- AI made conformance production and exploration cheap. It also removed the definition-discovery that writing code used to provide, and unlike libraries, it adds unproven code. The ceiling on speed is set by definition, validation, and stabilization, which AI can't compress.
What approaches zero is the marginal cost of generating another candidate implementation from an explicit, already-proven definition. What does not approach zero is the cost of establishing that the definition is right, proving that the implementation conforms to it, or accumulating enough real-world evidence to trust its behavior. The product that helped validate the definition, and the product that can repeatedly demonstrate its own conformance, retain value.
A question for discussion
If code generation keeps getting cheaper, which part of software development becomes the real bottleneck: defining quality, proving conformance, or accumulating operational trust? And how should engineering processes change if the scarce resource is no longer implementation itself?
Top comments (0)