Writing Makes the Problem Visible

A vocabulary gives you lenses. Writing lets you point them.

Imagine two managers asking the same AI model to help announce a delayed product launch. The first writes: “Create an exciting, compelling announcement about our delay. Make it sound positive and professional. Include everything customers need to know.” The result is polished, upbeat—and potentially disastrous. It may blur the reason for the delay, promise a new date the company cannot guarantee, or celebrate a change customers find frustrating.

The second manager makes the task specific: “Draft a 150-word email to customers who preordered our home air-quality monitor. The launch is delayed because final testing found inconsistent readings. We don’t yet have a confirmed shipping date. Be direct and apologetic; don’t minimize the testing issue or promise a date. Tell customers they can request a refund by replying to the email. Use only the facts provided.”

The difference is not a magic phrase, a special prompt trick, or superior vocabulary. It is a clearer brief. The second manager has made the important decisions visible, so the model has less room to guess.

Revise the thinking inside the sentence

Look closely at what changed between the two launch requests. “Make it sound positive” became a decision about what customers need: an honest explanation and a way to request a refund. “Include everything” became a small set of known facts. An unspecified promise became an explicit uncertainty: there is no confirmed shipping date. These are ordinary acts of good writing—choosing a purpose, naming the subject, and making the meaning exact.

Here is a smaller example. Suppose your rough instruction says:

Tell them it should be ready soon, but don't overpromise, and make the problem sound less serious.

Before improving the style, examine the meaning. Who are “them”? What is “it”? Is “soon” supported by a date? Does “less serious” mean explaining the issue calmly, or concealing its significance? A smoother version could preserve every one of those problems.

A clearer revision would say:

Tell preorder customers that testing found inconsistent readings in the monitor. We do not yet have a confirmed shipping date. Explain this calmly and apologize for the delay. Include the refund option. Do not describe the issue as minor; we have not established that.

This revision changes what the model has to work with. The reader and product are named. The known fact and the unknown date are separated. The tone no longer conflicts with the obligation to explain the problem.

A possible sentence from the resulting draft might be: “Final testing found inconsistent readings in the monitor, so we are delaying shipment; we do not yet have a confirmed shipping date.” Compare that with “We're making a few final improvements and expect to ship soon.” The second sounds reassuring, but introduces a description and an expectation the supplied facts do not support. The first gives you wording you can check directly against those facts. These are illustrative drafts, not a promise about what a model will produce.

Practice this kind of revision on a request you actually need to send. Replace an unclear pronoun with its subject. Replace “better” with the change you want. Separate what happened from why you think it happened. Remove an adjective that asks for an effect you cannot justify. Then read the instruction as though you knew nothing beyond what appears on the page. Whatever you still have to guess is a candidate for clarification.

A brief is a map of the task

A brief does not need to be long. It needs to distinguish what matters. Think of it as a small map: it tells the AI where you are trying to go, who is traveling, what terrain to avoid, and what would count as arriving.

Five elements do much of this work:

• Goal: What should the response accomplish?
• Audience: Who will read or use it, and what do they need?
• Context: What facts, circumstances, or source material should shape the answer?
• Constraints: What must be included, avoided, limited, or treated as uncertain?
• Evidence or format: What should support the answer, and what form should it take?

Each element makes a different decision explicit. The goal defines the intended outcome; the audience shapes tone and level of explanation; context connects the request to the actual situation; constraints mark boundaries; and evidence or format makes the response easier to use for its particular purpose.

Consider the request, “Help me improve our newsletter.” It might mean increase subscriptions, reduce cancellations, make the writing clearer, or sell more products. Those goals can conflict. A short brief—“Suggest three ways to make our monthly newsletter easier for current customers to scan; prioritize clarity over sales language”—gives the AI a direction and a trade-off.

The word trade-off matters here. A request to make something “more engaging” may lead to jokes, dramatic headlines, or a warmer voice. A request to make it easier to scan while preserving a calm, informative tone narrows the choices. Clear writing does not remove creativity. It gives creativity a useful playing field.

Specificity without ceremony

People sometimes respond to uneven AI results by making prompts elaborate: role-play instructions, long lists of adjectives, repeated warnings, and elaborate rituals about how the model should think. Some extra detail can help, especially when it conveys relevant context. But length is not the same as clarity. A beautifully decorated instruction can still fail to say what success looks like.

A simple test is to ask: What would a competent colleague need to know before doing this well? If you would explain the audience, deadline, source material, or boundaries to that colleague, they probably belong in the brief. If a detail does not affect the task, it may be clutter.

For instance, “Write a persuasive proposal” leaves crucial questions open. Persuasive to whom? Seeking what decision? Based on which facts? A compact revision could say: “Write a one-page proposal for the school principal, asking approval for a six-week reading pilot. Use the attached budget and schedule. Emphasize how we will assess participation; do not claim the pilot will improve test scores.” This request establishes purpose, audience, context, a constraint, and a usable format without turning into a ceremonial scroll.

There is also value in stating what you do not know. “We have not yet measured whether the pilot improves reading outcomes” is useful context. When information is missing, ask the model to identify assumptions or ask clarifying questions rather than silently filling gaps.

Make success inspectable

A brief is easier to use when it gives you a task-specific standard for reviewing the answer. “Make it good” is not a standard. “Give me three options, each with an estimated cost, the main risk, and one reason it might not work” is closer: you can see whether the response meets the request.

When factual claims matter, ask for evidence in a form that supports checking: identify the source documents to use, request citations or quotations where available, and distinguish what those sources say from what the model infers. A citation is not proof merely because it looks official; important references still need to be opened and checked. For creative work, the standard may be different: match a particular audience, keep within a word limit, or preserve the meaning of a supplied passage.

Before you send a request, try writing its goal in one sentence. Then add only the audience, context, constraints, and evidence or format that could change the answer. If those details are hard to name, that may be a clue that the task itself still needs thinking. Writing the brief is not paperwork before the work. Often, it is where the work becomes clear. This is the first move in Specify, Inspect, Verify: make the task clear enough to assess, then read the result against the standards you set.

A clear brief gives an AI a direction. It does not mean you must know the whole route before you start. Often, the first answer is most useful as a sketch: something concrete enough to react to, but not something you should accept simply because it arrived in polished paragraphs.

Imagine a small business owner asking for ideas to bring more customers into a neighborhood bakery. The first response offers a familiar assortment: launch a loyalty program, post on social media, partner with nearby businesses. Plausible, tidy—and nearly useless until she knows what problem she is actually trying to solve.

Instead of asking the model to “make the ideas better,” she can ask a more revealing question: Which of these approaches is most likely to bring in new weekday customers, rather than reward people who already visit? The answer may expose a mismatch. A loyalty program mainly serves regulars; a lunchtime partnership might reach new people. Now the conversation has moved from collecting suggestions to examining the goal.

That is the point of iteration. You ask for an initial direction, inspect it, and use what you notice to shape the next question. The AI supplies possibilities; your response supplies the steering. In this sense, refinement is another way to specify: each useful follow-up makes the real task, its constraints, or its standards more visible.

Treat the first answer as a draft of the problem

An answer can reveal what your request left open. Perhaps it assumes a large budget, treats all customers as alike, or offers tactics without saying how to judge them. Those gaps are not always mistakes. They may be clues about what you need to specify.

You might follow up: We have little budget and one person who can manage the campaign. Give me three options that can be tested in two weeks, and explain what evidence would count as success. This does more than demand a shorter list. It adds constraints and a standard for comparison.

Then ask for alternatives that differ meaningfully, not three variations on the same suggestion. For the bakery, the options might target nearby office workers, passersby, or current customers who could refer someone new. Seeing those approaches side by side helps the owner notice which audience she actually wants to reach—and which trade-offs she is willing to accept.

Compare against criteria, not charm

Fluent answers can make weak ideas feel finished. Comparison helps interrupt that spell. Put the options against criteria you care about: cost, effort, likely reach, speed of learning, or fit with the bakery’s character. Ask the model to explain the trade-offs, but do not confuse its explanation with proof. If a recommendation depends on local foot traffic or customer habits, those are facts to check, not details to admire in a confident paragraph.

The criteria may change as you compare. Perhaps the owner first thought low cost mattered most, then realized that learning quickly mattered more: a modest test that reveals which offer attracts first-time visitors may be better than a cheaper campaign with no clear way to assess it. Comparing versions can help her discover her priorities, not merely select from a menu; it does not establish that any option will work.

Useful follow-up questions are specific enough to change the answer: What assumption is this option making? What would make it fail? Which alternative serves a different audience? What evidence could distinguish these two approaches? If the response remains vague, narrow the task again. If an important claim is factual, seek a reliable source or test it in the real world.

The exchange need not become an endless polishing session. Stop when you have a direction that fits the goal, understand its main trade-offs, and know what still needs checking. Iteration is not asking the machine to keep talking until you feel reassured. It is a way to make your own judgment more informed—and your next question more exact. Inspect what the answer actually says, then verify the claims that matter before acting.

Once you know what you want to ask next, you do not have to type it. Voice can make working with AI feel less like filling out a form and more like thinking aloud with a patient partner. You can explore an idea while walking, dictate a rough explanation, or ask a question without wrestling with a keyboard. For people who find typing difficult or inaccessible, speech can also make the interface more usable. That is not a minor convenience; an interface is only helpful if people can use it.

Spoken conversation is especially good at opening things up. You can say, “I’m not sure what I think yet—help me sort it out,” then follow the thread that surprises you. A conversational system can respond, and you can interrupt, clarify, or change direction. The exchange has some of the looseness of a meeting in which the first useful idea was not on the agenda.

But looseness is not always what a task needs. Imagine asking AI to help draft a message to a client about a delayed project. Speaking may be the quickest way to explain what happened. Yet a written brief lets you inspect the details before they become instructions: the delay is three days, the cause is a supplier problem, the client has not been told, and the message should be candid without making promises the team cannot keep. On the page, an omitted constraint is easier to notice. So is a sentence that quietly claims more than you know.

Writing is useful here not because it is more formal, but because it slows intention down enough to examine it. You can revise a phrase, reorder priorities, and separate what is known from what is hoped. A sentence can be read twice before the machine acts on it. That pause is a small form of quality control.

Writing also leaves a record. A spoken exchange may be transcribed, but a carefully shaped written instruction or summary is easier to share, compare, and return to later. If an AI helps a team assess three proposals, a written record of the criteria—cost, implementation time, and risk—makes it possible to see whether the same standards were applied to each. It also gives people something concrete to challenge. “That feels wrong” can become “This option was rated highly on cost, but the analysis did not include maintenance.”

The distinction is not speech versus writing, as though one must win. Speech is often a good way to discover what you mean; writing is often a good way to settle what you mean. You might talk through a problem, then ask the AI to summarize the assumptions and open questions. Read that summary, correct it, and use the revised version as the basis for the next step. The machine’s words become a draft of your thinking—not a substitute for checking it.

When the stakes are low, speak and explore. When instructions are complex, decisions consequential, or details easy to lose, put the important parts in writing. And when the answer matters, keep enough of the exchange to inspect what was asked, what was assumed, and what still needs verification. Conversation helps you move; writing helps you see where you are going.