Mostly Done.
Contents

17 What good looks like

Projects that go well with coding agents do not go well because the agent stopped making mistakes. It never does. It still writes the review finding that dissolves under scrutiny, the benchmark that flatters, the fix that quietly breaks a neighbor, the feature that ships and then has to come out. What improves is the price of exposure. In a healthy project, each mistake gets caught earlier, by something cheaper than your full attention.

That is the standard to look for.

17.1 The repository carries the discipline

A healthy agentic project does not depend on anyone remembering the perfect prompt. A fresh agent, cold, can find:

The conversation can be terse because the repository is not.

17.2 Proof gets harder to fake

The checks do not all repeat one assumption. The regression test fails on the old code before it passes on the new. The fixture verifier rejects a deliberately damaged fixture, which proves it can reject at all. A reference implementation disagrees the moment the parser drifts. A layout check and a pixel check cannot be fooled by the same bug. The integrated tree runs the full suite after each merge, not just the branch’s slice. The published artifact gets opened by hand instead of inferred from a green badge.

No single check is trustworthy. The system earns trust by giving a plausible fiction several places to break.

17.3 Your attention goes to novel problems

You notice the cursor jump, the crowded labels, the claim that sounds too flattering. The agent turns the observation into traces, tests, and documentation. Once the failure class has a name and a detector, a ratchet carries it forward, and you never have to notice that defect again.

That is how taste compounds.

17.4 Stopping is allowed

A good session can end with a revert, a rejected finding, a corrected document, or a request for a diagnostic that does not exist yet. The workflow does not demand a patch as proof that work occurred.

That freedom matters. It keeps generation from becoming the default answer to uncertainty.

17.5 Reversal is ordinary

Small branches, explicit migrations, and narrow contracts let you change course without defending sunk cost. We were wrong becomes a normal engineering state rather than an emergency. Correctness has to cost less than pride, and these structures are what make it cost less.

17.6 The verdict is assembled, not announced

Ask whether the software is done and you get testimony, not a verdict. The agent says the task is complete. The test suite says its assertions hold. The pull request says reviewers found nothing more. The release workflow says the pipeline ran. The application, opened by hand, says what it actually does. These witnesses never describe quite the same thing, and that is not a defect to engineer away. Each covers ground the others cannot see, and the disagreements between them are where the defects live.

So the honest answer to is it done? is almost always mostly, followed by particulars: which conditions are established, on what evidence, and which remain open. The craft is making that sentence precise and cheap to say. Name the conditions. Give each one an executable witness. Prove the witnesses can object. Let no author, human or machine, close the case alone.

One question sorts workflows:

When the agent is confidently wrong, what happens next?

If the answer is that you will eventually notice, the system runs on vigilance, and vigilance does not accumulate. A stronger answer is visible in the repository itself: the change is small, the claim has a known-bad test, independent reviewers try to break it, the merged tree runs clean, the public artifact agrees, and the lesson survives the session.

Software declared finished that way is still only mostly done. But it is mostly done the way a well-run investigation is mostly closed: the open questions are named, the evidence is filed, and no one had to take anyone’s word for it. That is enough to build actually good software with a fallible author. It is also a good way to build software with people.

use ← and → to turn pages