Pacific Design/ artificial intelligence

section 04 · status: live · 7 entries · updated 2026-08-29

Prompt Engineering

The highest-leverage AI skill that needs no GPU. What belongs in a prompt and where, the techniques worth knowing, how to get output a program can parse, what to do about the answers you can't trust, and why prompts fail.

live · a context window being assembled — system, examples, user, schema

  1. Anatomy of a prompt3 mininstructions early, context middle, format last
  2. Few-shot & chain of thought3 minexamples teach, scratch tokens think
  3. Structured output3 minschemas, tools, and grammars over hope
  4. Context engineering2 minthe prompt grew up and became a budget
  5. Designing for uncertainty3 minthe interface is where reliability actually happens
  6. Optimizing prompts3 minstop tuning by hand, start searching
  7. Why prompts fail3 minambiguous, buried, injected, and untested

check yourselfAnswer before you open

Trying to recall something teaches it better than re-reading does. Have a go, then open the answer.

You add a rule to a long system prompt and the model ignores it. Name two likely causes before blaming the model.

Placement — instructions buried in the middle of a long context are measurably less likely to be followed than the same words at the start or end. And conflict — an older rule may contradict the new one, and the model resolves that silently rather than flagging it. Why prompts fail →

Why does putting your system prompt and examples first save money?

Providers cache the computed state of a prompt prefix and discount matching tokens steeply, but only while the prefix matches exactly from position zero. Stable content first, volatile content last — and never a timestamp at the top. Anatomy of a prompt →

Constrained decoding guarantees valid JSON. What does it not guarantee?

That the values are true. Structure removes exactly one class of error — the parse error — and converts the rest into well-typed hallucinations. Build honesty into the schema: a nullable answer, a confidence field, an explicit 'insufficient information'. Structured output →

You are calling a fast non-reasoning model on a multi-step math task. You then switch to a reasoning model. What should change in your prompt?

Remove the 'think step by step' scaffolding. The reasoning model was trained to produce its own long reasoning trace, and prescribing your steps can override a strategy better than yours. Manual chain of thought still earns its tokens on small, fast models. Few-shot & chain of thought →

Your extraction prompt is right 92% of the time. The remaining 8% ship silently. What is the design error?

Treating the output as a value when it is a claim. A system that cannot say 'I am not sure' converts every uncertain case into a confident wrong one. The fix is structural: let the model abstain, return a confidence you have actually checked, and route the low-confidence tail to review rather than to the user. Designing for uncertainty →

Your sessions run long and quality decays. What is the actual problem?

Not the prompt — the budget. The question stops being 'how do I phrase this' and becomes 'of everything this system knows right now, what earns a seat in the window.' The levers are compaction, tool-result hygiene, externalized memory, and keeping the cacheable prefix stable. Context engineering →