Preface: The several conditions

Ask a coding agent whether the work is done and it will say yes. Ask the test suite and it will say the assertions passed. Ask the pull request and it will say the branch was green. Ask the release workflow and it will say the artifacts published. Ask the actual application, running on an actual machine in front of an actual person, and you will sometimes get a different answer than all four.

None of these witnesses is lying. Each is answering a different question. The agent means I completed the unit I was given. The tests mean the fields I compare agreed. The pull request means this branch was compatible with the base it last saw. The release workflow means my own steps succeeded. The application means whatever it does when a human opens it. Software built with coding agents lives in the gap between these answers, and most of what goes wrong in agentic development is some version of mistaking one witness’s testimony for the whole verdict.

Hence the title. Mostly done is the honest, permanent condition of software in motion, not a complaint about laziness. Whether the work is done in general is unanswerable. Which specific conditions of doneness have been established, by which evidence, and which remain open: that you can answer, and this book is a treatise, brief on purpose, about how. How to state the conditions, how to make them executable, how to catch the witnesses disagreeing early, and how to keep a fallible author, human or machine, from declaring the verdict alone.

The argument in one paragraph

Good software built with coding agents does not come primarily from better prompting, a larger context window, or a more obedient model. It comes from arranging the work so that generation is cheap, mistakes are local, claims are challengeable, and verification is closer than self-deception. The agent can write a great deal of code. The engineering problem is to build a system in which no single witness, machine or human, is allowed to declare the software finished on its own testimony.

What finished means here

Done is intentionally not reduced to test coverage or release speed. It decomposes into conditions that can each be established or refuted separately:

1. Semantic correctness. The software does what its contracts say, including awkward edge cases.
2. Preservation. User data, source text, and intended meaning are not silently lost.
3. Perceptual quality. Rendered output and interactions satisfy named visual or behavioral rules that type checks cannot cover.
4. Operational truth. The shipped artifact, release assets, website, and documentation match the code that was supposedly completed.
5. Maintainability. Changes remain local enough that another agent can reason about them without reconstructing the entire system.
6. Epistemic honesty. Unknown causes remain unknown until evidence resolves them. Bad news is surfaced rather than narrated away.

These conditions sometimes conflict. A hard gate can slow a small change. A beautifully factored system can still render something ugly. A reviewer can produce plausible nonsense. The method in this book reserves human judgment for the places that require it and turns everything else into machinery.

How to read it

The early chapters describe the shared engineering loop: boundaries, executable contracts, tested tests, generated proof, design gates, adversarial review, debugging, integration, and memory. Three later chapters show how the loop changes across demanding domains: preserving user data, checking taste by machine, and keeping semantics true across boundaries. The final chapters describe the human-agent division of labor, a practical operating playbook, the failure modes that look productive, and what good actually looks like. Appendix B compresses the whole book into eleven takeaways.

The chapters are short on purpose: not a new software-development religion, just a small set of moves that have repeatedly paid rent.