Threat and Opportunity

Overview

Two bad answers dominate this subject. One says the work is unaffected because judgement is human. The other says the work is nearly over. Both are comfortable, and neither survives contact with what the preceding modules actually involved.

The useful question is narrower and answerable: which specific activities get cheaper, and what happens to the value of the activities around them?

What genuinely gets displaced

Not whole roles — activities. Four of them, and they are a real part of the job:

Drafting. Producing a first version of a design document, a comparison table, a diagram, a decision record. This is now minutes of work rather than hours, and the quality of the draft is often adequate.

Synthesis of known material. Summarising how a pattern works, enumerating the standard options for a problem, explaining what a technology does. Anything whose answer exists in the accumulated literature is now immediately available, and the person who held it in their head no longer has an advantage from holding it.

Breadth of recall. Knowing the catalogue — which queue, which database, which framework, and what each is suited to. This was genuinely valuable and is now close to free.

Mechanical exhaustiveness. Tracing every call site, enumerating every case, checking a document against a checklist. Not displaced so much as improved, since patience is where humans were weakest.

That list is a substantial share of what many people thought the job was. Pretending otherwise is the reassurance answer, and it leaves people unprepared.

What becomes scarcer

The other half, and the reason the role does not simply shrink:

Judgement under constraints that are not written down. Every module in this guide turned on constraints that existed nowhere in a document — no spare capacity, a principal engineer with an informal veto, an organisation with a quiet aversion to recording failure. A model given the written requirements produces a clean design that violates the unwritten ones, and nothing in its output signals the omission.

Knowing which question to ask. Generation answers the question posed. The expensive errors in this guide were all cases where the obvious question was the wrong one — where the stated target, the plausible threshold or the assumed schedule was itself the problem.

Accountability. Somebody has to be answerable for a decision, and that cannot be delegated to a system. This is not a technical limit but a structural one: accountability is a social arrangement, and it attaches to people.

Verification. The scarce skill, and the next topics make the case that it is where the value has concentrated.

graph TD
  A["<b>Gets cheaper</b><br/>drafting · synthesis ·<br/>recall · exhaustiveness"] --> C["The work<br/>redistributes"]
  B["<b>Gets scarcer</b><br/>unwritten constraints ·<br/>choosing the question ·<br/>accountability · verification"] --> C

  classDef cheap fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef scarce fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef hub fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  class A cheap
  class B scarce
  class C hub

Both columns are real. The mistake is reading either one alone.

Why the scarce half gets more valuable, not just relatively

The non-obvious part. If candidates are cheap and evaluation is not, evaluation becomes the constraint on the whole system — and the constraint on a system is where its value concentrates.

Module 9’s capacity arithmetic showed this concretely: cheap generation did not produce better designs so much as more of them, and the review capacity that was comfortable became the binding limit without headcount changing at all. That is the same mechanism arriving at an individual scale. The person who can tell a sound design from a plausible one is worth more when plausible designs are abundant, not less.

The honest residual

Two things this reading does not resolve.

Junior entry gets harder. The displaced activities — drafting, synthesis, recall — are how people traditionally built the judgement that the scarce half requires. If a model does the drafting, the apprenticeship that produced verification skill is weaker, and nobody has a convincing answer for how the next cohort acquires it.

And verification is itself partly automatable. Checking arithmetic, finding missing cases, testing a claim against stated constraints — these are tasks a model can help with, and Module 7 recommended exactly that. The defensible position is not that verification is beyond machines; it is that someone accountable has to decide whether the verification was adequate, and that is a narrower claim than it is comfortable to make.

What this guide would and would not have produced

A concrete test of the two columns, using this guide’s own work.

What a model would have produced well. The first draft of nearly every artifact. The comparison of architectural styles in Module 3. The enumeration of agent failure modes in Module 5. The standard structure of the ADRs in Module 9. The catalogue knowledge throughout — what a vector store does, how a strangler migration works, what Conway’s Law predicts. All of it adequate, much of it good, and all of it faster than a person.

What it would have got wrong, and why. The constraints that governed every decision were unwritten. That there is no spare engineering capacity because the migration consumes it. That Ivan Petrov holds a veto that appears on no org chart. That the 2023 failure was switched off quietly and the absence of a postmortem is itself the cultural finding. That Lena Fischer’s block is formal and real. A design produced from the stated requirements alone would be clean, correct-looking, and unbuildable here — and it would read as confident throughout.

And the specific errors it would have carried forward. Every substantive correction in this guide was an arithmetic or constraint check applied to a number that looked reasonable: that deflecting 38% of roughly 12,000 tickets leaves a residual human cost above the blended target; that three delegated stages at 90% land at 73%; that a 3-point regression trigger sits inside the noise band of a 300-case set run once; that a migration 35% complete after two years implies four more years, not one.

Each of those started as a plausible figure in a plausible document. None would have been caught by producing a better design — only by multiplying, dividing, and checking against a constraint.

What this says about the role here. The job at this company is not to produce the design. With the right inputs a model gets most of the way there. The job is to know that the support team is forty-five people across three time zones with a Zendesk history, that the deflectable share is a property of the documentation corpus rather than of the technique, and that any plan asking Tomas Beck for engineers is dead on arrival. That knowledge is not in the repository, and it is what the whole initiative turns on.

Feeds the workbook

This topic shapes your competency gap analysis: score yourself on the scarce column honestly, since the cheap column is no longer where a differentiated ability lives.

→ One thread from Module 1 has been running underneath all of this. — Code as liability, followed through