Prompt Engineering

You type "Write this up for me" and paste in some notes. The model answers, but the answer is too long, uses bullet points you did not want, and focuses on the wrong part of the notes. You correct it. It tries again. A few messages later you have what you wanted from the start.

Prompt engineering is the practice that removes those extra messages. It means writing the request so that the first answer that comes back is the one you wanted. The previous lesson explained that the prompt is the one part of the model's input that a user writes and can change. This lesson is about writing that part well.

The name sounds technical. The activity is not. It is the same thing a person does when briefing a colleague clearly. After this lesson you can take a vague request and turn it into a complete one, name the parts you added, and explain why the vague version cost more time.

1. Wording matters less than it did, and it still matters

The exact wording of a prompt used to decide much more of the result than it does now.

With early models, a small change in phrasing could turn a useless answer into a good one. The model could not fill in what the user left out, so the wording had to carry everything. People collected special phrases and tricks, and that period gave prompt engineering its reputation as a specialist skill.

Current models are much better at working out what a person probably means. Even a fairly vague prompt often gets a good result.

The influence of wording has dropped, but it has not dropped to zero, and it cannot. No model can know facts that exist only in your head: how long you want the answer, who will read it, or what a word means inside your team. If the prompt does not say these things, the model has to guess. A more capable model guesses better, and it is still guessing.

2. One job, specified piece by piece

Take a real job. You had a call on Tuesday, you have rough notes, and you want a write-up to send to your team. Here is the prompt in four stages, each adding one kind of information.

Each stage answers something the first version left open.

The task. "Write this up" could mean a summary, a formal report, an email, or meeting minutes. "Turn Tuesday's call notes into a summary" names both the material and the result.

Constraints. A constraint is a limit the answer must stay inside. "Under 300 words" is a constraint. Without it, the model chooses a length, and its choice may be three times what you had in mind.

The output. This is the shape of the answer. "Headings, not bullets" tells the model how to lay the text out. Other examples are "a table with two columns" or "one paragraph".

Definitions. Some words mean something specific to you. The notes use the word "blocker". The model knows the general meaning, but the prompt states the meaning that applies here: a blocker is whatever stopped work. Now the model can decide which items in the notes count as blockers.

Style. "Keep it plain" sets the tone. Without it, the model may write in a formal or enthusiastic voice that does not fit a team update.

Put together, the complete prompt reads:

Turn Tuesday's call notes into a summary.
Under 300 words. Headings, not bullets.
A blocker is whatever stopped work. Keep it plain.

[ call notes pasted here ]

This is four short lines in place of four words. It takes about two minutes longer to write.

3. What the extra two minutes save

Compare what happens after each version is sent.

On the left, the first answer is a guess at what you meant. You read it, find what is wrong, explain the problem, and wait for a second attempt. Often there is a third.

On the right, the model had the information before it started, so the first answer fits.

The extra two minutes spent on the prompt are usually less than the time spent reading and correcting wrong answers.

4. The cost of going back and forth

Sometimes the model does not guess. It asks. Here is how the vague prompt can play out:

you:     Write this up for me.
model:   Happy to. How long should it be?
you:     Short.
model:   And which parts of the call matter most?
you:     ... is it really this dumb?

Each message to the model and reply back is called a round trip. After four exchanges, this conversation has not produced a single line of the write-up. One complete sentence at the start would have covered both of the model's questions.

The round trips cost more than patience. As the lesson on context explained, the whole conversation is sent to the model again with every message. So each extra round trip sends the notes and all earlier messages again, which uses more tokens. On a pay-per-token plan this costs money, and on a subscription it uses up the allowance faster.

5. The model answered what was asked

The frustrated last line in that conversation asks whether the model is unintelligent. It is not. It answered the question that was asked.

"Write this up for me" does not say how long, for whom, or about what. Those are real gaps. A model that asks about them is handling the request correctly. A human assistant given the same four words and a page of notes would have to ask the same questions, or guess.

So a disappointing answer is very often a sign of a prompt with gaps, not of a weak model. Before blaming the model, read the prompt as if you knew nothing except what it says, and check whether a stranger could do the job from those words alone.

6. Briefing a model is like briefing a colleague

Imagine handing the same job to a colleague. You would not say four words and walk away. You would tell them three things.

The two columns hold the same information under different names. When a person explains a job clearly to a colleague, nobody calls it engineering. When a person does it for a model, it is called prompt engineering. The word means describing what you want efficiently, and nothing more unusual than that.

The comparison holds in one more way and breaks in another. It holds because a model, like a new colleague, knows nothing about your project except what you tell it. It breaks because a colleague learns over time and needs less explanation next month, while a model starts from nothing in every new conversation unless the app adds saved information for it.

7. A checklist for a complete prompt

The parts from this lesson can be used as a checklist before sending a request.

Not every prompt needs all five. "What is the capital of France" needs none of them. The longer or more specific the result you have in mind, the more of them are worth writing.

Two other additions are widely used. One is naming the reader, for example "for people who were not on the call", because the audience changes what needs explaining. The other is giving a short example of the result you want, because a model follows a pattern it can see more reliably than a description of the pattern.

Interview points

• Prompt engineering is writing a prompt so that the first response is the intended one, which reduces correction turns.
• A complete prompt states the task, the constraints, the output format, any definitions of ambiguous terms, and the style. Naming the audience and giving an example are common additions.
• Early models depended heavily on exact wording because they could not infer missing intent. Current models infer much more, so a vague prompt often works, but the effect of wording never reaches zero.
• A model cannot know information that exists only in the user's head, such as desired length, audience, or team-specific meanings. If the prompt omits it, the model guesses or asks.
• A vague prompt leads to extra round trips. Each one resends the whole conversation, so it costs time and tokens.
• A poor answer to a vague prompt usually reflects missing information in the prompt, not a lack of capability in the model.
• Briefing a model needs the same information as briefing a colleague: what the job is, what it must not be, and what finished looks like.

Summary

• Prompt engineering means describing what is wanted clearly and completely.
• Wording decides less than it once did, and it still decides something.
• Task, constraints, output format, definitions, and style turn a vague request into a complete one.
• A complete prompt takes a little longer to write and saves correction rounds.
• Extra round trips cost time and tokens.
• A model answers the question it was asked, so gaps in the prompt become gaps in the answer.