Mostly Done.
Contents

1 This is not a prompting book

The prompt supplies direction. The machinery supplies everything else.

The easiest explanation for a good agentic patch is that the human found the right words: the prompt was precise, the model smart, the instructions firm. That explanation is attractive because it makes the agent the unit of analysis. It is also too shallow to explain any codebase that has stayed good for months.

The directions that keep long-running agentic work moving are strikingly terse: go, keep going, handle all of it, build the XYZ feature. Taken alone, those are dangerously underspecified. They work because they land in a repository that already defines what done means: which checks must pass, how work is divided, which artifacts must be updated, how branches integrate, and which decisions need your judgment. The prompt supplies direction, and the repository supplies detail. A two-word instruction is safe when it activates a thousand lines of machinery.

Terse delegation does not buy sustained autonomy, though. However wide its permissions, an agent tends to finish one bounded unit of work and stop to ask for inspection. What keeps execution moving is a completion harness: tests, workflows, review loops, and completion criteria that define done and make premature stopping difficult. Delegation grants permission. The harness supplies persistence.

1.1 The unit of quality is the loop

A coding agent sits inside a loop:

  1. receive direction;
  2. inspect the current state;
  3. form a model of the problem;
  4. design or choose a change;
  5. implement it;
  6. run checks;
  7. report what happened;
  8. integrate, release, or revise.

Every step can lie.

Your request may omit a constraint. Your repository may hold stale documentation. The agent’s model of the problem may be wrong. A test may pass for the wrong reason. The branch may be green while main is red. The report may say done while the issue stays open or the site serves last week’s release. Integration may combine two locally correct changes into a globally broken tree.

That is the book’s title in mechanical form. The agent, the test suite, the pull request, the release workflow, and the running application each certify a different fragment of done, and every fragment can be true while the whole is false.

A better prompt improves one step. A better system makes every step easier to challenge. That is why the machinery worth building emphasizes executable invariants, design review, independent validators, real-binary reproductions, full-suite runs after each merge, and live-release checks. The method assumes that any single intelligence, human or machine, will sometimes be wrong. Reliability comes from forcing different representations of the work to agree:

Each agreement is an independent chance to catch a fiction.

1.2 Throughput is not velocity

Agents produce code fast, and that invites a measurement error: more diffs, more branches, more reviews, and more issue movement all look like speed. Real velocity is the rate at which trusted capability accumulates. Trusted capability has a different shape from raw output. It includes tests that defend yesterday’s hard-won behavior, boundaries that make tomorrow’s change smaller, diagnostic tools that shorten the next investigation, and documents that keep the next agent from rediscovering the same trap. A day that lands no feature but adds a faithful golden harness can buy more future speed than a day that lands five unguarded features.

An early ordering worth adopting: safety nets first, then correctness, then structure, then features. It feels backward only if code generation is the scarce resource. With agents it rarely is. What stays scarce is confidence in what has landed, attention at integration time, and your judgment about what the product should be. Build the workflow around those.

1.3 The agent is not the process owner

Agents are valuable because they can carry broad execution: reading, editing, testing, documenting, triaging feedback, preparing releases. Broad execution is not authority over truth. Empower the agent to act and forbid it to self-certify. It can say what it did. It cannot make that statement true by saying it confidently; git state, test output, generated artifacts, independent review, and the live system decide.

You are under the same rule. Looks good to me is weak evidence for a rendering engine, and memory is weak evidence for a performance claim. A familiar architecture proves nothing about whether a new interaction is safe. The method does not swap human trust for machine trust. It replaces personal trust with inspectable contracts wherever a contract can be written.

1.4 A compact formula

Agentic software quality can be approximated as:

trusted progress
  = generated change
  x locality
  x detectability
  x independent verification
  x integration discipline

This is not a literal equation. It is a warning about multiplication. If a change is hard to localize, failures are hard to detect, reviews repeat the author’s assumptions, or integration is casual, then abundant generation amplifies uncertainty rather than capability.

The rest of this book is about raising those multipliers.

use ← and → to turn pages