Chapter 11. Construction When Code Is Cheap

Learning objectives

After this chapter you should be able to:

Explain how pair programming, code ownership and the author's walkthrough each depend on someone understanding the code.
State the load-bearing assumption of classical construction, and say why the activity inverts while its authorship-based practices break.
Summarize the evidence on what agents change about comprehension, separating measurement from statements of practice.
Decompose a change into agent-sized tasks, count the steering each costs, write a context budget, and apply a reading protocol to generated code.
Write characterization tests for inherited code, and use them to choose between a hand merge and agent-native rework.
State what evidence would flip the verdict.

Opening case

A composite case, not a real engagement.

Nadia joins a logistics company's engineering group in the spring. Her first assignment is to extend Dispatch, the internal dispatch dashboard from Chapter 6, which a consultant built three months earlier with coding agents and which now runs in production. The consultant has moved on. The handoff note is one page, the repository holds about 6,000 lines of Java, and every test passes.

The chapter continues from here.

What the chapter covers

11.1 The classical method
- 11.1.1 Construction manages complexity
- 11.1.2 The author understands
- 11.1.3 Practices that spread the understanding
- 11.1.4 Legacy code and characterization tests
- 11.1.5 What it got right
11.2 The assumption it depends on
11.3 What agents change
- 11.3.1 What the evidence says
- 11.3.2 What construction becomes
- 11.3.3 Parallel agents and the merge
11.4 The verdict
11.5 What replaces it: decomposition, context and reading
- 11.5.1 The decomposition rule
- 11.5.2 The context budget
- 11.5.3 A reading protocol for generated code
- 11.5.4 Characterization tests before changing inherited code
- 11.5.5 When to hand-write code
- 11.5.6 Worked example: batch reassignment in two parallel worktrees
11.6 Lab: Construction in an inherited repository
11.7 What would make this verdict false

Lab and prediction

Lab: Construction in an inherited repository

Feeds milestone M5. How the labs fit the project

The lab tests this prediction from the working paper the book grows from (Smith 2026a):

P1 Share of human hours on review and verification exceeds the share on construction from the first milestone on

This chapter's own prediction: Comprehension plus review hours exceed prompting hours; agent-native rework leaves fewer defects than a hand edit on a semantic conflict, at a higher review time.

A result that contradicts a prediction, honestly reported, is a result. You are graded on accurate records and reasoned interpretation, not on agreeing with the book.

Summary

Load-bearing assumption: code is scarce; its author understands it. Verdict: inverts. Construction used to turn understanding into code and now has to turn code into understanding. Its authorship-based practices break; complexity management, defensive programming and characterization tests survive.
Evidence: the clearest randomized study I found reported lower quiz scores with AI assistance; no study measures comprehension of inherited, agent-written code.
Replacement: tasks of one session, one reviewable change and one acceptance check, as large as those conditions allow because each task costs steering; a context budget; reading the interface, tests and behavior diff first; characterization tests before changing inherited code; hand-writing small, critical and boundary-defining code.
Parallel work: predict conflicts from declared files and behaviors, merge one stream at a time, and choose a hand merge or agent-native rework by the kind of conflict.
Construction hours are an accounting category, not a success measure. The verdict flips if understanding becomes cheap or code becomes scarce again.

Key terms

Managing complexity: McConnell's primary technical imperative: organizing a program so that a person can focus on one part at a time.
Defensive programming: writing code to protect itself from invalid inputs and its own errors, through validation, assertions and barricades.
Legacy code: in Feathers's sense, code without tests.
Characterization test: a test that pins what code currently does, without claiming it is correct.
Agent-sized task: a task satisfying one agent session, one reviewable change and one acceptance check.
Context budget: a written allocation of an agent's working space for a task into fixed, task and headroom parts.
Predict-then-run: writing down the expected behavior diff before running the tests, so a wrong guess measures a comprehension gap.
Agent-native rework: resolving a conflict by re-running the second change's mission against the merged code, so the agent writes a fresh implementation, instead of editing by hand (Hassan 2026, §6.4.5, p. 193).

Connections

Where this chapter and another point to each other most often.

Chapter 2: The Assumption Audit: A Method That Outlasts the Tools
Fagan's inspection (1976) uses the same premise: the author walks reviewers through the code and answers questions (Section 2.3).
Chapter 6: Cost and Schedule Estimation After COCOMO
Her first assignment is to extend Dispatch, the internal dispatch dashboard from Chapter 6, which a consultant built three months earlier with coding agents and which now runs in production.
Chapter 12: Reviews: Inspecting Evidence, Not Diffs
Ownership survives as accountability, not comprehension (Chapter 16, condition 4), and pairing survives as a second reader who checks (Chapter 12).
Chapter 13: Testing, Evaluation, and Tests as Steering
Defensive programming survives if its assertions come from the specification, not the agent's guess at intent (Chapter 13).
Chapter 16: Roles and the Four Conditions for Assurance
Ownership survives as accountability, not comprehension (Chapter 16, condition 4), and pairing survives as a second reader who checks (Chapter 12).
Chapter 18: Running the Whole Life Cycle: The Engineer as Manager of an Agent Team
Commit the suite as the as-received baseline (Chapters 14 and 18).

See it on the map

11 Construction When Code Is Cheap