Stop Regenerating AI Output. Start Correcting It.

Most people accept the first draft or throw it out. The usable work is in round two.

Most people accept the first draft or throw it out. The usable work is in round two.

Watch someone use AI for real work and you'll see one of two moves.

They read the output, decide it's close enough, and paste it into the document. Or they read it, decide it's wrong, hit regenerate, and hope the dice land better this time.

Both are the same mistake wearing different clothes. Both treat the first output as a verdict — accept it or reject it — when it's a draft.

You would never do this with a person. If a junior analyst handed you a first draft that missed the point, you wouldn't shrug and send it to the client, and you wouldn't fire them and hire a new junior. You'd tell them what was off and ask for another pass. That conversation is where the work actually happens.

With AI, most people skip it entirely.

Regeneration is not correction

Hitting regenerate feels like iteration. It isn't. You've given the model no new information, so you're just resampling — pulling a different card from the same deck and hoping it's better.

Correction is different. Correction means saying what specifically was wrong and asking again. "Good, but you missed the exception cases and the tone is too formal for this audience — again." That's new information. That's a different deck.

The distinction sounds pedantic until you count the rounds. Resampling a bad output ten times gets you ten flavors of the same misunderstanding. Correcting it twice usually gets you something usable.

Where I learned this the slow way

On a delivery project last year I ran more than sixty stakeholder interviews and fed the transcripts to ChatGPT to aggregate.

The first summary was never usable. Neither was the second, most of the time. It took two or three rounds before I had something I'd put in a requirements document, and I spent months assuming that was just the cost of doing business — that iteration was friction, an unavoidable tax on using the tool.

It wasn't. It was the tool telling me something, and I wasn't listening.

What I eventually noticed was that I was fixing the same things every time. Different interview, different stakeholder, same three corrections. The model kept dropping the exception cases. It kept turning two people who disagreed into one consensus. It kept filling gaps with plausible industry defaults nobody had actually said.

Three failures, over and over, and every single week I was catching them fresh, as if I'd never seen them before.

The part that makes it compound — or not

Here's the asymmetry nobody mentions in the "treat AI like a junior" advice, and it's the thing that breaks the analogy.

A junior notices. Correct them on the same thing three times and something shifts. They start saying "I know, I always miss that." They've spotted the pattern in your corrections and built the checklist themselves, without being asked. That's the moment a junior stops being a cost and starts being an asset, and it happens on its own.

A model never gets there. Not because it can't retain anything — it can. Every serious tool now has some version of persistent context: Projects in Claude, Custom GPTs, Gems. Pin your corrections there and they'll be waiting for you tomorrow. The storage problem is solved.

What isn't solved is the noticing. No model is going to review the last twenty things you corrected, spot that four of them were the same mistake, and write itself a note about it. It will cheerfully make the identical error every session until you tell it not to — and then it will stop, permanently, because you told it.

So the memory isn't the bottleneck. The attention is. And the attention has to be yours.

The workflow: build a fix list

This is the whole method, and it's almost embarrassingly simple.

Tool: Any Takes: Two minutes per session, once you've started Output: A prompt that gets better every week instead of staying the same

Step 1 — Treat the first output as a draft, always

Not a result. Not a verdict. A draft, from someone who has never met your project.

Read it against the source, not against your expectations. The question isn't "is this good?" It's "what's in here that isn't in my notes, and what's in my notes that isn't in here?"

Step 2 — Correct specifically, not generally

"Make it better" gives the model nothing. "This is too formal" gives it a little. "You dropped the partial-batch exception and the mislabeled-lot exception, and both were mentioned as asides — go back and pull every exception case out of the source" gives it everything.

Name the failure. Point at the source. Ask again.

Step 3 — Write down what you corrected

This is the step everyone skips, and it's the only one that compounds.

Keep one file per workflow — a plain list, no structure required. Every time you correct something, add a line:

``` SUMMARIZING INTERVIEWS — what I always have to fix

• Drops exception cases (mentioned as asides, never survive compression)
• Merges disagreements into consensus
• Invents industry-standard requirements nobody stated
• Splits one step into two when different people name it differently

```

That's it. It's a boring text file. It's also the single highest-leverage artifact I've ever built for working with these tools.

Step 4 — Put the list where the model reads it before it starts

Now the list stops being a checklist and starts being an instruction.

If you're working in a Project, a Custom GPT, or a Gem, this is exactly what those are for. Put the fix list in the persistent instructions and you write it once instead of pasting it every session. That's the whole value of persistent context, and most people use it to store a personality when they could be storing hard-won corrections.

If you're not, paste it in up front, every time:

``` Before you summarize, note these known failure modes and avoid them:

• Exception cases are usually mentioned as asides. Preserve every one.
• Where two people disagree, keep both positions. Do not reconcile them.
• Do not add any requirement that is not explicitly stated in the source.
• If two people describe the same step with different words, flag it as

a possible duplicate rather than listing it twice.

Then: [your actual task] ```

The rounds drop. Not to zero — you'll still correct things, and you'll add those corrections to the list. But three rounds becomes one, and the one is better than the three used to be.

Watch-for: the list is workflow-specific, not universal. What the model gets wrong summarizing interviews is not what it gets wrong drafting a status report. Keep them separate. A generic "be accurate" preamble does nothing.

The proof: a second list, a different job

If the fix list were really just "AI makes mistakes, write them down," one list would cover everything. It doesn't. Here's the one I keep for weekly status reports, and there is almost no overlap with the interview list at all.

``` STATUS REPORTS — what I always have to fix

• Softens red. A workstream I flagged as red comes back

described as "experiencing some challenges"

• Fills silence. If my notes say nothing about testing,

it writes "testing on track" anyway

• "Decisions needed" comes back hollow — no options,

no deadline, no named owner

• Leads with the activity, not the implication.

"We held three workshops" instead of "scope is still open" ```

Look at the two lists side by side and the pattern is obvious. Summarizing interviews, the model's failure is compression — it drops, merges, and smooths. Drafting a status report, the failure is tone — it takes bad news and rounds it toward comfortable. Same model, same week, opposite problems.

That's not something you can prompt your way out of with a universal preamble. It's something you only learn by watching your own corrections pile up on your own work.

And the payoff isn't subtle. The status report used to take me three or four passes before the language matched the actual state of the project — I'd write red, it would give me amber, I'd push back, it would hedge. With those four lines pinned in front of the task, it lands in one pass and the report says what I meant. Not because the model got smarter. Because I finally told it the four things it always gets wrong.

What a mature list looks like

It gets shorter, not longer. That surprised me.

The first month, you're adding lines constantly — every session turns up another thing. Then the additions slow, because you're no longer discovering new failure modes; you're seeing the same four or five, and they're already written down. The list stabilizes.

And then it starts to shrink, because some of those lines stop being about the model and start being about you. "Invents requirements nobody stated" was a model problem. But after I'd looked at it for long enough, I realized half the invented requirements were things my notes had been vague about — I hadn't captured the answer clearly, so the model reached for a plausible default. That line came off the AI fix list and went onto a different one: things to nail down while I'm still in the room.

The fix list is a mirror. Keep it long enough and it stops telling you about the tool.

Why this is the actual skill

There's a lot of noise about prompt engineering, and most of it is people trading incantations — magic phrasings that supposedly unlock better output.

The real thing is duller and it works. The model will hold anything you give it. What it won't do is work out what to give it — and that's the actual job.

Which means the person who gets good at this isn't the one with the cleverest prompt. It's the one who has been paying attention to their own corrections for six months and has a boring text file to show for it.

That file compounds. The prompts don't.

This article originally appeared in AI in Plain English on Medium — read the original there, or follow new pieces on Substack.