Decide What Good Looks Like Before You Generate

Watch someone review an AI output and you'll see them doing two jobs at once: deciding what they wanted, and deciding whether this is it.

The second job is fast. The first is the expensive one, and it's being done under the influence of a piece of writing specifically shaped to be persuasive. You end up assessing whether the thing in front of you is good rather than whether it's what you needed — and those come apart more often than anyone likes.

Three sentences written before you generate fixes most of this, and it's the highest-return habit in the whole business of working with AI.

Judgement versus comparison

An undecided standard makes review a judgement: is this good? That's an open question, it's tiring, and it's suggestible. Fluent writing makes it harder, which is the wrong direction for a quality check to move.

A decided standard makes review a comparison: does this have these three properties? That's closed, fast, and largely immune to how well it's written. It also produces a usable answer when the output fails — you know which property is missing, so you know what to say next.

The difference is roughly a minute of work up front against five to ten minutes of deliberation afterwards, repeated on every attempt.

What makes a usable criterion

Checkable in seconds. "Every claim traceable to a named source" you can check. "Well-researched" you cannot.

About this output, not about writing in general. "Under a page", "leads with the recommendation", "no more than three options" — real constraints for this piece of work. Generic quality adjectives do no work.

Something the output could plausibly fail. If a criterion is satisfied by anything the model would ever produce, it isn't a criterion. "Professional tone" passes automatically. "Names the trade-off we're accepting" doesn't.

Three is the right number. One isn't a standard; six becomes a form nobody fills in.

Write it where you'll use it

Criteria written in your head don't survive contact with a good-looking draft — the standard quietly adjusts to what you're reading. Write them down, in the same place as the request, before the output exists.

This also makes them reusable. Most people have five or six recurring output types, and each needs its criteria written once. After a month you're not writing criteria at all, you're picking one of six sets you already have.

Give the criteria to the model too

The same three sentences make the output better, not only the review faster — you're describing the finish line, which is exactly the information most requests are missing.

Doing both is more than twice as useful as either. And when you then run the review, you're checking against the standard the output was aiming at, which surfaces a specific kind of failure: an output that meets the letter of your criteria and clearly isn't what you wanted. That's a signal your criteria were wrong, and it's cheap to learn.

Where it fails

Two honest limits.

Criteria don't catch what you didn't think to specify. They make review fast and slightly narrower. Keep one open question at the end — what's missing? — and ask it after the comparison, not instead of it.

Not everything decomposes. Genuinely creative or exploratory work resists this; when you're generating options to find out what you think, a standard set in advance defeats the purpose. Use it for the work with a known shape, which is most of it.

Aoife — the six sets she wrote once

Aoife is a communications lead at a university. She'd been re-deciding what good meant on every AI output, several times a day.

She spent an afternoon listing what she actually produces — press statement, internal announcement, event copy, briefing note, social summary, FAQ — and wrote three criteria for each. Six sets, one page, done.

She now pastes the relevant three lines into the request and checks against the same three afterwards. Her estimate is that review time dropped by more than half, and the bigger change was that first drafts started landing closer, because the criteria were also the brief.

Deniz — the draft that passed and was wrong

Deniz is a product manager at a fintech. He'd set three criteria for a competitor summary: under one page, top three differences only, each backed by a public source.

An output met all three and was clearly not useful — it had picked three real, sourced, trivial differences and omitted the pricing change that mattered.

His read was that this was the criteria failing, not the model. He added a fourth: differences that would change a customer's decision. Less mechanically checkable, and it was the one doing the actual work.

The one thing

Most review effort goes on deciding what you wanted while looking at what you got. Decide first, in three checkable sentences, and review becomes a comparison instead of a judgement.

Give the same three to the model. And when something passes and still isn't right, fix the criteria rather than the draft.