Jacques Murray — Notes & Projects

Why I Wrote a Book on Prompt Engineering (And Why 'Prompting' Is the Wrong Word)

· Writing

I have spent the last two years watching engineers argue with autocomplete.

They type a question into an LLM, get a wrong answer, and conclude the model “doesn’t understand” the problem. Then they rephrase the same question three more times, hoping the fourth attempt triggers some hidden reasoning circuit. It never does, because there is no reasoning circuit to trigger. There is a statistical engine predicting the next token, and the gap between what people think it does and what it actually does is where every bad prompt comes from.

That gap is why I wrote Prompt Engineering for AI LLMs: A Beginner’s Guide: Mastering Generative AI, Reasoning Models, and Autonomous Agent Workflows . It published on the Kindle Store on September 18, 2026, runs 119 pages, and carries ASIN B0HK9MGLB1. It is a practical manual for treating an LLM like the mechanism it is.

What the Engine Actually Does

Here is the mechanism. A transformer-based LLM takes your input, breaks it into tokens, and computes a probability distribution over its entire vocabulary for what token comes next. It samples one, appends it to the sequence, and repeats. GPT-4-class models have vocabularies on the order of 100,000 to 200,000 tokens, depending on the tokenizer, and run this prediction loop for every single output token you see. Each forward pass yields a probability distribution for exactly one next token. Reasoning models such as o1, R1, and extended-thinking variants run this same loop over a block of intermediate reasoning tokens before producing the final answer. That block is more sampled text, generated the same way as everything else.

“Prompting” implies asking an agent for help, the way you’d ask a colleague. That framing is the wrong word for what’s happening. The actual work is closer to specifying an input distribution: your prompt constrains the sampler’s search space, narrowing which continuations are high-probability before generation even starts. You are not persuading anything. You are shaping a distribution.

Attention is the part that makes this useful instead of random. Every token in your prompt attends to every other token, weighted by learned relevance scores, so the model can track that “it” in sentence four refers to “the API” in sentence one. This is why context ordering matters more than most people assume. Put your instructions after 3,000 words of background material and the attention weights dilute; the model still technically “sees” the instruction, but it competes for weight against everything else in the window. Put the instruction first and restate it last, and it competes against less of the window at both ends, where the model is most likely to be attending. Claude’s context window runs to 200,000 tokens in its standard tier; an instruction anchored at the start and end of that window is never far from either edge.

This reframe changes how you write prompts. You stop asking “does the model understand my intent” and start asking “what token sequence maximizes the probability of the output I want, given this exact context window.” That question has answers you can engineer. The first one does not.

A prediction engine rewards precise input. Vague input gets vague output because vague input has more high-probability continuations to choose from.

The P-T-C-O Blueprint

The book organizes every prompting technique around one structure: Persona, Task, Context, Output constraints. Four slots, filled in order, every time.

Persona

Assign the model a role with a specific vocabulary and standard of judgment. “You are a senior backend engineer who reviews pull requests for race conditions and unhandled null states” produces different scrutiny than “review this code.” The persona narrows the token-prediction space toward the vocabulary and concerns of that role.

Task

State the action as a verb plus a deliverable. “Summarize this transcript” is a topic. “Extract the five action items assigned in this transcript, with the owner’s name and stated deadline for each” is a task with a shape the model can fill.

Context

Supply the facts the model cannot infer: the audience, the prior decisions, the constraints already ruled out. This is where most prompts fail, because writers assume shared context that exists in their head and nowhere in the token stream.

Output Constraints

Specify format, length, and what to exclude. “No more than 150 words, bullet list, no adjectives describing quality” gives the sampler a hard boundary.

Here is a compact example, end to end:

Persona: You are a technical editor for a developer newsletter with 40,000 subscribers. Task: Rewrite the following paragraph to remove hedging language and passive voice. Context: The paragraph will appear in a changelog entry announcing a breaking API change. Readers are experienced backend engineers who skim. Output: Return only the rewritten paragraph, maximum 60 words, no headers.

Four sentences. No ambiguity about tone, audience, format, or length. That specificity is the entire discipline.

From Prompts to Systems: What Else Is In the Book

A single well-formed prompt gets you one good response. The rest of the book is about what happens after that, once you need reliability across hundreds of runs or a chain of them. I covered the agent-workflow side of this in more depth in From Prompts to Autonomous Systems: Practical Agent Workflows , and the book expands that material with:

  • The Scratchpad Pattern: a chain-of-thought scaffold that forces the model to externalize intermediate steps in a designated block before committing to a final answer, cutting arithmetic and logic errors that show up when reasoning stays implicit.
  • Four production workflows: the Adversarial Red Team (a second model instance attacks the first model’s output before it ships), the Anti-Slop Voice Matrix (a rubric-driven pass that strips generic AI phrasing against a defined voice profile), the Tri-Pass Research Distiller (three sequential passes for breadth, verification, and synthesis), and the Pair Programmer pattern for iterative code review loops.
  • Autonomous agents and tool calling: ReAct loops (Reason, Act, Observe, repeat) as the control structure behind most agent frameworks, plus circuit breakers, hard limits on tool-call count and runtime, that stop a misbehaving agent loop before it burns your API budget.
  • RAG grounding: retrieval-augmented generation as a fix for the specific failure mode of hallucinated facts, with guidance on chunk size and retrieval scoring.
  • Defensive prompting: jailbreak patterns, prompt injection through untrusted retrieved content, and system prompt leakage, with concrete mitigations for each.
  • Git-backed prompt repository architecture: version-controlled prompts with regression evals, so a prompt edit that breaks output quality gets caught by a test suite instead of a customer.

Prompting is the entry point. Systems engineering is where the value compounds.

Get the Book

Prompt Engineering for AI LLMs: A Beginner’s Guide is available now on the Kindle Store, 119 pages, ASIN B0HK9MGLB1. It is written for engineers, technical writers, and product builders who already know how to think in systems and want the mental model to match. Lists of magic phrases stop working the moment the underlying model updates.

I am already drafting the follow-up material on multi-agent orchestration and evaluation harnesses. The P-T-C-O blueprint is the part I would want back if I could only keep one page.