Code as Liability

Overview

Section 1 described the job as it has existed for decades. This section is about what has changed — and it starts with a shift in what makes an engineer valuable.

Code used to be the asset

For most of software’s history, code was expensive to produce. Writing it was slow, so having more of it meant having more value. Companies counted lines of code and headcount, and both were reasonable proxies for capability.

When generating code becomes fast and cheap, that logic weakens. The bottleneck moves somewhere else.

Code starts to look like what it always actually cost: something to be reviewed, maintained, secured, understood by the next person, kept compatible, and eventually deleted. Every line is a small ongoing obligation.

That’s Code as Liability. Not “code is bad” — but the ability to produce it is no longer the scarce thing.

What this does to the work

When writing was the bottleneck — the effort sat in the middle:

graph LR
  B1["Decide what<br/>to build"] --> B2["Write it"] --> B3["Review"]

  classDef effort fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef cheap fill:#7C7C7C,stroke:#5E5E5E,stroke-width:2px,color:#ffffff
  class B2 effort
  class B1,B3 cheap

When writing is cheap — it moved to both ends:

graph LR
  A1["Decide what<br/>to build"] --> A2["Generate"] --> A3["Verify and<br/>integrate"]
  A3 -->|"found a problem"| A2

  classDef effort fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef cheap fill:#7C7C7C,stroke:#5E5E5E,stroke-width:2px,color:#ffffff
  class A1,A3 effort
  class A2 cheap

Where the effort sits, before and after. The amber boxes are where the scarce judgment lives — one in the middle becomes two at the ends, and the step that was hardest is now the grey one.

Two things get harder, and neither is writing.

Deciding what to build. If producing an option is cheap, you’ll be offered more options, faster, than you can evaluate. Choosing well matters more when choosing badly is cheap to act on.

Verifying the result. Reading a design or an implementation and finding the logic error, the missed constraint, the plausible-looking thing that fails under load — this is genuinely harder than writing, and it gets much less credit. It’s also increasingly the job.

The uncomfortable part

Reviewing is worse work than writing, for most people. Writing has flow; reviewing has vigilance. Writing produces something you can point at; reviewing produces the absence of a problem nobody will ever see.

And the failure mode of review is specific and dangerous: “it looks right.” Generated output is fluent by construction. Fluency reads as correctness. The error you’re looking for is usually not a syntax mistake — it’s a confident, well-formed answer that’s wrong about something you’d have to know the domain to catch.

Which is the thread picked up two topics from now.

Where the constraint actually is

Lintel has 140 engineers, no spare capacity, and a two-year-old migration consuming all of it. The constraint on shipping is not typing speed and never was.

It’s the review queue, the coordination between teams, the fact that Ivan Petrov is the only person who genuinely understands the monolith’s billing path, and the caution left over from 2023. Making code generation faster at Lintel would move almost nothing, because writing code was not the bottleneck.

Noticing where the actual constraint is — rather than where the exciting tooling is — is an architectural judgment, and this is exactly the kind of decision the chain in Why the job exists is for.

A caveat worth keeping

Treat this as a strong thesis, not settled fact. It’s a claim about a trend still unfolding, and reasonable people disagree about how far it goes. Module 10 returns to it properly, with the career consequences.

What’s safe to say now: skill that consists of producing code faster is depreciating; skill that consists of deciding what’s worth building, and judging whether the result is right, is appreciating.

Check your understanding

1. What is the actual constraint on shipping in your organisation? Name it specifically — and check whether faster code generation would move it.
2. Think of a recent review where something got through. Was it a syntax-level problem or a domain-level one?
3. If generating a design is cheap, what stops a team producing more designs than anyone can evaluate?

---

→ Verification is the scarce skill. But verifying what, exactly, when the thing you’re checking behaves differently each time you run it? — Probabilistic architecture