{"slug": "stop-fixing-your-ai-writing-prompt-make-these-5-decisions-first", "title": "Stop Fixing Your AI Writing Prompt. Make These 5 Decisions First", "summary": "A developer outlines a five-line editorial brief—audience, takeaway, material to use, first point to place, and scope delegated to AI—that should be filled before any AI writing prompt. The approach shifts decision-making back to humans, preventing polished but aimless drafts. The developer argues that without a specific reader and a clear takeaway, AI-generated prose remains weightless regardless of prompt refinement.", "body_md": "I used to fix weak AI drafts by asking for better prose.\n\n\"Make it clearer.\" \"Make it more persuasive.\" \"Make it sound less generic.\"\n\nThe output improved a little. Then it failed in the same place: the article looked polished, but nobody remembered what it was trying to say.\n\n**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.**\n\nDecide these five things before the first draft:\n\nThat is the difference between an AI writing prompt and an AI writing workflow.\n\nA 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.\"\n\nHere is the copy-paste version I now use before drafting:\n\n```\ncat > ai-writing-brief.md <<'BRIEF'\nAudience:\nTakeaway:\nMaterial to use:\nFirst point to place:\nScope delegated to AI:\nBRIEF\nOutput: a five-line brief that makes the human decisions visible before the AI starts drafting.\n```\n\nIf those five lines are empty, a better prompt usually will not save the article. It will only make the generic answer prettier.\n\nAI 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.\n\nAll of that can be correct and still useless.\n\nThe missing part is not grammar. It is aim.\n\nA 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.\n\nThat is when many people start polishing the prompt.\n\nThey 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.\n\nFor me, the uncomfortable lesson was this: a polished AI draft can hide the absence of an editorial decision.\n\nThe better the model gets at writing acceptable prose, the easier it becomes to miss the fact that nobody decided what the piece is for.\n\n\"Developers\" is not a reader. \"People interested in AI\" is not a reader. \"Everyone on the team\" is not a reader.\n\nThose labels are audiences in a marketing spreadsheet. They are too broad to guide a paragraph.\n\nA usable reader is closer to this:\n\nThe reader needs to be specific enough that you can make tradeoffs.\n\nIf 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.\n\nWithout that reader, the model does the safest possible thing: it writes for a vague average person.\n\nThat average person is often the reason AI writing feels like it came from nowhere and goes nowhere.\n\nHere is the test I use: can I name one real person who would benefit from this draft?\n\nNot a demographic. A person. Someone whose current confusion I can describe in one sentence.\n\nIf I cannot do that, I do not ask the AI to draft yet.\n\nA post is not a container for everything you know. It is a transfer of one useful idea.\n\nWhen 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?\"\n\nFacts are not the same thing as a takeaway.\n\nBefore drafting, I now write one sentence that finishes this phrase:\n\nAfter reading this, the reader should be able to...\n\nFor example:\n\nThat sentence becomes the spine of the draft.\n\nIt also gives you permission to cut good material.\n\nGood 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.\n\nPeople often treat AI like a bigger inbox: throw in all the notes, ask for a draft, then hope the model discovers the point.\n\nThat sometimes works for organization. It rarely works for judgment.\n\nAI is good at using material. It is less reliable at deciding why a piece of material deserves to survive.\n\nIf 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.\n\nThat is not intelligence failing. That is missing criteria.\n\nThe human has to decide what counts as evidence for this article.\n\nA simple table helps:\n\n| Material | Keep? | Reason |\n|---|---|---|\n| The incident that triggered the post | yes | It gives the reader a concrete pain point |\n| Background history of the project | maybe | Only keep what explains the decision |\n| Interesting side discovery | no | Save it for another post |\n| Exact wording of the final workflow | yes | The reader can reuse it |\n| Internal process details | no | They explain the author, not the reader's problem |\n\nThe important move is not the table. It is the act of forcing a reason.\n\n\"This is interesting\" is not enough. \"This helps the reader believe or use the takeaway\" is enough.\n\nSometimes 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.\n\nThe first draft answers, \"What material exists?\"\n\nThe human edit answers, \"What material belongs?\"\n\nThose are different questions.\n\nThe order in which something happened is rarely the order in which a reader should learn it.\n\nWork happens in time order. Understanding often does not.\n\nA 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.\n\nAI 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.\n\nThat is how readers get trapped in a lobby before they reach the room they came for.\n\nBefore drafting, I choose the first move:\n\nFor this article, the first move is the failure: asking AI to write better did not solve the problem.\n\nThat 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.\n\nOrder is not decoration. Order is part of the argument.\n\nThis is the decision people skip because it feels obvious.\n\n\"I am using AI to write.\" Fine, but which part of writing?\n\nWriting 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.\n\nThose are not equally safe to delegate.\n\nHere is my current split:\n\n| Task | I keep | AI can help |\n|---|---|---|\n| Choose the reader | yes | suggest alternatives |\n| Choose the takeaway | yes | test clarity |\n| Select material | yes | group and summarize |\n| Decide order | mostly | propose variants |\n| Draft paragraphs | no | yes |\n| Smooth tone | no | yes |\n| Shorten without losing meaning | review | yes |\n\nThe key phrase is \"AI can help,\" not \"AI owns.\"\n\nIf 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.\n\nA useful test is whether I can reject the model's suggestion quickly.\n\nIf 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.\n\nDelegation works best where the human has taste, context, and the ability to say no.\n\nIt works poorly where the human is hoping the model will create the judgment the human has not yet made.\n\nHere is the complete version.\n\n```\nAudience: A specific person or role, with their current confusion.\nTakeaway: One sentence that says what the reader should be able to do or believe after reading.\nMaterial to use: The examples, logs, notes, or facts that directly support the takeaway.\nFirst point to place: The opening move that makes the reader keep reading.\nScope delegated to AI: The parts the model may change, and the parts it must not decide.\n```\n\nAnd here is a filled version for this article:\n\n```\nAudience: A developer or team lead whose AI-written posts look polished but feel generic.\nTakeaway: A better prompt starts with human editorial decisions, not more wording tricks.\nMaterial to use: Failed polished drafts, weekly-report examples, material-cutting examples, and a reusable brief.\nFirst point to place: I tried asking AI to write better, and it did not fix the problem.\nScope delegated to AI: The model may help phrase and compress, but it must not choose the reader, takeaway, or cuts.\n```\n\nNotice how little of this is prompt magic.\n\nThere is no special jailbreak. No hidden roleplay. No giant system message.\n\nThe brief is boring on purpose. It forces the missing decisions into visible text.\n\nAfter that, the prompt can be simple:\n\n```\nUsing 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.\n\n[brief here]\n```\n\nThe more clearly I write the brief, the less dramatic the prompt needs to be.\n\nHere is the kind of prompt that used to give me a polished but forgettable article:\n\n```\nWrite an easy-to-understand article about how to use AI for writing. Make it practical and engaging. Include examples and a conclusion.\n```\n\nNothing in that prompt is offensive. It is just empty of decisions.\n\nWho is the reader? Unknown.\n\nWhat should they do after reading? Unknown.\n\nWhich examples matter? Unknown.\n\nWhat should come first? Unknown.\n\nWhat should the AI not change? Unknown.\n\nNow compare it with the brief-based version:\n\n```\nAudience: A developer who uses AI to draft team updates but keeps getting generic reports.\nTakeaway: They should define the reader, takeaway, material, order, and AI scope before drafting.\nMaterial to use: Weekly report example, meeting-note example, and five-line brief.\nFirst point to place: A polished report can still fail if the reader cannot see the decision.\nScope delegated to AI: Improve language and structure, but do not invent a different reader or takeaway.\n\nDraft the article from this brief. Use a practical tone, short paragraphs, and include a copy-paste checklist.\n```\n\nThe second prompt is not better because it is longer. It is better because the judgment is already present.\n\nThe AI is no longer being asked to decide what matters. It is being asked to express decisions that already exist.\n\nThe same five lines also make review faster.\n\nWithout 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.\n\nWith a brief, I can check five smaller questions:\n\nThat last question matters.\n\nAI 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.\n\nA brief makes that drift easier to see.\n\nIt 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.\n\nThe goal is not to avoid editing. The goal is to make editing inspectable.\n\nUse this before the first prompt, not after the bad draft appears.\n\nIf the answer is no, do not ask for a better draft yet.\n\nAsk yourself for a better brief.\n\nNot exactly. Prompt engineering often focuses on how to phrase the instruction. This workflow focuses on what must be decided before the instruction exists.\n\nThe prompt is still important, but it is downstream. A clear prompt cannot fully compensate for an absent reader, absent takeaway, or absent material selection.\n\nFor small tasks, no. If the task is low risk and easy to review, a lightweight prompt is fine.\n\nI 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.\n\nThat is fine as a brainstorming step, but keep it separate from drafting.\n\nAsk for options first. Choose one yourself. Then draft from the chosen brief.\n\nThe 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.\n\nIt makes the first minute slower and the review phase faster.\n\nWhen 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.\n\nYes. In fact, the brief is more valuable in a team because it externalizes decisions that otherwise stay inside one person's head.\n\nFor 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.\n\nHere is the rule I keep coming back to:\n\nDo not ask AI to find the point while it is writing the prose.\n\nFind the point first.\n\nThen let AI help with the prose.\n\nThat 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.\n\nThe human work does not disappear. It moves earlier.\n\nAnd because it moves earlier, the AI output becomes easier to judge.\n\nThe next time an AI draft looks fine but feels empty, do not start by asking for a better tone.\n\nFill the five-line brief.\n\nThen draft.\n\nI'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.\n\nThis article was written with AI assistance for cross-language adaptation and editing. The workflow, examples, and final judgment are mine.", "url": "https://wpnews.pro/news/stop-fixing-your-ai-writing-prompt-make-these-5-decisions-first", "canonical_source": "https://dev.to/nomurasan/stop-fixing-your-ai-writing-prompt-make-these-5-decisions-first-51gk", "published_at": "2026-07-07 03:22:54+00:00", "updated_at": "2026-07-07 03:58:14.109219+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "generative-ai", "ai-tools", "developer-tools"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/stop-fixing-your-ai-writing-prompt-make-these-5-decisions-first", "markdown": "https://wpnews.pro/news/stop-fixing-your-ai-writing-prompt-make-these-5-decisions-first.md", "text": "https://wpnews.pro/news/stop-fixing-your-ai-writing-prompt-make-these-5-decisions-first.txt", "jsonld": "https://wpnews.pro/news/stop-fixing-your-ai-writing-prompt-make-these-5-decisions-first.jsonld"}}