The AI output spec: what good looks like before you start

Why this matters now

This pattern is drawn from Ethan Mollick's 7 July 2026 post on X, in which he argued that even before agentic AI became mainstream, prompting tricks stopped being very valuable. The best approach, he wrote, is to clearly specify your goals, your output, what "good" and bad look like, and how to test the results.

That is a management framing, not a prompt engineering framing. The difference matters. Prompting tricks tried to coax a model into doing something clever; a spec asks a capable executor to hit a clear standard. The rework that most knowledge workers experience — the technically correct output that is wrong for the actual use case — happens because neither side agreed on what "done" meant before the work began.

Mollick has been building toward this position in his writing on management as an AI superpower: the durable skill is not knowing which phrases unlock good output, it is knowing how to define a standard and hold work to it. That applies whether you are briefing a junior analyst, an offshore contractor, or an AI assistant.

When to use an output spec

Use it for any task where you will need to edit, approve, or pass the result to someone else: a draft, a summary, an analysis, a structured list, a slide outline, a client email. Skip it for quick lookups and single-sentence questions where you would recognise a good answer immediately.

A rough guide: if the task takes more than ten minutes to do manually, spend two minutes writing the spec. If it takes less, ask directly.

Copy this prompt

Add this header before your actual request, then paste the content you want processed after it:

Task:
[One sentence. What needs to exist when this is done?]

Output format:
[Be specific: bullet list / table with columns X, Y, Z /
email under 200 words / slide outline with 4 bullets per slide]

What good looks like:
- [Specific quality criterion — e.g. "each point cites a named source"]
- [Tone or audience bar — e.g. "readable by a non-technical director"]
- [Scope limit — e.g. "covers only the last 12 months of data"]

What to avoid:
- [Common failure mode — e.g. "no hedge phrases like 'it is important to note'"]
- [Off-target content — e.g. "do not include background the reader already has"]

Check before handing back:
- [Factual or source check]
- [Format check — does the output match the structure above?]
- [Audience check — would [specific reader] act on this without editing?]

Why each part earns its place

Task. Gives the AI the destination rather than the journey. Writing it in one sentence forces you to clarify the actual deliverable before work begins. If you cannot write the task in one sentence, it is not ready to delegate.

Output format. The single highest-leverage instruction. It removes the most common rework: receiving a wall of prose when you needed a table, or a 400-word email when 150 words was the brief. The format anchors everything that follows and makes the output immediately usable rather than requiring reformatting.

What good looks like. The critical piece most people skip. AI cannot calibrate "high quality" without a reference standard. This is exactly Mollick's management point: a good manager does not say "do a good job" — they define what "good" means for this specific task, for this specific audience, at this level of detail. Three to four observable criteria outperform a vague instruction like "be thorough" because the model can check them.

What to avoid. Catches the failure modes you already know from past experience with this task type. One or two specific prohibitions outperform "be concise" because they are binary — the AI can verify it did not break the rule before returning the result.

Check before handing back. Turns the AI into its own first reviewer. Self-checking catches format errors, missing elements, and scope drift before the output reaches you. It also signals that the model is accountable for the quality bar defined above, rather than treating delivery as the end of its job.

Worked example

You need a summary of a competitor's pricing page for a sales team calling a prospect tomorrow.

Without a spec:

Summarise this competitor pricing page for my sales team.

With a spec:

Task:
Summarise the pricing page below for a sales team
calling a mid-market prospect tomorrow.

Output format:
Bullet list, five bullets maximum, each under 20 words.

What good looks like:
- Each bullet contains a specific price point, plan tier,
  or feature limit a salesperson can quote.
- The full list reads in under 30 seconds.
- No bullet opens with the competitor's brand name.

What to avoid:
- Do not include the competitor's marketing language or
  value claims — only observable facts.
- Do not list features available on every plan;
  only differentiators matter here.

Check before handing back:
- Does each bullet contain a number or a named plan tier?
- Would someone walking into a call cold know what to say?

The spec version takes about 90 seconds to write and removes the back-and-forth of asking for reformats, tighter bullets, or a second pass with different instructions.

What this will not fix

The spec does not fix a vague task. "Summarise the company strategy" with a perfect four-part spec still returns something unfocused if the underlying task is unfocused. The goal must be concrete before the spec is worth writing.

The "what good looks like" section is only fully useful once you know what good looks like for this task type. For genuinely novel work, run a rough first pass without the quality bar, then use that output to define what you actually want. The first draft teaches you what to ask for.

Do not over-specify. If the quality criteria section runs to six bullet points, the model starts ticking a rubric rather than aiming at a standard. Three criteria, four at most, is where the spec stays useful rather than becoming another thing to manage.