Writing a done-line

Day 11: Write "done =" before you prompt

The first draft isn't where you lose time with AI. You lose it in rounds two, three and four, the replies that start with "No, not like that." In my experience one line in the prompt removes most of those loops. It says what "done" means, and it lists what the AI isn't allowed to touch on the way there.

A real session, replayed

I asked a coding agent for a small fix. Our date parser broke on end-of-year dates like 31/12. My prompt was roughly: "Fix the date parsing bug in parseInvoiceDate, it fails on 31/12."

• ▹Round 1: it pulled in a date library and rebuilt the parser around it. Me: "No, no new dependencies."
• ▹Round 2: it changed the function signature to return a richer result object. Me: "No, callers depend on that signature."
• ▹Round 3: it made the test pass by loosening the assertion. Me: "No, not like that. Don't touch the test."
• ▹Round 4: a small, correct fix inside the existing function. Accepted.

Put those three rejections side by side: no new dependency, signature unchanged, don't edit the test. Add the goal and you have a one-line spec. I knew every word of it before I typed my first prompt. I just never wrote it down.

The reframe

The agent wasn't being dense. I was dictating the spec one rejection at a time, and every "no" carried exactly one criterion that should have been in the prompt from the start.

In each correction round, the agent discovers one done-condition you already had. You pay for each discovery with a round trip, some context and some of your attention. Long correction threads also tend to make the session worse, because by round four the model is carrying three abandoned approaches in its context.

The pattern: done = check + fences

A done-line has two parts:

• ▹The check is the observable thing that proves the task is finished: a test passing, a number reconciling, a word count. Both you and the AI need to be able to verify it. "Clean" and "better" are feelings, so they don't count.
• ▹The fences are the routes the AI may not take to get there. To find them, ask yourself: what would make me reject an answer that technically works?

done = <the check that proves it> + <the fences>

Here's the same task again:

Fix the date parsing bug in parseInvoiceDate: it fails on 31/12.

done = the existing test plus a new case for 31/12 pass;
       no new dependency;
       public signature unchanged;
       don't edit the test you're fixing (add the new case alongside it).

The agent got it right on the first attempt. The model didn't get any smarter between prompts. It had less room to wander, because every route I would have rejected was already closed.

Why fences matter more than the finish line

Most people who write success criteria at all only write the finish line: "make the test pass", "fix the bug". In my experience modern agents usually do reach the finish line. The trouble is the route they take to get there. An agent optimises for the goal you gave it, and as far as it can tell, any shortcut you didn't rule out is allowed.

Here are the escape routes I run into most, with the one-clause fence that shuts each one:

• ▹Pulling in a library to sidestep the real problem → "no new dependency"
• ▹Refactoring nearby code it decided was ugly → "only modify <file/function>; don't touch anything else"
• ▹Changing an interface to make the fix easier → "public signature / API / schema unchanged"
• ▹Weakening, skipping or mocking the test until it goes green → "don't edit existing tests; no new mocks"
• ▹Catching and swallowing the error instead of fixing the cause → "no new try/catch that hides the failure"
• ▹A sprawling diff you can't review → "diff under ~30 lines" or "one commit, one concern"
• ▹Quietly changing behaviour for other inputs → "all existing tests still pass"

Look at the ratio in my rewritten prompt: one clause states the goal and three are fences. That's about normal in what I see. If your done-line is all finish line, you've probably left the escape routes open.

Cheat-sheet: done-clauses you can copy

You don't need to invent these from scratch each time. Most fences get reused, so keep a short list and paste from it.

# Coding
done = failing test <name> passes + all existing tests pass; no new dependency
done = ...; public signature unchanged; only edit <file>
done = ...; don't modify or delete existing tests; no new mocks
done = ...; diff under 40 lines; no formatting changes outside the fix

# Writing / email
done = under 120 words; no new commitments; keeps the original deadline
done = same facts as my draft; tone firmer, not ruder; no apology for the delay

# Analysis
done = numbers reconcile to the source sheet; no new assumptions unstated
done = every claim cites a row/cell; flag anything you had to estimate

The shape works outside code too. Look at the email fences, "no new commitments" and "keeps the original deadline". An AI rewriting an email often turns more helpful than you wanted and promises things on your behalf. Those two fences stop that.

The self-check that matters most

If you can't write the done-line in one sentence, stop. The task isn't ready to hand to anyone, human or AI.

I apply the same rule as an engineering manager. When a ticket arrives without acceptance criteria, it goes back to whoever wrote it. I'm not trying to be difficult. A ticket that nobody can call "done" comes back three times in review, and each of those reviews is someone uncovering the criteria one rejection at a time. If you lead engineers and you've been following this series, you'll recognise this as Definition of Done turning up in a new place. The prompt is the ticket now.

So when the line won't come, the prompt isn't the problem. The missing line is a gap in your own thinking. Take two minutes to decide what you'd accept and what you'd reject. Otherwise you'll spend twenty minutes finding out through corrections.

• ▹When NOT to bother: open exploration, like "give me five ways to approach X" or "what am I missing here?". You want options there, not a finished deliverable, and a done-line would narrow the answer too early.
• ▹Pitfall: fences that are really preferences, like "make it elegant". If you can't check it, it isn't a fence.
• ▹Pitfall: twenty fences. If your line has grown into a paragraph, you're probably looking at two tasks. Split them.

Where this goes next

The done-line also gives the AI something concrete to check itself against. Once the check can actually be run (a test, a reconciliation, a word count), the agent can loop test → fix → test without you sitting in the middle. The next few days in this series are about letting the AI verify its own work, and all of them depend on this line being there.

Your task

Before your next prompt, type "done =" first and fill it in. Then write the rest. If you still end up correcting the AI, turn that correction into a standing fence and keep it in a notes file, a CLAUDE.md or your custom instructions. That way you only ever have to say that particular "no" once.

Extend your knowledge

• ▹Go back through your last three AI sessions that needed corrections. Turn each correction into a reusable fence, and you've started a personal fence list.
• ▹Move your standing coding fences into a project instructions file so every session picks them up: CLAUDE.md for Claude Code, custom instructions in ChatGPT, .github/copilot-instructions.md for Copilot.
• ▹Read Anthropic's prompt engineering docs, especially the "Be clear and direct" guide and the page on defining success criteria. Compare what they recommend with check + fences.
• ▹If you lead a team, put your Definition of Done next to your prompts. Do the acceptance criteria you insist on for tickets also show up when your team prompts agents?