Follow the Process

This chapter makes a claim that may sound strange after everything so far. We have spent eight chapters moving the human away from implementation detail. Now I am going to argue for preserving something old-fashioned amid all that change: the discipline that keeps work traceable, reviewable, and recoverable — today taking the familiar shape of the git repository, the commit history, branches per unit of work, written notes, and a steady working cadence. Follow the process — even though the machine does the work.

The reason is simple to state and worth unpacking: the process is how work stays legible. To you next week. To a reviewer who must judge it. To a future session that inherits it.

A note on what I am and am not claiming. Branches and commits are excellent mechanisms for achieving traceability today — for parallel agents, branches or work trees are particularly valuable; for a strictly sequential project like this book, a linear history has proved entirely adequate, one commit per reviewed step with its evidence alongside. The requirement is the retained history and the ability to recover, not any particular git ritual. Mechanisms will evolve, as Chapter 08 argues they must. The principle — every meaningful change traceable, reviewable, and recoverable — is what I am asking you to preserve, whatever machinery implements it tomorrow.

The discipline does not retire

Nothing in machine coding removes the need for version control; if anything, it raises the stakes. A human programmer produces code at a pace that allows some informality — the odd uncommitted experiment, the end-of-day mega-commit, the branch that lives forever. Those habits were always sloppy. Under machine coding they become dangerous, because the volume and speed of machine output turns small disorder into archaeological chaos within days. Hundreds of generated files, dozens of sessions, corrections layered on corrections: without the discipline of small, described, committed steps, nobody — human or machine — can reconstruct what happened, let alone judge whether it was correct.

So the rule is blunt: the machine does the work, but no meaningful change escapes the record. Every change traceable to its reason. Every step preserved in a form that can be reviewed. Every state recoverable. Today that usually means a branch with a purpose, small described commits, tests as far as they can go, notes kept as the work proceeds rather than reconstructed afterwards. This is not nostalgia for ceremony. It is the cheapest available defence against a future in which nobody understands the system, including the machine currently editing it.

Why legibility wins

Consider who reads a repository. First, you in three months, trying to remember why a decision was made. Second, a reviewer — human or machine — asked whether a change is safe. Third, the next AI session, which must pick up context it never lived through. Fourth, plausibly, the models themselves: trained disproportionately on public GitHub history, they have seen the branch-commit-review-merge shape orders of magnitude more often than any alternative, and work in that shape is work they parse most reliably.

I am careful about the fourth claim. Nobody outside the model providers knows the full composition of any frontier model’s training data, and I will not assert a measured causal link I cannot verify. What I can defend without qualification is the rest: conventional structure is human-reviewable, recoverable, and navigable by every tool in the ecosystem, where an idiosyncratic dump is none of those. If the machine readability follows from the same shape — and my working experience suggests it does — that is a welcome consequence, not the load-bearing argument. Legibility to people would justify the discipline on its own.

Branches are units of work

The branch is where intention meets version control. One branch per unit of work: a capability, a correction, an experiment. The branch name states the purpose. The branch lives as long as the work is open and merges — or is deliberately abandoned with its reasoning recorded — when the work resolves.

ALIVE is developed in this shape, and the repository record supports the specific claims I make about it. Dozens of retained remote branches carry per-agent development, experiments, qualification, and review work, and main’s history shows the merges that brought finished work back — codex/adopt-templates-help, a workflow-binding repair, the memory-03 experience feature. Separately, the WF-03 report documents the opposite decision made with equal deliberateness: an experimental stack with two failing revocation regressions, paused and retained on its own branch rather than merged. That is the whole point in miniature. What I can verify from the record is the shape: named branches per unit of work, explicit merges for finished work, quarantine for unfinished work. I do not claim to know the motive behind every retained branch; the pattern across the history is consistent enough to read as discipline rather than accident, but the discipline I can prove is in the merges and the documented quarantine, not in a census of intentions.

Contrast this book’s own repository, which I run differently and for stated reasons: a linear main history, one commit per chapter pass, with planning and evidence documents committed alongside the prose. There are no long-lived branches here because the unit of work — one chapter draft or revision, reviewed before the next begins — is small and strictly sequenced. Two shapes, one principle: the version history must tell the story of the work. Branches serve parallel, exploratory, multi-agent development. A linear log serves sequential, reviewed development. What neither shape tolerates is the uncommitted sprawl — days of machine output with no checkpoints, no messages, no way back.

Commits are evidence — acceptance is something else

A commit preserves a state: at this point, the work stood here. That is distinct from every stronger claim we might make about it, and the chapter needs the vocabulary straight:

State	Meaning
Checkpoint	Work preserved and recoverable; nothing claimed beyond existence
Verified	Defined checks performed, with retained results
Reviewed	The required examination by the appropriate reviewer
Accepted	Authorised to become part of the accepted system

A commit establishes the first row. It does not independently prove any of the others. This distinction matters because the machine should be free to preserve intermediate work — incomplete experiments, failing tests, temporary scaffolding — without those checkpoints being mistaken for finished, approved contributions. Forbidding unreviewed commits does not produce rigour; it produces either paralysis or a history full of premature acceptances. Let the machine checkpoint freely; govern acceptance strictly, through the evidence, review, and integration checks the earlier chapters describe.

A commit message, though, is a claim: this work stands here for this reason, verified this far. Machine coding raises the standard for that message rather than lowering it, because the author of the change may not remember making it. I was not present in any meaningful sense for most of the lines my agents produce; the message, the test evidence, and the review record are my memory, and I write them accordingly.

The practices transfer directly. Small commits that do one thing. Messages that say why, not just what — the future reader needs the reasoning, which the diff cannot supply. Test evidence attached to the claim, not asserted beside it. No commit that the author — human or machine — could not explain on demand. Machine-generated messages deserve particular scrutiny here: a fluent summary of a change the machine only half-understood is worse than a terse honest one, so I treat generated messages as drafts to approve rather than text to accept. Rewriting history before merge — squashing exploratory stumbles into coherent steps, rewording messages that mislead — is legitimate craftsmanship, not dishonesty, provided the rewriting happens before review and never after acceptance. And critically: never accept what you have not reviewed at the level the change demands. The machine’s speed makes it tempting to accept broadly and review later. Later never comes, and the history fills with unverified work wearing the authority of the record.

This book follows its own rule. Each chapter arrived as a first draft commit, each revision as another, each supported by evidence notes and a planning document updated in the same pass. The history shows what was tried, what review found, and what changed as a result. The log reads as the book’s own table of contents in miniature: template cleanup, one chapter draft at a time, revisions with their evidence, editorial upgrades, index versions advancing alongside the manuscripts they track. Anyone opening the repository can see not only what the book says but how it came to say it — which drafts were revised, which decisions were recorded, and where each claim’s supporting evidence lives. That is not vanity publishing of process. It is the only reason any of it is checkable.

Notes and cadence

Version control captures what changed. Notes capture what was meant. The Intent Record, the package record, the next-work plan, the evidence notes committed alongside every chapter of this book — these are the working memory of the project, and they matter more under machine coding, not less. A human programmer carries context in their head between sessions. A machine session cannot safely be assumed to inherit every relevant decision or the current state of the repository: some agent systems hold persistent sessions, retrieved context, and durable state, while others start effectively from nothing, and Chapter 07 showed why the environment matters as much as the model. Either way, what is not written down cannot be recovered and verified by the next worker — and recovery with verification is the standard, not mere continuation.

Cadence is the rhythm that keeps both honest. Short, regular checkpoints — a review at the end of each work package, a commit at each verified step, a plan updated when direction changes — prevent the two characteristic failures of machine-assisted work: the uncommitted sprawl, where weeks of output accumulate without a single decision point, and the unrecorded drift, where the original intention quietly mutates through a hundred unexamined micro-decisions. It also governs the branches themselves: merged work gets merged and its branch retired; paused work stays visible with its stopping reason recorded; stale branches are pruned or explicitly renewed, never left to rot into ambiguity about what is live. Scrum understood this decades ago with its ceremonies; the names do not matter, and I claim no allegiance to any particular framework. What matters is the heartbeat: work, check, record, repeat. The machine can generate at any tempo. The heartbeat is what keeps generation pointed at the goal.

What happens without it

I have seen the alternative, and it is instructive precisely because the machine makes it so easy to fall into. A developer asks for a feature, receives a large diff, accepts it on the strength of a green suite, and moves on. Repeat for a month. The application grows; the history, if it exists at all, is a sequence of “updates” and “fixes” with no discernible relationship to any intention. Then something breaks in a way the tests do not cover, and nobody — not the developer, not a reviewer, not a fresh AI session — can determine what the system was supposed to do, which change introduced the fault, or what “correct” would even look like. All the code is present. None of the knowledge is.

Notice what failed. Not the model’s ability — the code mostly worked. What failed was legibility: no branches delimiting units of work, no messages recording reasons, no notes preserving intent, no checkpoints where a human judged and accepted. The machine did exactly what it was asked, at a scale no human team could match, and produced exactly what unsupervised generation produces: output without history, and therefore without accountability. Process is what converts output into engineering. Without it, machine coding is just very fast typing.

Make the machine follow it — then let it run the process

Here the earlier chapters pay off, because process compliance is itself a perfect work-package constraint. The machine does not resist discipline; left unconstrained it simply generates in whatever shape is easiest, which is usually one large undifferentiated change. So constrain it the way the book has taught: the package specifies the branch, the commit granularity, the message standard, and the evidence to retain — for example, work on feat/restart-behaviour, commit at each verified step with messages explaining the reasoning, attach the test evidence that closes each claim, update the package record before requesting review. Review checks the history as well as the code — was this committed in reviewable steps, does each message explain its why, is the record complete? Acceptance covers the trail, not just the result.

This is also where instruction files earn their place. Repository guidance that mandates branch-per-task, commit standards, and evidence retention turns every future session toward the process by default rather than by nagging. And the enforcement lesson from Chapter 07 applies unchanged: instructions request, mechanisms ensure. Branch protection, required reviews, and checks that refuse unverified history are what make the discipline real. A process the machine can silently skip is a suggestion, and suggestions do not survive contact with a deadline.

But there is a further step, and it matters for the book’s whole argument: the human should not become the process administrator. Telling the machine to work on branches is today’s instruction; increasingly, the machine should create and select the workspaces and branches itself, preserve meaningful checkpoints automatically, record intentions, changes, and verification results, keep the project plan aligned with accepted work, detect inconsistent history or abandoned work, and present the exceptions — the conflicts, the blocked merges, the decisions that need a person. The human defines the required properties of the process: everything traceable, reviewable, recoverable. The human evaluates whether the system respects them. The administration in between — the committing, the recording, the tidying — is exactly the kind of operational burden the steamroller exists to absorb. We delegate the discipline as well as the implementation, and we judge the machinery on whether the history it keeps is one we can trust.

The rails under everything

Look back at the book from here and the process chapter stops looking like an appendix. The Intent Record is notes discipline applied to purpose. The System Charter is notes discipline applied to the world. Package records and the application map are notes discipline applied to the work itself. Evidence notes are notes discipline applied to belief. Every durable record the method relies on is the same habit in different clothes: write down what mattered, where the next worker can find it, in a form the repository preserves.

That is why this chapter belongs where it does — after the skill of directing machines, before the question of quality. A machine that works on branches, commits evidence, and writes things down can be supervised, corrected, and trusted progressively. One that does not can only be believed or doubted wholesale, and neither scales. Follow the process, even — especially — when the machine does the work. It is the rails everything else runs on, and rails are what let heavy machinery move fast without leaving the ground.