How to Use Generative AI: Spec, Three Passes, Then Stop

To use generative AI on real work, pick a task where checking the output costs less than producing it, write the request as a spec with accept criteria, generate once, then run at most three revision passes against that spec. That loop is the whole method. What changes between text, images, and code is only the gate you check against.

This is the companion to what generative AI actually is. That post defines the machine and its failure modes. This one drives it.

TL;DR

• Only take on jobs where you can separate good from bad in under a minute. Stanford HAI's 2026 AI Index economy chapter measures gains of 14 to 15 percent in customer support and 26 percent in software development, and notes gains shrink on tasks that need deeper reasoning.
• Write the request as a spec: job, inputs, output shape, accept criteria. The accept criteria are the part almost everyone skips.
• Three passes, then change the job. Each pass fixes one named defect and the fix goes into the spec, not the chat.
• Gate by modality. Text gets its claims checked. Images get a spec sheet. Code gets tests and a scan, because Veracode found 45 percent of AI-generated samples carried an OWASP Top 10 flaw.
• Tokens are not the cost. A three-pass draft loop runs about 4.5 cents on Claude Sonnet 5. The same 500 drafts cost 33 hours of human review.

Pick a job where checking is cheaper than doing

Adoption is not the constraint anymore. Stanford HAI's 2026 AI Index reports 88 percent organizational AI adoption and generative AI in at least one business function at 70 percent of organizations, while AI agent deployment sits in single digits across nearly every function. Plenty of access, thin deployment.

The reason is that saved time relocates. DORA's research, published March 10, 2026, found 90 percent of technology professionals now use AI at work and over 80 percent believe it raised their productivity, yet 30 percent report little to no trust in AI-generated code. DORA calls the gap a verification tax: time saved on generation gets spent on checking.

So the selection rule is arithmetic, not enthusiasm. Ask one question before you start: can I tell a correct output from a wrong one in under sixty seconds, without doing the task myself?

Jobs that pass: turning a call recording into structured notes, drafting a first version of a message you will edit, pulling named fields out of forty invoices, generating twelve thumbnail variants, writing a regex plus the tests that prove it.

Jobs that fail: choosing a vendor, deciding a tax position, summarizing a forty-page contract you have not read and do not intend to read. Each of those hides the error until it is expensive.

Write the request as a spec, not a wish

A spec has four parts. The job in one sentence. The inputs, pasted in full rather than described. The exact shape of the output. The criteria you will accept it against.

A wish: "write me a product update email."

A spec: "Write a product update email to 400 existing customers announcing the scheduling feature below. Inputs: the changelog and the two support tickets pasted underneath. Output: subject line under 50 characters, 120 to 160 words, one link, no bullet list. Accept criteria: names the feature in the first sentence, states what it replaces, no adjectives about how excited we are, reads like the last email in this thread which I have pasted as a reference."

The accept criteria do the heavy lifting because they are what the revision loop will compare against. Without them you are reacting to vibes on every pass, and vibes do not converge. The full anatomy of a request is in how to write AI prompts, and the reusable versions I keep on hand are in PROMPT MASTER.

One addition that beats any wording trick: paste a real example of the thing you want. One good past email outperforms three paragraphs describing the tone of a good past email.

The loop: diagnose, patch, stop

Two rules make the loop converge.

First, never say "make it better." Name the defect: "the second paragraph invents a statistic," "the subject line is 71 characters," "this function has no error handling." A named defect is a spec line you can add permanently.

Second, the fix goes into the spec. If you patch it in a chat follow-up, you own a conversation. If you patch it in the spec, you own a reusable asset that works tomorrow on a different input. That distinction is the whole argument in WRITE LOOPS NOT PROMPTS.

The three-pass limit is not superstition, it is a stopping rule that saves you from sunk cost. A third failure has a diagnosis: the model is missing context you never gave it, or the task needs judgment you have not encoded, or verification costs more than doing the work. None of those are wording problems.

Text: gate on claims, not on tone

Tone is cheap to fix and you will notice it instantly. Facts are expensive to fix and they survive a skim, which is exactly why generated text fails in public.

So the text gate is a list, not a feeling. Every proper noun, every number, every date, and every citation gets checked before the draft leaves your machine. If a claim has no source you can open, it comes out. Model confidence carries no information about accuracy, because a fabricated citation is exactly as plausible a continuation as a real one.

The structural fix is to stop asking for recall. Paste the source material into the request and tell the model it may only use what you pasted. That converts the job from remembering to transforming, which is the shape generative AI is actually good at. More on the failure mechanics in how to reduce AI hallucinations.

Images: gate on a spec sheet, and count the attempts

Image generation fails differently. The output looks finished before it is correct, which makes eyeballing it a bad gate.

Write the spec sheet first: subject, composition, palette in hex, whether rendered text is allowed, aspect ratio, and an explicit list of what must not appear. Then check every candidate against the list rather than against whether you like it. The recurring defects are malformed hands, garbled in-image text, the wrong object count, and a subject that drifts a few degrees off-brand on each pass until image nine looks nothing like image one.

Two operational rules. View the candidate at final size on the final background before you accept it, because thumbnail review hides all four of those defects. And iterate cheap, finish expensive. Google's published Gemini API pricing puts Gemini 3.1 Flash Image at 0.067 dollars per 1K image and Gemini 3 Pro Image at 0.134 per 1K or 2K image, rising to 0.24 at 4K. Forty exploratory attempts at the 1K Pro tier is 5.36 dollars. The same forty at 4K is 9.60, and batch pricing halves either. Explore at small resolution, render the winner once at full size. The prompt structures I use for this are in IMAGE CODES.

Code: gate on tests and a scan

Generated code is the one modality where the gate is already automated, so there is no excuse for skipping it.

The evidence is blunt. Veracode's GenAI Code Security Report, published July 30, 2025, tested over 100 models across real coding tasks and found 45 percent of generated samples introduced an OWASP Top 10 vulnerability. Java failed 72 percent of the time, C# 45, JavaScript 43, Python 38. Cross-site scripting defenses failed in 86 percent of relevant samples. Newer and larger models did not score better, which means upgrading your way out of this is not a plan.

Pair that with DORA's finding that higher AI adoption correlates with both more throughput and more delivery instability, and the working procedure writes itself:

1. Ask for the failing test before the implementation. Now the accept criteria are executable instead of aspirational.
2. Run the code. Never accept generated code you have not executed, including the code you only skimmed because it looked routine.
3. Run the scanner as part of the gate, not as quarterly cleanup.
4. Review the diff at the size a human can actually review. Generation speed is not a reason to ship 900-line changes.

What the loop actually costs

Token cost is almost never the blocker, and treating it as one is how teams end up optimizing the wrong side of the ledger.

Anthropic's published pricing puts Claude Haiku 4.5 at 1 dollar per million input tokens and 5 per million output, Claude Sonnet 5 at 2 and 10, and Claude Opus 5 at 5 and 25. Take a three-pass drafting loop that sends roughly 3,000 input tokens and returns 900 output tokens per pass. That is 9,000 input and 2,700 output across the loop: 1.8 cents in, 2.7 cents out, about 4.5 cents for the finished draft on Sonnet 5. Five hundred drafts in a month is 22.50 dollars. The Batch API halves both sides for anything that can wait, and a cache read costs a tenth of base input, so a large reusable spec stops mattering after the first call.

Now price the other side. Five hundred drafts at four review minutes each is 33 hours. That is the real budget line, and it is roughly 3,000 times the token cost at a modest hourly rate.

Which tells you what to optimize. Tighter accept criteria cut review minutes. A cheaper model does not. If you are choosing between spending an hour on your spec and an hour comparing per-token prices, the spec wins every time. How to choose an AI model covers the cases where the model choice genuinely does move the number.

The bottom line

Using generative AI well is a selection problem and a stopping problem, not a prompting problem. Select tasks where the check is cheaper than the work. Write the accept criteria before the first generation. Run three passes, each fixing one named defect, each fix landing in the spec. Gate text on its claims, images on a spec sheet, code on tests and a scan. Then stop, because the fourth pass is where your judgment goes to die.

Everything in this post costs pennies to run and pays out in review minutes you stop losing.

Want the reusable version? WRITE LOOPS NOT PROMPTS is the free resource that turns a one-off spec into an asset you run every week, and I send one build like this every Wednesday. Join the newsletter.