Prompt engineering examples that actually work

Most “prompt engineering examples” you find online are a list of magic incantations. Copy this exact text, get great output. It does not work like that, and the examples that travel well are not the clever phrasings. They are the boring structural moves: give the model the real context, the real constraints, and a way to check the answer.

So this is not a list of prompts to paste. It is a set of patterns, with example prompts to make them concrete, drawn from how I actually use AI: writing code, porting libraries, research, and drafting. The pattern is the part that transfers. The exact words are not.

What actually makes a prompt good

Strip away the folklore and a good prompt usually has four things:

• Context the model could not guess (the stack, the constraint, the audience).
• A specific task, not a vague wish.
• Constraints and an output format you can actually use.
• A way to verify the result, ideally one the model can run itself.

That last one is the one people skip, and it is the one that matters most. Let me show you what each looks like.

Example 1: role and real constraints beat “be an expert”

The weak version:

You are an expert Python developer. Write a function to parse dates.

This gives you a generic date parser that may or may not fit anything. The stronger version names the real situation:

I have a CSV exported from an old system. The date column mixes two formats:
"2026-06-09" and "09/06/2026" (day/month/year). Write a Python function that
parses both into datetime, raises on anything else, and has doctest examples
for both formats plus one bad input.

Same model, completely different output. The difference is not “expert.” It is that the second prompt carries the constraints the model could not have known.

Example 2: validation-first prompting

This is the pattern I lean on hardest, and it is the reason a genuinely scary project worked out. When I ported a Python astronomy library to GoHow I Ported a Python Astronomy Library to Go with AIAI-assisted port of Skyfield (Python) to a Go ephemeris library. Validation-first approach, golden tests, and bug hunts., “looks right” was worthless: an ephemeris number is either correct to the decimal or it is a bug. So the prompt was never “port this file.” It was closer to:

Here is the Python function and its output for these 5 inputs (attached).
Port it to Go. Then write a Go test that runs the same 5 inputs and asserts
the output matches the Python values to 1e-9. Show me the failing test first,
then make it pass.

The model is not being trusted here. The test is. Ask for the check, not just the code, and you turn “trust me” into “watch it go green.” I go deeper on this loop in how I actually use Claude CodeClaude Code: what it is and how I actually use itClaude Code is Anthropic's agentic coding tool. Here's what it is, how it works, and how I actually use it across real G....

Example 3: pin the output format

If you are going to do something with the output, say what shape you need. Vague prompts get prose; specific prompts get something you can use:

Compare these three libraries for our use case (attached requirements).
Output a markdown table: Library | Maintenance | Bundle size | Our blocker.
One row each, one short phrase per cell. No preamble.

“No preamble” earns its place in more prompts than you would think. The format line is doing real work: it is the difference between an answer you read and an answer you paste.

Example 4: show one example (few-shot)

When the task has a style or a shape, one example beats a paragraph of description:

Rewrite these commit messages in this style:

before: "fixed stuff"
after: "Fix off-by-one in pagination when total is an exact multiple of page size"

Now do these: [list]

You are not explaining the rule. You are demonstrating it once and letting the model generalize. For anything with a consistent format, this is the highest-leverage move.

Example 5: make it critique its own work

The model is often better at finding holes than at avoiding them. So I add a second pass:

Here is the function you just wrote. List the inputs that would break it,
ordered by how likely they are in production. Do not fix them yet, just find them.

Splitting “find problems” from “fix problems” gets you a real list instead of a defensive “looks good to me.” This is the same instinct as validation-first: build the check into the conversation.

Patterns for writing and research, not just code

Prompt patterns are not a coding-only thing. The way I use AI for drafting and research, which I wrote about in why, when, and how I use AIWhy, When, And How I Use AIExplore how I integrate AI into daily work - for research, writing, and learning - and the real challenges of accuracy, ..., runs on the same moves: give it the real material, constrain the output, and verify. For a draft, that means feeding it my actual notes and asking it to keep my structure rather than inventing one. For research, it means asking for sources I can check, not a confident summary I cannot. The honest version of “write faster with AI” is in that postWrite Faster with AI - While Keeping It YoursWrite faster with AI while preserving your unique style. A creator’s step-by-step workflow that works. too: the tool speeds you up, it does not remove the part where you have to be right.

Where prompt examples mislead you

Here is the trap with a post like this: you read the examples, paste a version, and expect the magic. The examples are not the skill. The skill is the loop: try, read the output critically, adjust the constraint that was actually wrong, try again. A “perfect prompt” that you cannot iterate on is worth less than a rough one you refine twice.

And the limit that never goes away: the model will be confidently wrong, in the same calm tone it uses when it is right. Every pattern here is really just a way to not take its word for it. The verification is the point. The clever wording is not.

FAQ

What is prompt engineering?

Writing the input to an AI model so it gives you a useful, correct result. In practice it means supplying the context the model lacks, stating the task and output format precisely, and building in a way to verify the answer, then iterating when it misses.

Do these prompt examples work for both ChatGPT and Claude?

The patterns do (context, specificity, output format, verification, few-shot). The exact wording matters less than people think, so treat the examples as structures to adapt, not text to paste verbatim. Test on your model and refine.

What is a few-shot prompt?

A prompt that includes one or more worked examples of the input-to-output you want, so the model generalizes the pattern instead of guessing from a description. Example 4 above is a few-shot prompt.

Why does my prompt give different answers each time?

Models are probabilistic, so some variation is normal. Tighter constraints, a fixed output format, and concrete examples reduce the spread. If the variation actually hurts you, that is usually a sign the task needs a clearer done-condition or a verification step.

Is prompt engineering a real skill or hype?

It is real but narrow. It is not magic words; it is the discipline of giving a model what it needs and checking what it returns. The leverage is real, and so is the failure mode of trusting confident-but-wrong output.

The best prompt I know is not a phrase. It is a habit: say what you actually need, give the model a way to check itself, and never take a confident answer as a correct one.