Prompting is a delegation skill wearing a technical name

Everyone has access to the same models. Same interface, same context window, same weights. Yet two people sit down with the same tool and one walks away with a working feature while the other walks away convinced the whole thing is overhyped.

The usual explanation is that the second person doesn’t know "the tricks." Wrong. There is no secret list. The gap is not technical, and that is exactly why it is hard to close.

The name is the first problem

Calling it "prompt engineering" makes people look for the wrong thing. Engineering implies syntax, parameters, a manual. So people go hunting for magic phrases: "act as a senior developer," "think step by step," "you are an expert in." They collect incantations.

Then they use those incantations on a vague request and get a vague answer, dressed up in a confident tone. The phrases were never the point. What the good prompters are doing is not casting spells, it is specifying work.

Most people don’t know what they want

This is the real bottleneck, and it is uncomfortable to admit.

A good prompt forces you to define the output before you see it. Format, constraints, scope, what to exclude, what "done" looks like. Most people start with a fuzzy intention and hope the model will sharpen it for them.

It won’t. It will produce something in the shape of an answer, which is worse than producing nothing, because now you have something to react to instead of something to think about.

If you have ever received a ticket that said "make the dashboard better," you already understand this failure mode. The model is that developer, except it never pushes back and never asks what you meant.

You cannot judge output you don’t understand

Here is the trap that keeps beginners stuck. Model output is fluent. Fluency reads as competence.

If you don’t know the domain, a generic answer looks like a good answer. You have no way to tell the difference between "this is the standard approach" and "this is the average of everything ever written about this topic, which means it fits nobody." So you accept it, ship it, and never learn what a better version would have looked like.

Expertise is not what lets you write the first prompt. It is what lets you look at the response and say: this is boilerplate, go deeper, you missed the constraint that actually matters here.

Which produces an unfair loop. The people who least need the help are the ones who extract the most value from it.

Two broken mental models

Almost every struggling user is running one of these:

The search engine model. Keywords, no context, no goal. "React state management." You get an encyclopedia entry. You wanted a decision for your specific app.

The mind reader model. The opposite failure. They talk to the model like a teammate who was in yesterday’s meeting, who knows the codebase, who remembers what the client rejected last week. "Fix the bug in the checkout flow." Which bug. Which flow. Which project.

It is neither of those things. It knows what is in front of it right now, and nothing else. Everything you leave out, it invents.

They ask once

Good prompting is rarely one shot. It is three to five rounds of narrowing: ask, read, correct, constrain, ask again.

Most people ask once, get sixty percent quality, and stop. Then they conclude the tool is weak. The tool was fine. The conversation ended early.

Iteration feels like failure to people who expect a machine to be right the first time. It isn’t failure, it is the actual method. Nobody expects to write a feature in one commit.

It is tacit knowledge, so nobody can hand it to you

You cannot read your way to this. You calibrate by volume, the same way you built debugging intuition.

Over hundreds of exchanges you start to feel which phrasings collapse into filler and which ones force a commitment to specifics. You learn that "write me a landing page" gets you a template, while a page with a stated audience, a stated action, a design reference and a hard exclusion list gets you something usable. Nobody taught you that. You noticed it.

That is why the guides disappoint. They can only give you the vocabulary. The judgment is earned.

The actual predictor

If I had to guess in advance who will be good at this, I would not ask about their technical background. I would ask one question: are you good at delegating to people?

Can you write a task that a developer picks up and finishes without coming back to you five times? Do you specify the constraints, the edge cases, the definition of done? Or do your handoffs end with "you know what I mean"?

Because prompting is delegation with the safety net removed. A human colleague protects you from your own vague brief. They ask the clarifying question. They notice that what you asked for makes no sense and check before burning a day on it.

The model doesn’t. It fills your gaps silently and hands you something confident and wrong. Vague managers get bad output from AI for the same reason they get bad output from teams. The tool just removed the buffer that used to hide it.

What to actually do

Concrete version, if you want to get better this week:

• Write the acceptance criteria before the request. If you cannot describe what a correct answer looks like, you are not ready to ask.
• State the constraints, not just the goal. Stack, audience, length, tone, what to avoid. Exclusions do more work than instructions.
• Give one example of good. A reference, a sample, an existing file. One example beats a paragraph of adjectives.
• Treat the first answer as a draft, always. Your second message is where the value is.
• Say what was wrong, specifically. "Too generic" is not feedback. "You gave me five options, I need one recommendation with the tradeoff stated" is feedback.
• Reuse what worked. When a prompt produces something good, save it. Build a pack, not a memory.

None of that is a trick. It is just the discipline of writing a clear brief, which was always the hard part, long before any of this existed.

Yes, this article was prompted. That is the argument, not a confession. The prompt behind it carried a thesis, a tone, a list of things to exclude, and a specific ending to land. Anyone can type "write an article about prompt engineering" and get eight hundred words of nothing. The skill was never in the typing. It was in knowing what to ask for.