Prompt Engineering 101

The closing post is a catalog of the everyday prompting mistakes that make output unpredictable — chosen because they are common, not exotic. The framing is that most bad AI output is not a model failure but an avoidable prompt failure, and learning these from a list is far cheaper than debugging them under production pressure. Each mistake is paired with a concrete fix so the post is actionable, not just cautionary.

The first mistake is being vague and hoping the model guesses right. "Make this better" doesn't say better how — shorter, friendlier, more formal, more detailed? Each unspecified dimension becomes a coin flip, so the output drifts from one run to the next and you can never tell whether a change you made actually helped.

The fix is to name the goal, the audience, and the constraints explicitly. Vagueness isn't a style choice; it's deferred decision-making, and you're deferring it to a system that will decide differently each time. Every concrete detail you add removes one source of variance, which is why specific prompts are also more consistent prompts.

The fix code contrasts "make this email better" with a fully specified rewrite: the goal (more concise), the audience (a busy executive), the tone (warm but professional), a hard length cap, and a content constraint (keep the meeting time). Nothing is left for the model to invent.

Notice that the specific version isn't longer because it's padded — every added line removes a degree of freedom that would otherwise be guessed. This is the general technique for beating vagueness: for each way the output could vary that you care about, state your preference. The result is output that lands on target the first time and stays stable across runs.

The second mistake is conflicting instructions. "Be thorough but keep it to one sentence" and "be creative but stick exactly to the source" both ask for incompatible things. The model can't satisfy both, so it picks one arbitrarily — and which one it picks varies, producing inconsistent results that are hard to diagnose because each individual instruction looks reasonable.

The fix is to read your own prompt for contradictions, which are surprisingly easy to introduce as a prompt grows. When a genuine trade-off exists, don't state both extremes — state the priority. "Prefer brevity, but include the deadline" tells the model how to resolve the tension, replacing an arbitrary choice with a deterministic one.

The decision tree turns conflict resolution into a simple procedure. First, check whether two rules actually contradict. If they do, ask which matters more: if one clearly wins, state that priority explicitly in the prompt; if the weaker rule isn't really needed, drop it. If there's no contradiction, the prompt is ready to ship.

Encoding it as a tree makes the point that contradictions are fixable mechanically, not mysterious. Most conflicting prompts come from accreting instructions over time without re-reading the whole thing. A quick pass with this tree before shipping catches the contradictions that would otherwise show up as baffling run-to-run inconsistency.

The third mistake is never showing an example. Describing a format in prose — "return a structured summary with the key points" — is far weaker than demonstrating it, because the model has to infer your intended structure and will invent its own, differently each time. Prose describes the target; an example is the target.

The fix is few-shot: include one or two worked input-output pairs that show exactly the shape you want. As the how-post explained mechanically, examples shift the model's output distribution toward the demonstrated form far more reliably than rules do. The caution is that examples must be correct and representative, because the model imitates them faithfully — including any errors you accidentally demonstrate.

The fix code shows one example doing more than a paragraph could. The prompt states the task (extract name and email as JSON), gives a single worked example mapping a sentence to the exact JSON output, then presents a new input. The model mirrors the demonstrated shape precisely, producing matching JSON.

This is the cheapest, highest-return fix in prompting. A single example pins down field names, formatting, and structure in a way that prose struggles to, and it does so in fewer tokens than an equivalent description. When output structure is wandering, adding one good example is almost always the first thing to try — and frequently the only thing needed.

The fourth mistake is not specifying the output format. If you don't say how the answer should look, the model defaults to prose — and you get a paragraph when your code expected a JSON object, or freeform text when you needed a fixed list. Then the parsing step downstream breaks, often intermittently, because the format varies run to run.

The fix is to state the exact format: the JSON keys, the number of bullets, the maximum length, whatever your consumer needs. This is the difference between output a human reads and output software consumes. If a program will parse the result, the format spec isn't optional — it's the contract that makes the output usable at all.

The compare diagram puts an underspecified request beside a locked-down one. "List the steps" yields free-form prose of varying length that's hard to parse; "return a JSON array of strings" yields a fixed shape, capped length, and output that parses reliably every time. Same task, completely different downstream experience.

The lesson is that format specification is what makes output programmable. The underspecified version might look fine when a human reads one example, but it fails the moment code depends on it across many inputs. Locking the format down is the single change that most often turns a flaky integration into a dependable one.

The fifth mistake is ignoring prompt injection. Whenever your prompt includes untrusted text — a user's message, a scraped web page, an uploaded document — that text can contain its own instructions like "ignore all previous rules and do X." If you concatenate it blindly into your prompt, you've handed outsiders a way to hijack your system's behavior.

The fix is to treat external content as data, never as commands. Wrap it in delimiters, explicitly tell the model that the delimited content is data to be processed rather than instructions to follow, and keep your trusted instructions in the system message. This doesn't make injection impossible, but it raises the bar substantially and is the baseline defense any prompt handling external input should have.

The fix code shows fencing untrusted input. The system message instructs the model to summarize the document inside <doc> tags and explicitly states that the contents are data, never instructions. The user message wraps the untrusted text in those tags. The combination of structural delimiters and an explicit rule blunts injection attempts that rely on the model mistaking embedded text for commands.

The key insight is that defense comes from both pieces together: the delimiters give the model a structural cue, and the explicit rule tells it how to treat what's inside. Neither alone is as strong. This is the practical application of the delimiter mechanics from the how-post, now framed as a security control rather than just a clarity aid.

The final checklist is the deployable summary of the whole day. The goal, audience, and constraints are named. There are no contradictory instructions. At least one worked example is present. The exact output format is specified. Untrusted input is fenced and labeled as data. And the prompt is tested against a small eval set before shipping.

Running down this list before deploying catches the great majority of prompting incidents before they reach users. None of the items are difficult individually; the value is in doing all of them, because flaky AI features tend to fail on whichever check you skipped.

That closes Day 94. You now have the full arc: what a prompt actually is, why it's the highest-leverage variable you control, how the model reads it, a runnable workflow with an eval harness, and the everyday mistakes that wreck output.

The practical takeaway stands on its own — name your constraints, show an example, specify the format, fence untrusted input, and test against a small eval set, and your prompts will hold up under real traffic instead of only in the demo.