Judgment in the AI Era
The capstone path. When code is cheap to produce, value moves to deciding what is correct and proving it: specify intent, draw the boundaries, then verify, operate, and learn.
- Depth
- Deep
- Steps
- 10 existing graph entries
- 1
Verification Over Authorship
The durable difficulty in software was never typing the code; it was deciding what the code should do and establishing that it actually does it. Producing an implementation is the cheap, fast part; specifying intent precisely and verifying correctness is the scarce, hard, last...
Start from the thesis: authoring code was never the hard part; specifying intent and verifying correctness is the scarce, durable work.
Related within this path
- References: Automated Testing
- References: Design by Contract
- References: Fitness Functions
- References: Observability
- 2
Ubiquitous Language
A shared, rigorous language for a single model of the domain, used identically by developers and domain experts in conversation, documents, and the code itself. The terms, relationships, and rules of the model become the vocabulary the team speaks. If a word is ambiguous or mi...
Specify intent precisely: one rigorous shared language for the domain, so what "correct" means is unambiguous.
- 3
Bounded Context
An explicit boundary within which a single domain model applies and its terms have one precise meaning. Outside the boundary the same word may mean something different, modeled differently. Bounded contexts make the limits of a model deliberate: each context owns its model and...
Decide where boundaries belong, so each model stays consistent and change stays contained.
Related within this path
- Related To: Trust Boundary
- 4
Trust Boundary
A line in a system where the level of trust changes, so anything crossing it must be validated, authenticated, or authorized rather than assumed safe. Inside a boundary, components trust each other; data and requests arriving from outside are treated as potentially hostile unt...
Mark where trust changes, so you know exactly where input must be validated.
Related within this path
- Related To: Bounded Context
- Related To: Design by Contract
- 5
Design by Contract
Specify the rights and obligations of a piece of code explicitly as a contract: preconditions the caller must satisfy, postconditions the routine guarantees in return, and invariants that always hold. The contract makes assumptions a stated, checkable part of the interface. Mo...
Make expectations explicit and checkable at the interface, rather than assumed.
Related within this path
- References: Verification Over Authorship
- Related To: Automated Testing
- Related To: Trust Boundary
- 6
Automated Testing
Automated testing is the practice of encoding expected behavior as checks a machine runs, so that whether the system still works is answered by running the suite rather than by inspection or hope. Self testing code, where a fast, trustworthy suite accompanies the code, is the...
Establish that behavior is preserved by running checks, not by inspection or hope.
Related within this path
- References: Verification Over Authorship
- Related To: Design by Contract
- 7
Fitness Functions
An objective, usually automated, test that measures whether an architecture characteristic is being maintained as the system changes: performance budgets, dependency rules, security checks, coupling limits. Borrowed from evolutionary computing, a fitness function scores how cl...
Keep the architecture honest over time with automated, objective checks on its qualities.
Related within this path
- References: Verification Over Authorship
- 8
Observability
Observability is the degree to which a system's internal health can be inferred from what it emits: metrics, logs, and traces. You cannot operate, debug, or improve what you cannot see. The practical core is to instrument for a small set of user centric signals (latency, traff...
Verify behavior where it actually runs, in production, not only in theory.
Related within this path
- References: Verification Over Authorship
- 9
Blameless Postmortem
A blameless postmortem is a written, after the fact analysis of an incident that assumes everyone acted with good intent given what they knew at the time, and that looks for the systemic and latent causes that let the failure happen rather than for a person to fault. The outpu...
When it fails anyway, turn the failure into learning fed back into the system.
- 10
Judgment Is Bounded
Human judgment runs on limited information and fast, automatic heuristics, producing errors that are systematic and predictable rather than random. Robust systems and decisions are designed to account for bounded, biased judgment instead of assuming rational actors. Bounded Ra...
Close on the humility the whole path requires: the human judgment doing all this verifying is itself systematically bounded.