I used to fix weak AI drafts by asking for better prose.
"Make it clearer." "Make it more persuasive." "Make it sound less generic."
The output improved a little. Then it failed in the same place: the article looked polished, but nobody remembered what it was trying to say.
TL;DR: Before you ask AI to write, fill a five-line editorial brief: audience, takeaway, material to use, first point to place, and scope delegated to AI. The prompt gets shorter because the decision-making moved back to the human.
Decide these five things before the first draft:
That is the difference between an AI writing prompt and an AI writing workflow.
A prompt says, "write a useful article about this." A workflow says, "write for this reader, to deliver this point, using this material, in this order, while leaving these decisions untouched."
Here is the copy-paste version I now use before drafting:
cat > ai-writing-brief.md <<'BRIEF'
Audience:
Takeaway:
Material to use:
First point to place:
Scope delegated to AI:
BRIEF
Output: a five-line brief that makes the human decisions visible before the AI starts drafting.
If those five lines are empty, a better prompt usually will not save the article. It will only make the generic answer prettier.
AI can satisfy the instruction you give it. If you ask for more detail, it adds detail. If you ask for simpler language, it removes jargon. If you ask for a friendly tone, it softens the edges.
All of that can be correct and still useless.
The missing part is not grammar. It is aim.
A draft can have headings, clean paragraphs, and natural transitions while still leaving the reader with no decision, no next step, and no sentence worth remembering. That failure is especially frustrating because the draft does not look broken. There is no obvious typo to fix. No paragraph is obviously wrong. It is simply weightless.
That is when many people start polishing the prompt.
They add more constraints. They specify tone. They ask for examples. They ask for a stronger opening. They ask the model to "make it engaging." The draft becomes more fluent, but the core problem stays: the model still does not know who must be changed by the article.
For me, the uncomfortable lesson was this: a polished AI draft can hide the absence of an editorial decision.
The better the model gets at writing acceptable prose, the easier it becomes to miss the fact that nobody decided what the piece is for.
"Developers" is not a reader. "People interested in AI" is not a reader. "Everyone on the team" is not a reader.
Those labels are audiences in a marketing spreadsheet. They are too broad to guide a paragraph.
A usable reader is closer to this:
The reader needs to be specific enough that you can make tradeoffs.
If the reader is a beginner, you define terms. If the reader is already deep in the project, you skip the setup. If the reader is in a hurry, you move the decision to the top. If the reader is skeptical, you show the failure mode first.
Without that reader, the model does the safest possible thing: it writes for a vague average person.
That average person is often the reason AI writing feels like it came from nowhere and goes nowhere.
Here is the test I use: can I name one real person who would benefit from this draft?
Not a demographic. A person. Someone whose current confusion I can describe in one sentence.
If I cannot do that, I do not ask the AI to draft yet.
A post is not a container for everything you know. It is a transfer of one useful idea.
When I ask AI to summarize a week of work, it tends to include all the visible facts: meetings, small fixes, decisions, open tasks, and background context. Nothing is necessarily false. The result still fails if the reader wanted one answer: "Are we safe to keep moving?"
Facts are not the same thing as a takeaway.
Before drafting, I now write one sentence that finishes this phrase:
After reading this, the reader should be able to...
For example:
That sentence becomes the spine of the draft.
It also gives you permission to cut good material.
Good material that does not serve the takeaway is still noise in this article. It may belong in another article, a footnote, a follow-up, or a private note. It does not belong here just because it is true.
People often treat AI like a bigger inbox: throw in all the notes, ask for a draft, then hope the model discovers the point.
That sometimes works for organization. It rarely works for judgment.
AI is good at using material. It is less reliable at deciding why a piece of material deserves to survive.
If you give it ten meeting notes, it may respectfully include all ten. If you give it a long research dump, it may flatten every source into equal weight. If you give it every thought you had while working, it may preserve the mess and make the mess sound professional.
That is not intelligence failing. That is missing criteria.
The human has to decide what counts as evidence for this article.
A simple table helps:
| Material | Keep? | Reason |
|---|---|---|
| The incident that triggered the post | yes | It gives the reader a concrete pain point |
| Background history of the project | maybe | Only keep what explains the decision |
| Interesting side discovery | no | Save it for another post |
| Exact wording of the final workflow | yes | The reader can reuse it |
| Internal process details | no | They explain the author, not the reader's problem |
The important move is not the table. It is the act of forcing a reason.
"This is interesting" is not enough. "This helps the reader believe or use the takeaway" is enough.
Sometimes I still ask AI to draft from a messy pile first. That can be useful when I do not yet know what is in the pile. But I treat that first draft as an inventory, not as an article. I then cut from it manually.
The first draft answers, "What material exists?"
The human edit answers, "What material belongs?"
Those are different questions.
The order in which something happened is rarely the order in which a reader should learn it.
Work happens in time order. Understanding often does not.
A meeting starts with context, moves through discussion, and ends with decisions. A reader of the meeting note usually wants the decision first. A bug investigation starts with confusion, moves through dead ends, and ends with the cause. A reader of the incident write-up usually wants the impact and fix before the archaeology.
AI will often preserve the order you provide, because that is a reasonable thing to do. If your notes are chronological, the draft may be chronological. If your brain dump starts with background, the article may start with background.
That is how readers get trapped in a lobby before they reach the room they came for.
Before drafting, I choose the first move:
For this article, the first move is the failure: asking AI to write better did not solve the problem.
That matters because the target reader has probably tried the same fix. If I started with a clean definition of "editorial brief," the article would feel like theory. Starting with the failed repair makes the workflow feel earned.
Order is not decoration. Order is part of the argument.
This is the decision people skip because it feels obvious.
"I am using AI to write." Fine, but which part of writing?
Writing includes more than sentences. It includes choosing the reader, selecting the claim, deciding what to cut, ordering the argument, choosing examples, setting tone, and polishing language.
Those are not equally safe to delegate.
Here is my current split:
| Task | I keep | AI can help |
|---|---|---|
| Choose the reader | yes | suggest alternatives |
| Choose the takeaway | yes | test clarity |
| Select material | yes | group and summarize |
| Decide order | mostly | propose variants |
| Draft paragraphs | no | yes |
| Smooth tone | no | yes |
| Shorten without losing meaning | review | yes |
The key phrase is "AI can help," not "AI owns."
If I have a strong opinion, I can delegate the execution. If I do not have an opinion yet, delegating usually means outsourcing the wrong thing.
A useful test is whether I can reject the model's suggestion quickly.
If the AI suggests a sentence and I can say, "No, that sounds too salesy," that is a safe area to delegate. I have a standard. If the AI suggests the article's target reader and I think, "That sounds reasonable," without any ability to challenge it, I probably delegated too early.
Delegation works best where the human has taste, context, and the ability to say no.
It works poorly where the human is hoping the model will create the judgment the human has not yet made.
Here is the complete version.
Audience: A specific person or role, with their current confusion.
Takeaway: One sentence that says what the reader should be able to do or believe after reading.
Material to use: The examples, logs, notes, or facts that directly support the takeaway.
First point to place: The opening move that makes the reader keep reading.
Scope delegated to AI: The parts the model may change, and the parts it must not decide.
And here is a filled version for this article:
Audience: A developer or team lead whose AI-written posts look polished but feel generic.
Takeaway: A better prompt starts with human editorial decisions, not more wording tricks.
Material to use: Failed polished drafts, weekly-report examples, material-cutting examples, and a reusable brief.
First point to place: I tried asking AI to write better, and it did not fix the problem.
Scope delegated to AI: The model may help phrase and compress, but it must not choose the reader, takeaway, or cuts.
Notice how little of this is prompt magic.
There is no special jailbreak. No hidden roleplay. No giant system message.
The brief is boring on purpose. It forces the missing decisions into visible text.
After that, the prompt can be simple:
Using the brief below, draft a dev.to article. Keep the audience and takeaway unchanged. You may improve phrasing, section transitions, and examples, but do not change the reader, the central claim, or the material selection without calling it out first.
[brief here]
The more clearly I write the brief, the less dramatic the prompt needs to be.
Here is the kind of prompt that used to give me a polished but forgettable article:
Write an easy-to-understand article about how to use AI for writing. Make it practical and engaging. Include examples and a conclusion.
Nothing in that prompt is offensive. It is just empty of decisions.
Who is the reader? Unknown.
What should they do after reading? Unknown.
Which examples matter? Unknown.
What should come first? Unknown.
What should the AI not change? Unknown.
Now compare it with the brief-based version:
Audience: A developer who uses AI to draft team updates but keeps getting generic reports.
Takeaway: They should define the reader, takeaway, material, order, and AI scope before drafting.
Material to use: Weekly report example, meeting-note example, and five-line brief.
First point to place: A polished report can still fail if the reader cannot see the decision.
Scope delegated to AI: Improve language and structure, but do not invent a different reader or takeaway.
Draft the article from this brief. Use a practical tone, short paragraphs, and include a copy-paste checklist.
The second prompt is not better because it is longer. It is better because the judgment is already present.
The AI is no longer being asked to decide what matters. It is being asked to express decisions that already exist.
The same five lines also make review faster.
Without a brief, I have to reread the whole draft and ask, "Is this good?" That question is too large. It turns review into taste arbitration.
With a brief, I can check five smaller questions:
That last question matters.
AI drafts often drift by making small invisible decisions. It adds a new example. It changes the implied reader. It turns a narrow claim into a general rule. It adds a confident conclusion that goes beyond the material.
A brief makes that drift easier to see.
It also makes feedback sharper. Instead of saying, "This feels generic," I can say, "The draft is no longer aimed at a team lead. It is now aimed at all AI users." That is a fixable problem.
The goal is not to avoid editing. The goal is to make editing inspectable.
Use this before the first prompt, not after the bad draft appears.
If the answer is no, do not ask for a better draft yet.
Ask yourself for a better brief.
Not exactly. Prompt engineering often focuses on how to phrase the instruction. This workflow focuses on what must be decided before the instruction exists.
The prompt is still important, but it is downstream. A clear prompt cannot fully compensate for an absent reader, absent takeaway, or absent material selection.
For small tasks, no. If the task is low risk and easy to review, a lightweight prompt is fine.
I use the full brief when the draft will be published, sent to stakeholders, used as a team reference, or reused later. The more expensive the review is, the more valuable the brief becomes.
That is fine as a brainstorming step, but keep it separate from drafting.
Ask for options first. Choose one yourself. Then draft from the chosen brief.
The failure mode is mixing brainstorming and drafting in one prompt. The model invents the target and writes toward it before you notice the target changed.
It makes the first minute slower and the review phase faster.
When I skip the brief, I usually pay later by rereading a polished draft that has no center. When I write the brief, the draft is narrower, and the edit has a target.
Yes. In fact, the brief is more valuable in a team because it externalizes decisions that otherwise stay inside one person's head.
For a team update, the author can write the brief, the reviewer can challenge the brief, and the AI can draft only after both agree on the target. That is a better review surface than asking everyone to comment on a full draft.
Here is the rule I keep coming back to:
Do not ask AI to find the point while it is writing the prose.
Find the point first.
Then let AI help with the prose.
That split sounds small, but it changes the texture of the work. You stop treating the model as a magic writer and start treating it as a drafting system with a clear contract.
The human work does not disappear. It moves earlier.
And because it moves earlier, the AI output becomes easier to judge.
The next time an AI draft looks fine but feels empty, do not start by asking for a better tone.
Fill the five-line brief.
Then draft.
I'm Sho Naka, publishing as nomurasan. I write about practical AI workflows, automation, and the places where human judgment still has to be made explicit.
This article was written with AI assistance for cross-language adaptation and editing. The workflow, examples, and final judgment are mine.