Module 7: Start Here

Overview

Module 6 made the system measurable. This module makes it deliberate — and then turns the lens around.

How do you engineer against uncertainty, and how does AI change what you do all day?

Two threads converge here, and they are less unrelated than they look.

The first is that probabilistic systems need explicit uncertainty policies or they decay into unpredictability. Retries, fallbacks, degradation, confidence thresholds — every one of them is a decision, and every one of them gets made by default if you do not make it on purpose. Module 1 said decide the failure path first; this module is where that becomes a specification.

The second is more personal. As generation gets cheap, the scarce skill shifts from producing a design to validating one. That changes what an architect does on a Tuesday, and it is worth confronting while you still have a choice about how you do it.

How the module is built

Two sections. The first is engineering; the second is antipatterns and your own practice. This module closes Part 3.

graph TD
  subgraph S1["Section 1 — Engineering against uncertainty"]
    A["1 · Measure before<br/>optimising"]
    B["2 · Optimisation<br/>techniques"]
    C["3 · Retry semantics"]
    D["4 · Fallback and<br/>degradation"]
    E["5 · Confidence as<br/>control flow"]
    F["6 · Hybrid<br/>architectures"]
    A --> B --> C --> D --> E --> F
  end
  subgraph S2["Section 2 — Antipatterns and your own work"]
    G["7 · Hallucination<br/>amplification"]
    H["8 · Context overflow and<br/>silent truncation"]
    I["9 · Antipatterns<br/>of omission"]
    J["10 · The 'just add<br/>RAG' reflex"]
    K["11 · AI as design<br/>opponent"]
    L["12 · From creation<br/>to review"]
    G --> H --> I --> J --> K --> L
  end
  F ==> G
  L ==> M(["Workbook — Exercise 7"])

  classDef s1 fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef s2 fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef cap fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A,B,C,D,E,F s1
  class G,H,I,J,K,L s2
  class M cap

The module’s path. Section 1 specifies what the system does when it is unsure; Section 2 is about the failures you build by omission, and about your own judgement as the thing being tested.

Section 1 — Engineering against uncertainty

1. Measure before optimisingWhy profiling matters more when the system's own path varies.

2. Optimisation techniquesThe catalog, each entry with the quality it spends.

3. Retry semanticsA retried credit is a second credit — and sometimes you cannot tell whether it happened.

4. Fallback and degradationDesigning the failure path first, and specifying what the user actually sees.

5. Confidence as control flowThresholds as structure, and why self-reported certainty is not a probability.

6. Hybrid architecturesWhy the strongest AI architectures contain the least AI.

Section 2 — Antipatterns and your own work

7. Hallucination amplificationWhat happens when model output becomes model input.

8. Context overflow and silent truncationThe failure that produces no error and no signal.

9. Antipatterns of omissionThe eval-free deployment, the unbounded agent, the cost spiral.

10. The 'just add RAG' reflexReaching for retrieval before anyone has said what is broken.

11. AI as design opponentRed-teaming your own architecture, recovering lost decisions, reading unfamiliar systems.

12. From creation to reviewThe scarce skill, the failure mode, and what it means for your week.

How to work this module

About six hours, split evenly:

1. Read the twelve topics — about 3 hours.

2. Optional — Workbook exercise 7 — about 3 hours. One artifact asks you to find real faults in your own Modules 4–6 design, and another asks you to have a model attack it.

In the workbook

Four artifacts for Lintel:

• An optimisation plan with expected cost and latency impact per lever
• An uncertainty policy specifying retry, fallback, degradation and confidence behaviour for every agent action
• An antipattern review of your own Modules 4–6 design, honestly conducted
• An AI-assisted red-team — run your design through a model instructed to attack it, and record what it found that you missed

The last two are unusual and deliberately uncomfortable. They are also the two most likely to change your design.

Before you start

You need your Modules 4, 5 and 6 artifacts. Two of the four workbook artifacts are reviews of them. If you have been reading rather than building, at minimum write down the stack choice, the action boundary and the eval plan — you cannot red-team an architecture you have not committed to.

Check your understanding

Answer now, revisit at the end.

1. A write action times out. You do not know whether it happened. What does your system do?
2. Name a place in a design you have shipped where a deterministic check could have replaced a model call.
3. When you last reviewed a generated design, what did you actually check — and what did you assume?

→ Start with Measure before optimising.