Code as Liability, Followed Through

Overview

Module 1 opened with a claim that sounded contrarian: code is not an asset but a liability. Every line must be understood, maintained, secured, migrated and eventually removed, and the value lives in the capability it provides rather than in the lines themselves.

Nine modules later, with generation nearly free, that claim stops being contrarian and becomes load-bearing. This topic follows it to its conclusions — including two that are uncomfortable.

The conclusion people skip

If code is a liability, and producing it is now cheap, then the correct response is not to produce more of it.

This is obvious when stated and almost universally ignored in practice, because cheapness feels like permission. The actual logic runs the other way. The cost of code was never concentrated in typing it:

• It must be read — repeatedly, by people who did not write it, for as long as it exists.
• It must be understood well enough to change safely, which is strictly harder than reading.
• It must be secured, patched and migrated as its dependencies move underneath it.
• It must eventually be removed, which requires knowing what depends on it.

None of those costs fell. Only the first, smallest one did. So the economics of a codebase got worse relative to its production cost, which means the optimal quantity of code went down while the price of producing it went down too — a genuinely counterintuitive pair that explains most of what goes wrong with enthusiastic adoption.

graph LR
  A["<b>Writing</b><br/>now near-free"] --> B["<b>Reading</b><br/>unchanged"]
  B --> C["<b>Understanding<br/>well enough to change</b><br/>unchanged"]
  C --> D["<b>Securing, migrating,<br/>removing</b><br/>unchanged"]

  classDef free fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef same fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A free
  class B,C,D same

One of four costs collapsed. The three that did not are the ones that recur for the life of the system.

What this makes the architect’s job

Three consequences, each a shift in emphasis rather than a new activity:

Constraining how much exists. When the marginal cost of a new service, a new abstraction or a new integration approaches zero, the thing standing between an organisation and an unmaintainable estate is a deliberate decision not to add. That is an architectural function, and it is newly load-bearing.

Making deletion routine. If code is liability, removing it is value, and it is the only engineering activity that reduces total cost with certainty. Section 1’s reclassification of abandoned code as a deletion rather than a debt item is an instance: small, unglamorous, strictly positive.

Protecting comprehensibility as a requirement. A system nobody understands is pure liability, whatever it does. This is why the HLD must be readable by an outsider and why decision records exist — both are investments in a property that generation does not provide and actively erodes.

The two uncomfortable parts

It applies to your own artifacts. Documents are liabilities on the same terms: they must be read, maintained, and eventually removed, and a wrong one costs more than none. Module 9 made exactly this argument about the HLD — an un-revised description is worse than no description — and the discipline of a small artifact set with named owners follows from it. An architect who responds to cheap generation by producing more documentation has made the same error as a team that responds by producing more code.

And it limits the value of what you build. Section 2’s buy-versus-build conclusion is this thesis applied to assets: if code is liability and capability is commoditising, then the durable value sits in things that are not code at all — the evaluation set, the document corpus, the measured facts about your own traffic, the list of what the system may do. That is an uncomfortable conclusion for people who became architects because they liked building systems. It is also the reason the unglamorous artifacts from Modules 4 through 6 are the ones that still matter after a model generation turns over.

What is actually worth having, three years on

A thought experiment on the guide’s output: assume two model generations have passed and the inference layer has been replaced twice. What retains value?

What does not. The orchestration code, substantially — rewritten or replaced, and that is fine, because it was always the cheap part. The specific prompts, tuned against a model that no longer exists. The confidence thresholds, which were calibrated empirically against one model’s behaviour. The retrieval implementation, superseded by whatever the vendors ship next.

Each of those was real engineering and none of it is a loss. They were liabilities carrying capability, and the capability arrived.

What retains full value. The evaluation set — about 300 cases drawn from nine years of support history, with the repetition count corrected by Module 6’s noise-floor arithmetic. It is the instrument that makes every future model swap a measurement rather than a leap, and it cannot be bought because it encodes this company’s actual traffic.

The tiered action list, with its approval requirements — and the correction that credits are two processes rather than one, which the Module 9 design session found and Section 2’s characterization work independently confirmed. That is domain knowledge, not code.

The documented reasoning: why two services, why hosted in-region inference, why retrieval over fine-tuning, and the four-year dependency finding that superseded the original record. A new architect reading those fifteen records understands the system’s shape in an afternoon.

And the corpus work — the measured finding that the deflectable share is a property of the documentation rather than of the technique, which redirected the entire initiative from an engineering problem to a documentation investment.

The uncomfortable tally. The parts that felt like architecture — the service split, the agent bounds, the degradation ladder — are mostly expressed in code that will be replaced. The parts that endure are a test set, a list, and a folder of explanations. Anyone who measured their contribution by the system they built would conclude they had achieved little; measured by the decisions recorded and the instruments left behind, the same work looks different.

Feeds the workbook

This shapes how you present the portfolio. The artifacts that read as durable to a hiring manager or a leadership team are the reasoning and the instruments, not the volume of design produced.

Check your understanding

1. Which of the four costs of code dominates in a system you know? What would halving the writing cost change about it?
2. What have you deleted recently? What stopped you deleting more?
3. Of your own last year’s output, what would still have value after two model generations?

---

→ If that is where the value sits, the skills that reach it are not the ones most people are building. — The shifting competency profile