Prompt Engineering 101: Talk to AI Better

1. What a prompt is really doing

2. Few-shot prompting and role-play

prompt = """
You are a customer support classifier.
Label each message as Positive, Negative, or Neutral.

Examples:
Message: Thanks, that fixed it.
Label: Positive

Message: This still does not work.
Label: Negative

Message: I have a question about billing.
Label: Neutral

Now label:
Message: The update helped a lot, but login is still slow.
Label:
"""

print(prompt)

3. Reasoning prompts, chain-of-thought, and self-consistency

4. Debugging prompts systematically

{
  "name": "Mina",
  "role": "data analyst",
  "task": "Summarize the chart in two sentences",
  "output_format": "JSON with fields summary and risk"
}

5. Advanced patterns and a practical workflow

note

Advanced prompt patterns

Self-consistency

Use multiple sampled reasoning paths and choose the most common answer.

Tree-of-thought

Explore several branches, score them, and keep the best path.

Structured output

Use schemas, tables, or JSON when another system depends on the result.

Practical workflow

• Write the task in one sentence
• Choose free-form or structured output
• Add examples if the task is ambiguous
• Test on real cases
• Revise one variable at a time

Decision rule

Human reader: free-form

Software reader: structured

Hard reasoning: step-by-step plus sampling

Exploration: tree-of-thought

diagram

illustration

equation

$$\text{Expected utility} = \text{Answer quality} - \text{Latency cost} - \text{Parsing cost}$$

Transcript

Welcome to Slate. Today we're looking at Prompt Engineering 101: Talk to AI Better. We'll cover Core prompting techniques: few-shot, chain-of-thought, role-play, How to debug and iterate on prompts systematically, When to use structured output vs. free-form, and Advanced patterns: self-consistency, tree-of-thought. Let's get into it.

A prompt is not a magic phrase. It is instructions plus examples plus constraints. The model reads your words and predicts the next token, one step at a time. That means small wording changes can shift the output a lot. Here’s the mental model: you are not commanding a person. You are shaping a probability machine. The most useful prompt has four parts. First, the task. Second, the context. Third, the format. Fourth, the quality bar. For example, “Summarize this article” is weak. “Summarize this article for a busy product manager in three bullets, using plain language, and include one risk” is much better. The diagram shows why: each extra constraint narrows the search space. Think of prompting like giving directions in a city. “Go downtown” is vague. “Take the blue line to Central, exit on 5th, and stop at the library” gets you there faster and with fewer wrong turns. There is one more key idea: the model does not truly know your intent unless you make it explicit. If you want a table, say table. If you want JSON, say JSON. If you want a tone, name the tone. Clarity beats cleverness almost every time.

Few-shot prompting means showing the model examples before asking for the real answer. The examples act like a stencil. They tell the model what pattern to copy, not just what topic to discuss. This is especially useful when the task is subjective, repetitive, or format-sensitive. Here’s a concrete case. Suppose you want product reviews labeled as positive, negative, or neutral. One example may help a little. Three well-chosen examples help much more, because the model sees the boundary between categories. The examples should be close to the real task. Random examples are noise. Role-play is different. You assign a perspective, like “You are a tax accountant explaining this to a freelancer.” That does not make the model smarter, but it changes the style, priorities, and vocabulary it uses. It is a shortcut to domain framing. A strong trick is to combine both. Give the role, then give examples, then ask for a new item. That is like showing a cook the dish, naming the cuisine, and then asking for the next plate. The model follows patterns much better when the pattern is visible.

Some tasks need reasoning, not just pattern matching. That is where chain-of-thought prompting comes in. The idea is to ask the model to work through the problem step by step before giving the final answer. The benefit is usually better accuracy on multi-step tasks like arithmetic, logic, planning, and code debugging. But there is a catch. You do not always need the model to expose every internal step. In many products, it is better to ask for a brief explanation or a short solution path, not a wall of hidden reasoning. The goal is better answers, not longer answers. Self-consistency is a powerful extension. Instead of trusting one reasoning path, you sample several and choose the most common final answer. This was described by Xuezhi Wang and colleagues in 2022. It works because one bad chain can fail, but a majority vote across several chains is more robust. Think of it like asking three mechanics before replacing a part. Tree-of-thought goes further. The model explores multiple branches, evaluates them, and keeps the promising ones. That is useful for puzzles, strategy, and open-ended planning. It is slower and more expensive, but it can beat a single straight-line answer when the problem has many possible paths.

Prompt debugging is closer to software debugging than to writing poetry. Start by naming the failure mode. Did the model misunderstand the task, ignore a constraint, invent facts, or use the wrong format? Once you know the bug, you can fix the right layer. A useful sequence is: simplify, isolate, test, then add constraints back. If a prompt fails, strip it down to the minimum version that still fails. That reveals whether the problem is the task, the examples, or the formatting. Then change one thing at a time. This is the same logic as diagnosing a noisy engine: you do not replace every part at once. Structured output helps debugging because it is easier to check. If you need reliable downstream parsing, ask for JSON or a table. If you want creativity, free-form text gives the model more room. The tradeoff is control versus flexibility. A good prompt is rarely perfect on the first try. The best practitioners keep a small test set of real examples and run their prompt against them repeatedly. That turns prompt writing from guesswork into an experiment.

Advanced prompting is about control. Self-consistency helps when one answer path is brittle. Tree-of-thought helps when the problem needs exploration. Structured output helps when another system has to read the result. The right choice depends on the job, not on what sounds sophisticated. A practical workflow is simple. First, define the task in one sentence. Second, choose the output shape. Third, add one or two examples if the task is ambiguous. Fourth, test on real inputs. Fifth, record failures and fix the weakest point. That loop is how prompt engineers work in practice. Here is a useful rule of thumb. If humans will read the answer, free-form text is fine. If software will read it, use structure. If accuracy matters more than speed, add reasoning and self-consistency. If exploration matters more than speed, use tree-of-thought. The image shows the whole pipeline: goal, prompt, test cases, revision, and final version. That is the real skill. Not memorizing tricks. Building a repeatable process that gets better with each round.