Syntax Planet

AI

Why Your AI Output Is Mediocre, and It Is Not the Prompt.

By Muhammad UmarMay 16, 20265 min readIssue #17

Working on something like this? Tell me about it →

Stop prompting. Start briefing. The gap is almost never phrasing, and rewriting the request cannot close it.

Placeholder. Artwork for this article has not been made yet.

You write a careful request. The output comes back competent, generic, and not what you wanted.

So you rewrite it. You add "be detailed". You add "act as an expert in this field". You try being firmer, then more polite, then you find a template someone posted and use that instead.

The output changes slightly. It is still generic.

At this point most people conclude the model is not very good, or that there is a technique they have not learned yet. Usually it is neither. You are editing the phrasing of a request whose problem is missing information, and no amount of rewording adds information that was never in the message.

The problem: you know things the model cannot

Imagine handing the same task to a contractor who starts tomorrow morning. Competent, experienced, and completely new to your situation.

You would not expect a good result from one sentence. Not because they lack skill, but because they do not know who reads this, what went wrong with the last version, which parts are politically sensitive, or what you will refuse to sign off.

None of that is in the request. It is in your head, and it has been there so long that it does not feel like information any more. It feels like context that any reasonable person would have.

A large circle holding everything you know about a task, with a small shaded circle inside it marked as what was actually sent. An arrow carries only the small circle across to the model.

Rewriting the prompt rearranges the small circle. That is why the fifth attempt reads much like the first: you keep changing how you say the same insufficient thing.

The model is not misunderstanding your request. It is answering a much vaguer question than the one in your head, and answering it reasonably.

Why role prompts do so little

It is worth being specific about the most popular non-fix.

Telling a model to act as a senior engineer adjusts register and vocabulary. It cannot supply the facts a senior engineer in your company would have, because those facts are about your company and they are not in the message.

So you get the voice of expertise applied to the same thin brief, which is arguably worse than before. Generic output that sounds hedged is easy to spot. Generic output that sounds authoritative is not.

The fix: brief it like a contractor

Four things, and they take a few minutes to write once. Most of what people call prompt engineering is a substitute for one of them.

What it is for, and who reads it

Almost all weak output is aimed at nobody in particular, because the request did not say who it was for.

The same summary written for a client, a compliance reviewer, and the engineer who will implement it are three different documents. Ask for "a summary" and you get the average of all three, which serves none of them.

What good looks like

This is the one with the largest effect and it is the one people skip, because it takes thirty seconds of searching and adjectives take none.

Paste a previous piece of work you were happy with. Not as a template to fill in, just as an example of the target. One real example carries more than a paragraph of description, because your standards live in details you have never articulated: how long, how formal, how much hedging, whether you use headings, where you stop explaining.

You do not know those rules explicitly. That is exactly why you cannot write them down and exactly why the example works.

Constraints, as constraints

There is a difference between hoping for something and stating it. "Keep it fairly short" is a hope. "Under 300 words, four sections, no introduction" is a constraint.

Anything you would reject the work for is a constraint, and if it is not written down you will discover it by rejecting the work.

What it must not do

The most commonly missing part, and the one that saves the rewrite.

Do not invent numbers. Do not mention the pricing. Do not restructure the existing sections. Do not recommend anything we cannot deliver. Every one of those is something you know and would never have thought to say, and each one is a rewrite you will otherwise pay for.

How to tell which problem you have

There is a quick test, and it works before you start rewriting anything.

Read the output as though a new contractor produced it from exactly what you sent. Would you consider it a fair attempt?

If yes, you have a briefing problem. The work is a reasonable response to the request you actually made, and the fix is more context, not different words.

If no, and a person given that message would have done clearly better, then you have a genuine prompting problem: an ambiguous instruction, a buried requirement, a question that could be read two ways. Those exist and they are worth fixing. They are a much smaller share of cases than the rewriting behaviour suggests.

The tell that you are in the first situation and treating it as the second is attempt number four. Nobody rewrites the same sentence four times because it was unclear. They do it because rewriting feels like progress and gathering context feels like admin.

When briefing is the wrong move

When the task genuinely carries no context. Reformat this list. Convert this to a table. Fix the grammar. There is nothing in your head that the work depends on, so a one-line request is the correct size and adding a brief wastes your time.

When writing the brief costs more than doing the work. If explaining the situation properly takes twenty minutes and the task takes fifteen, do the task. This is the same boundary as the one where verification costs as much as doing, approached from the other side.

When you do not know what good looks like yet. If you cannot name the audience or produce an example, the problem is not the brief. You have not decided what you want, and no amount of context will supply a decision you have not made. That is worth noticing rather than delegating, because it is the actual work.

The takeaway

Prompting is a real skill and it is a much smaller one than it is treated as. Once a request is unambiguous, further polishing has very little left to do.

What is left is the thing that was always the bottleneck when handing work to anyone: they cannot see what you can see. Write down the part you have stopped noticing you know, and most of what you were trying to fix with phrasing fixes itself.