The Discipline That Saves It

Tessa's next request is a review-trends page: the 2,300 classified reviews from Chapter 8, shown as counts per bucket, per month, per office, so the season can be read at a glance instead of opened as a file.

Milo builds it himself, and he builds it with the assistant doing most of the typing — the top rung, the same tools the junior used, no handicap and no ceremony. It takes him a day and a half. When operations asks for a change in month six, that change will take an afternoon.

The difference between his day and the junior's Thursday is four habits. None of them is exotic, none of them is a programmer's secret, and every one of them is something the careful reader of this book has already been doing to prose since Chapter 3. This page is AI-assisted development, honestly practised, and it turns out to be a chapter you have already read.

Specify itwhat it must do · what must not change

→

The assistant draftsmost of the characters in the file

→

Read it, run the checksline by line · tests every single time

→

Keep it, recordedor say precisely why, and ask again

Read the Change

Milo reads every generated change before he keeps it. Not the whole project every time — the change: the lines that are about to become part of Waymark's software, in front of his eyes, before he says yes.

That is the entire habit, and it is the one that matters most. It is also exactly the posture Tessa takes toward generated prose. She does not send the model's brochure paragraph to a client unread. She reads it, keeps the good parts, cuts the invented ones, and puts her name on the result. The model drafts; the human owns. Chapter 3 called that habit verification and Chapter 5 called it checking the output; here it is again, wearing code's clothes.

Reading is where "plausible" gets separated from "correct" — and in code the gap between those two is invisible from the outside, because both of them run. A page that shows the wrong guest name for group bookings starts up perfectly. The only place that flaw is visible before a guest sees it is in the lines themselves.

What Milo is not doing is reading for style. He is reading for four things: does this do what I asked, does it touch anything I did not intend it to touch, does it handle the cases I know about, and would I be able to explain this to somebody in six months. About a third of what comes back fails one of those and goes back for another round.

Keep the Net

The second habit is tests — small automatic checks that run the software with known inputs and shout if the answer is not what it should be. A test for the booking page would type a group booking's reference and insist the right guest name comes back. It runs in under a second, and it runs every single time anything changes.

Compare that with clicking around. Clicking checked one afternoon, in the places one person thought to click. Tests check every afternoon, forever, in every place anybody ever thought to write down. That is the whole of the difference, and it is why the group-name bug would have been caught before lunch rather than in week three.

Tessa met this idea in Chapter 5 as the gauge: checks with no judgement in them, run over the model's output automatically, catching malformed and out-of-range rows before a human ever looked. Her twenty-line program did exactly that to 2,300 reviews. Tests are that gauge, grown up and pointed at software.

Two honest notes. The assistant is genuinely good at writing tests — describe what must be true and it will produce the checks, quickly, which removes the usual excuse for skipping them. But what must never break is a human decision, and it is the most valuable thing on this page. The assistant does not know that Waymark's group bookings are the fragile case, because that knowledge is Waymark's, not the world's. Chapter 2's rule, still holding: the model knows the general; you supply what only you know.

Small Steps, Versioned

The third habit is two habits that only work together.

Small steps first: one change at a time, finished and checked, before the next one starts. Not an afternoon of thirty rounds fused into a single indistinguishable lump, but a sequence of separate changes, each one small enough to hold in your head while you read it.

Then versions. Each of those steps gets recorded, with a short note saying what it was for. The record keeps every earlier state of the code, so two questions always have answers: put it back the way it was on Friday, and what changed between Friday and Monday. In week three those were the two questions nobody could answer, and the four days were mostly spent not answering them.

Tessa recognizes this immediately, because she has been doing it to text files since Chapter 5. Version four of the review template sits beside versions one, two and three; she can see what she changed after the Harbourview Annex turned up in a spreadsheet cell, and she can go back if version five turns out worse. Software's version history is that habit done properly, by a tool built for it.

The tool of record has a name — a version-control system, a program that stores every recorded state of a project and can bring any of them back — and using one is a genuine skill with a genuine learning curve. It is not this book's subject. It is the subject of a whole other beginner course in this catalogue, Git for Beginners, and anyone who intends to commission or build software should go and take it. That is the honest handoff: this page tells you the habit exists and why it decides outcomes; that course teaches your hands to do it.

Specify Like It's a Prompt, Then Hold the Line

The fourth habit is where the reader will feel most at home, because it is Chapter 2 verbatim.

Milo's task descriptions carry the four specifics: what the change must do, for whom, in what shape, and within what limits. Then one addition that prose rarely needs and code always does — what must not change. Show cancelled bookings differently, and do not touch how references are matched, and do not alter what group bookings display. The absent version of that sentence is the reason two things broke in week three.

And when the result fails his reading, he does what Tessa does with a seventy-percent draft. He says precisely what is wrong and asks for another version — cut this, keep that exactly as it is, the lookup should happen before the formatting. Steering with specifics, in rounds. Chapter 2 taught it as the craft of prompting and it is the same craft here, on the same kind of machine.

What he does not do is accept a change because it is the fourth attempt and everyone is tired. That is the failure mode with a name in this book: iteration without standards, which is just acceptance with extra steps.

Stand back and the whole page collapses into one sentence. Every discipline here is a Chapter 2 to 5 habit transplanted to code — specify, review, check, version, steer. The reader has been practising AI-assisted development on prose for seven chapters. This page only changed the material.

Waymark's office has an extension on the back, built two summers ago by a fast crew. Their neighbour used the same crew and got the same speed. The difference is that Waymark's job had drawings, an inspector who came three times, and a signed sheet listing every change to the plan. Both extensions went up in five weeks. Only one of them can be altered next year by somebody who was not there, which is why the neighbour's new doorway took a fortnight of exploratory demolition.

And there is one more thing Tessa gets out of this page, which is a sentence for a contract. Waymark's next software agreement will say that changes are reviewed by a named person, that automatic tests are kept and run, and that a version history is maintained and handed over. Three phrases. She does not have to understand a line of code for them to work, because agencies that do those things will sign happily and agencies that do not will start explaining.