Chapter 38 - Prompt Patterns That Actually Matter

Part: VIII - The Field Manual

Thesis

Most prompt engineering advice optimizes the wrong variable. The patterns that matter are the ones that produce artifacts the system can verify — not the ones that make the model sound more confident.

Key Line

Prompts matter when they produce artifacts the system can verify.

Why Most Prompt Advice Is PPE Theater

The model does not respond to encouragement.

“Think step by step” changes the output format. “You are a senior engineer” shifts the register. “Be careful and double-check” adds verbosity. None of these change whether the output is correct. They change how the output feels to read.

Patterns that constrain the output space are different. They limit what the model can generate in ways that make specific failures impossible or immediately visible. These patterns work because they connect generation to verification, not because they motivate the model.

Every pattern below produces an artifact. The artifact has a validator. If the validator does not exist, the pattern is missing its other half.

Every pattern in this chapter is ex ante specification in Introduction II’s terms: it shapes what the model proposes, before the model proposes it. None of them is a verifier. A better prompt still is not a substitute for a safer system - each pattern below reduces a specific kind of miss, and the table at the end of the chapter names, pattern by pattern, which failures a prompt can catch and which still need something checking the output afterward. That division of labor is the point. A pattern that improves specification is worth using precisely because it is not pretending to replace validation.

Pattern 1 — Plan Before Patch

Ask the model to describe the approach before writing any code.

“Before implementing, describe: which files will change, what each change is, and what could go wrong.”

The output is a plan. The plan is reviewable in seconds. If the plan is wrong — wrong files, wrong approach, wrong scope — the correction happens before the code is written.

The plan also surfaces assumptions. “This assumes the user is already authenticated” is a sentence in a plan. In code, it is an invisible state assumption (Ch 31). In the plan, it is catchable.

Pattern 2 — Test Before Implementation

Ask for the test before the code.

“Write the test for the intended behavior. Do not write the implementation yet. The test should fail if run against an empty implementation.”

The test is the specification. The model cannot generate a test that passes on no implementation without writing a tautology. When the test fails, it fails for the right reason. When the implementation passes the test, the specification is met.

This pattern forces the model to express the acceptance criterion before generating the mechanism. That is the test-first discipline from Ch 15, applied as a prompt pattern.

Pattern 3 — Negative Fixtures

Ask for test cases that should fail, not just cases that should succeed.

“Generate five input cases that this function should reject or handle as errors. Then generate the test assertions for those cases.”

The model naturally generates the happy path. Negative fixtures force it to reason about the boundary conditions — empty input, malformed data, out-of-range values, concurrent modification. These are the cases that break systems in production.

Negative fixtures are especially valuable for security-touching code. What should the validator reject? What should the authentication middleware block? The model generates a threat model as a set of failing test cases.

Pattern 4 — Explain Diff Risk

After generating a change, ask for its risk profile before committing.

“Given this diff, what could go wrong? What tests would catch each failure? Which failures would not be caught by the existing tests?”

The output is a risk summary. It is reviewable. It produces a gap list: failures that the test suite does not currently cover. The gap list is actionable — either add the missing tests, or explicitly accept the uncovered risk and document it.

This pattern uses the model’s generation capability against itself. The same model that generated the change can also reason about the change’s failure modes. That reasoning is faster than a human working through the same question from scratch.

Pattern 5 — Observable Markers

Ask the model to insert visible markers into prototype code so that human reviewers can identify what changed during a demo or playtest.

“Add code markers to every change you make in this session. For UI changes, add a visible test badge (colored border, console log, or overlay label). For logic changes, add a comment marker // VCB-MARKER: [what was changed]. I will tell you when to remove them.”

Worked example. A prototype adds a new user authentication flow. The session produces three changes: a new login form component, a modified API route, and updated session handling. Without markers, a reviewer watching a demo recording sees a working flow and must read the diff to understand what is new. With markers:

The login form has a yellow border: style={{ outline: '3px solid #f59e0b' }} and a console log: console.log('[VCB-MARKER] New login form rendered')
The API route has a comment: // VCB-MARKER: Added rate limiting -- test with 10 rapid requests
The session handler has a comment: // VCB-MARKER: Changed token expiry from 24h to 1h

During the playtest, the yellow border is visible in the screen recording. The reviewer knows exactly which UI element is new. The console log confirms when it renders. The comments tell the next agent what to verify and what to remove.

When the behavior passes validation, the agent sweeps the markers in one targeted pass: “Remove all VCB-MARKER comments and test style overrides. List each removal before making it.”

The markers serve the Propose stage. Their removal closes the Validate stage. The clean commit is the Commit stage.

Why this works. The marker pattern makes AI-generated changes visible to humans who were not in the session. A video of a demo with no markers shows behavior. A video with markers shows exactly which behavior came from this session’s changes. That distinction is the difference between “it works” and “I verified what we built.”

Pattern 6 — Rollback Plan

Before any deployment-touching change, ask for the rollback procedure.

“Given this change, describe the rollback procedure: what command or action would undo this if it causes a problem in production?”

If the model cannot produce a rollback procedure, the change does not have one. That is the answer you needed before deploying.

The rollback plan becomes part of the PR description. It is reviewed alongside the code. It is the deployment team’s instructions if something goes wrong.

Pattern 7 — Minimal Change

State the smallest acceptable change before asking for the implementation.

“Make the minimal change necessary to satisfy this requirement. Do not refactor adjacent code. Do not rename variables that are not directly involved. If you see something that could be improved nearby, note it in a comment but do not change it.”

Without this constraint, the model refactors what it touches. The refactoring is often reasonable but untested and outside the scope of the current change. The minimal-change constraint keeps the diff reviewable and the blast radius small.

Pattern 8 — Request Structured Proposals, Not Prose

For any output a downstream system will parse or act on, ask for the structured shape directly instead of asking for an explanation and extracting the shape from it.

“Respond with a JSON object matching this schema: {action: string, target_id: string, confidence: "high"|"medium"|"low"}. Do not include prose outside the JSON.”

A structured request does not guarantee a structured response - the model can still produce malformed JSON, and the schema validator is still the control that catches that, per Chapter 16. What the pattern buys is a proposal that is easy to validate at all. A paragraph of reasoning with an action buried in the middle of it forces a fragile extraction step before validation can even begin. Asking for the structure directly moves the model’s output closer to something Chapter 6’s routing pipeline can classify cleanly.

Pattern 9 — Name The Uncertainty, Separately From The Claim

Ask the model to report its confidence as a distinct field, not folded into the prose of the claim itself.

“For each factual claim, output the claim and a separate confidence label: verified (you have a specific source), inferred (reasonable given context but unconfirmed), or guessed (no strong basis).”

This does two things. It gives a downstream gate something structural to check - a claim labeled “guessed” can be routed to human review or blocked from publication automatically, where a claim with uncertainty buried in a hedge word like “probably” cannot be reliably filtered. And it makes the model’s own uncertainty visible to a reviewer instead of smoothed over by confident prose. A confidence label is not proof of anything - the model can mislabel its own certainty - but a mislabeled field is at least checkable against evidence, where a vague sentence is not.

Pattern 10 — Separate The Claim From The Action

When a response might contain both a factual claim and a proposed action, ask for them as distinct fields rather than one flowing paragraph.

“Respond with two fields: analysis (your reasoning, prose is fine here) and proposed_action (a structured object matching the action schema, or null if no action is warranted).”

This is Chapter 6’s mixed-output problem, addressed at the prompt level instead of only at the parser level. A model that is asked to keep its claim and its action in separate fields produces a response that is already partly routed before the router even runs. The parser still has to do its job - a claim in the analysis field can still be wrong, and an action in proposed_action still needs its own validator - but the prompt has done the specification-side work of keeping the two from bleeding into each other in a single unstructured paragraph.

When a proposal is rejected - a schema fails, a domain rule blocks it, a test does not pass - the natural next move is to send the model back with the failure. Done well, this closes the loop between verdict and specification: the model gets the exact reason its proposal was rejected and a genuinely better chance at a valid one.

Done badly, it becomes an unbounded resampling loop: the model tries again with no new information beyond “that was wrong, try again,” burning attempts against a validator that is not going to pass a proposal built the same way it built the last one. Chapter 9’s structured failure response is the difference - “field X failed constraint Y, expected shape Z” is specification the model can act on. “Invalid, try again” is not.

The practical rule: a rejection gets returned as specific, structured feedback, and the retry loop is bounded - one or two corrected attempts, not an open-ended loop. Past that bound, the failure escalates rather than resamples again, because a model that could not use precise feedback to succeed twice is unlikely to succeed on attempt seven.

Pattern 11 — Write Handoff

At the end of a session, ask the model to write the handoff file.

“Write the handoff file for this session in the format: current state, what was done, what was decided and why, what was deferred, open questions, next step.”

The model has the session in its context. It can produce a complete handoff from that context faster and more completely than a human writing from memory after the session ends.

The human verifies the handoff against their own recollection. Discrepancies are flagged. The verified handoff is committed. The next session starts with a briefing instead of a blank slate.

The Pattern Table

Pattern	Produces	Validator	When to use
Plan before patch	Change plan with risk list	Human review	Before any multi-file change
Test before implementation	Failing test	Run the test suite	All feature implementations
Negative fixtures	Edge case tests	Regression suite	Security, validation, parsing
Explain diff risk	Risk summary and gap list	Human review + test suite	Before merging complex changes
Observable markers	Visible in-code markers	Human watching demo/playtest	All prototype and demo sessions
Rollback plan	Rollback procedure	Operator review	All deployment-touching changes
Minimal change	Scoped diff	Diff review	All sessions in production codebases
Structured proposals	Typed object, not prose	Schema validator	Any output a downstream system parses or acts on
Name the uncertainty	Claim + confidence label	Human or gate routing by label	Any factual claim heading toward a public or high-consequence sink
Separate claim from action	Distinct analysis and action fields	Parser + action validator	Any response that might contain both
Write handoff	Agent handoff file	Human verification	Every session end

Practical Artifact — Prompt Pattern Reference Card

Copy one of these patterns verbatim into your session to activate it.

PLAN BEFORE PATCH:
"Before writing any code, describe: which files will change, what each change is, and what could go wrong."

TEST BEFORE IMPLEMENTATION:
"Write the test for this behavior first. Do not implement yet. The test must fail against an empty implementation."

OBSERVABLE MARKERS:
"Add a VCB-MARKER comment to every change. For UI, add a visible yellow border. I will tell you when to remove them."

EXPLAIN DIFF RISK:
"Given this change, what could go wrong? What tests catch each failure? What failures are not currently tested?"

ROLLBACK PLAN:
"Describe the rollback procedure for this change before we proceed."

MINIMAL CHANGE:
"Make the smallest change that satisfies the requirement. Note but do not fix adjacent issues."

WRITE HANDOFF:
"Write the handoff file: current state, what was done, decisions and why, deferred work, open questions, next step."

Export

Copy this block into your CLAUDE.md, agent instructions, or project checklist.