Prompting is engineering, not wording

That one-sentence prompt is where your build stands after your first model call: the wiring works, and the replies read like they were written for someone else's product. Our family nutrition app FuelTheFam stood in the same spot with its fridge feature: a parent photographs their open fridge, the photo goes to a multimodal model, and a shopping list comes back while they wait.

The first fridge prompt, printed in full

Here is the complete prompt our first working version ran on:

You are a helpful assistant.
Look at this photo of a fridge and tell me what groceries we need.
Be accurate and helpful.

And here is what it produced against a real photo of our own fridge, with milk, eggs, butter, and spinach visible on the shelves:

Sure! From the photo it looks like you have milk, some eggs,
butter, and possibly some leftovers in a container. A well-stocked
family fridge usually also has yogurt, cheese, and fresh fruit,
so I'd suggest picking up yogurt, cheddar, apples, and orange
juice. Would you like a simple meal plan built around these?

Read that as the parent and every flaw has a price. The list is padded with yogurt, cheddar, apples, and orange juice, none of them in the photo, added because a typical fridge holds them, so a parent shopping from it buys food the photo never showed. The reply hedges on "possibly some leftovers," and it ends with a question on a screen where nobody can answer one. Nobody on our team reads a list before the user sees it, so this block, exactly as printed, was the product.

The obvious objection: the model should work it out

The obvious objection is that a model trained on a huge fraction of the written internet should not need hand-holding about shopping lists. The printed reply is the answer: every flaw is the statistically likely resolution of a question our three lines never answered.

• Who reads this? Nothing said, so the reply defaults to chat, preamble and follow-up offer included.
• May items appear that the photo does not show? Nothing said no, so the list filled out the way shopping lists in its training data usually do.
• What must the reply look like? Nothing said, so the most common form arrived: a friendly paragraph offering more help.

The model fills every gap in a prompt with the most common pattern in its training data, so every line you leave out is a decision you hand over.

The rewrite, part by part

Here is the fridge prompt as it ships today, complete:

You write the shopping list for the FuelTheFam fridge feature.
A parent has photographed their open fridge and is waiting on
this screen; your reply becomes the list they see.

Rules:
- List only items visible in the photo. Never add an item
  because a typical fridge would have it.
- If the photo is too dark or blurry to read, reply with the
  single word RETAKE and nothing else.
- No greetings, no advice, no questions.

Example
Photo shows: a milk carton, six eggs, wilted spinach.
Reply:
milk
eggs
spinach

Photo:

The same fridge photo now returns this:

milk
eggs
butter
spinach

Every part of the rewrite answers a failure you just watched, so match each part to the printed failure it fixes rather than memorizing categories.

• The role, the first two lines. It skips "you are an expert," which carries no information, and states who reads the reply and where it lands, the facts that moved the output out of chat.
• The boundaries, the Rules block. The only-visible-items rule answers the padded list. The RETAKE rule covers the photo taken one-handed into a dark fridge, where the feature asks for a retake instead of guessing. The no-greetings rule deletes the "Sure!" a waiting parent would scroll past.
• The example. It demonstrates the format instead of describing it; the next section shows why that outworks adjectives.
• The input slot, the final line. The photo attaches after the instructions, kept apart from them so instructions and input never blur.

A prompt is a specification you write and revise, like a brief for a contractor: it states the role, the boundaries, one worked example, and the format, and it improves by revision, never by hunting for a magic phrase.

One example beats a paragraph of adjectives

The example block earned its place through a failed attempt worth printing. We first tried to control the format with description, adding one rule: "Keep the list clean, concise, consistent, and easy to scan." One run returned • Milk (1 carton), the next returned - eggs, about 6, each defensibly clean and concise, and no two runs alike, because an adjective describes a standard without pinning down a single choice: bullets or none, capitals or not, counts or not. The three-line example replaced that sentence, and the format locked on the next run: lowercase, one item per line, no bullets, no counts, exactly as demonstrated. An example outworks description because the model is handed the standard itself rather than words about it, and at a fraction of a cent per fridge list, confirming the fix across ten reruns cost a few cents.

The prompt lives in the repo, like code

The fridge prompt is a file in the FuelTheFam repo, versioned like everything else that ships, so every change is a diff with a date and an author instead of a memory of what someone typed into a console. That habit makes revision possible: when a rule stops holding, the fix is a line in the file, and the proof is a rerun of the same inputs. It also marks the first rung of the ladder this part climbs: revise the prompt before you hand the model your data, hand it data before you hand it tools, and leave fine-tuning for the day the cheaper rungs are exhausted.

One ceiling stays in view: the model produces a response to whatever it is given, so a clear prompt cuts the rate of bad output without locking it out, and a user's input can push against your written rules. That is why anything that must never appear gets checked in code as well as written in the prompt.

Try it now

This drill takes about fifteen minutes; the no-setup path spends nothing, and the tooled path spends a few cents. You arrive with the artifact the last drill left you: your feature's first working call from Make your first model call, or its paper request if you took that chapter's no-setup path. You leave with PROMPT v1 for your feature, saved in your project, with the before and after outputs kept beside it. Call the rewrite v1, because the numbering starts when the file does.

No setup: Write the vague three-line version of your feature's prompt, the way ours started, and note in the margin what it would pad, where it would hedge, and what it would wrap around the answer. Then rewrite it against our printed rewrite: two lines stating who reads the reply and where it lands, boundary rules including one for unreadable input (your equivalent of RETAKE), one worked example of a perfect reply, and the slot where the user's input attaches. Keep both pages; they become the file the moment you have tools.

With your tools: In your project, ask Claude Code to move your feature's prompt into a file of its own, then run the same real input through the vague version and the rewrite, and save both outputs next to the file. Read the pair side by side; every difference traces back to a line you added. Same move in Codex or Cursor: create the prompt file in the sidebar chat and rerun the call both ways. If nothing is installed yet, the Setup Clinic gets you running.

Chapter Summary

• A vague prompt does not produce a broken reply, it produces an average one, because the model fills every unanswered question with the most common pattern in its training data.
• Our fridge feature's three-line prompt padded the list with items not in the photo, hedged on what it could not read, and wrapped the answer in chat.
• The rewrite fixed each failure with a specific part: a role stating who reads the reply and where it lands, boundary rules, one worked example, and a separated slot for the user's input.
• Flattery like "you are an expert" carries no information; a useful role line states the reader and the destination.
• One worked example fixed the fridge list's format where a sentence of adjectives could not, because an example hands the model the standard instead of describing it.
• The prompt lives in the repo as a versioned file, so every change is a diff you can read, test, and revert.
• A prompt lowers the rate of bad output without locking it out, so anything that must never happen is also enforced in code.
• Your drill artifact going forward is PROMPT v1 for your feature, saved in your project with its before and after outputs.
• Next, Get output you can build on turns the reply from clean lines a person can read into a structure your code can parse every time.

Sources

• Anthropic prompt engineering documentation (last verified July 2026).
• OpenAI prompt engineering guide (last verified July 2026).
• Google Gemini prompting strategies documentation (last verified July 2026).
• FuelTheFam (fuelthefam.com), our family nutrition app; the fridge prompts and outputs are quoted from our build.