Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Preframing

Pattern

A named solution to a recurring problem.

Ask the agent to explain the code before you reveal your intended change, so its first read is less biased by your hypothesis.

Also known as: ASK / EXPLAIN / DIRECT

Preframing is a small sequencing move with outsized effects. Instead of opening with “I think this component should do X,” you start with a neutral question about how the relevant code works. The agent reads the code to answer that question before it knows what you want changed. Only after that first explanation do you reveal the problem, invite analysis, and direct the work.

Understand This First

  • Prompt — preframing is a conversational prompt pattern.
  • Context Engineering — preframing works by loading code context before intent.

Context

At the agentic level, preframing sits at the start of a coding conversation. It applies when you already have a suspected problem or change, but you don’t fully trust your own hypothesis yet. You want the agent to inspect the code before it starts defending the solution you put in its head.

Most agent workflows tell you to provide clear intent up front. That advice is usually right. Ambiguous prompts make agents guess. But there is a narrow, common case where intent-first prompting hurts: you have a half-formed theory about the code, and stating it too early biases the agent’s first read.

Preframing handles that case by separating the agent’s first read from your proposed interpretation.

Problem

How do you get an agent to inspect code honestly before it starts trying to satisfy your stated intent?

Agents are cooperative. If you say, “This parser is dropping escaped quotes; fix it,” the agent will read the code through that frame. It may find the bug. It may also miss that the parser is correct and the caller is passing already-decoded input. The first prompt turned your hypothesis into the agent’s search pattern.

That failure is subtle because the answer still sounds useful. The agent explains why your theory might be right, proposes a change, and starts editing. You don’t discover the misframe until the verification loop fails or a reviewer asks why the wrong layer changed.

Forces

  • Intent helps agents act, but early intent can anchor the agent on the user’s first guess.
  • Neutral exploration costs a turn, and that feels slow on small fixes.
  • Agents tend to be agreeable, especially when the user states a confident diagnosis.
  • Code has local truth, and the first read should come from the code before it comes from the user’s story.
  • Routine changes don’t justify a full ceremony, but they still need some protection against cold-start prompting.

Solution

Use a three-turn conversational discipline: ASK, EXPLAIN, DIRECT. The discipline is not the number of messages by itself. The key move is withholding your intended change during the first turn.

ASK. Start with a neutral, non-operative question about the relevant code. Ask the agent to explain how a component decides something, where state flows, how invalid input is handled, or which files participate in a behavior. Don’t mention the bug you suspect or the change you want.

Good ASK prompts sound like this:

  • “Explain how this component decides when to re-render.”
  • “Walk me through how this parser handles malformed input.”
  • “Where does this state get initialized, transformed, and persisted?”

The agent now has a reason to read the code for its own structure. It is answering a comprehension question, not proving or fixing your theory.

EXPLAIN. In the next turn, state the problem or sketch your proposed change. End with “Thoughts?” or an equivalent analysis cue. That tag matters. It tells the agent you want critique, not action.

For example:

I think the stale UI state may come from the memoized selector rather than
from the React effect. My proposed change is to move the normalization step
closer to the API boundary so the component gets stable values. Thoughts?

The agent can now compare your hypothesis against the code it just explained. It may confirm the idea, reject it, narrow it, or point out a safer path.

DIRECT. Only after the agent has reacted do you ask for action. On a small change, the directive may be one sentence. On a larger change, the directive often hands off to Plan Mode: “Good. Propose a plan for that change before editing.”

Preframing is not secrecy for its own sake. You are not trying to trick the agent. You are controlling the order of information so the agent’s first pass is grounded in the code, then tested against your intent, then converted into work.

Example Prompt Sequence

Turn 1: “Walk me through how this parser handles malformed input. Don’t propose changes yet.”

Turn 2: “I think the bug is in how escaped delimiters are normalized before tokenization. Thoughts?”

Turn 3: “That makes sense. Make the narrow change in the tokenizer, add a regression test for escaped delimiters, and run the parser tests.”

How It Plays Out

A developer notices a React page re-rendering too often. The direct prompt would be, “Optimize this component so it doesn’t re-render every time the parent changes.” The agent would probably reach for memoization, because the prompt framed the problem as rendering overhead.

With preframing, the developer starts differently: “Explain how this component decides when to fetch and when to re-render.” The agent reads the component, the hook it calls, and the selector feeding it. It reports that the component re-renders because the selector returns a new object on every store update. Now the developer explains the observed bug and asks for thoughts. The agent points to selector stability, not component memoization. The final directive is smaller: fix the selector and add a regression test.

The same pattern works for backend changes. You suspect a retry loop is causing duplicate jobs, but you begin with, “Walk me through how jobs move from queued to running to completed, including where idempotency is checked.” The agent reads the queue worker and discovers that retries are safe, but the status update happens after an external API call. Your proposed retry fix isn’t the right move. The DIRECT turn becomes an atomic state-transition change instead.

Preframing also composes with Question Generation. After the ASK and EXPLAIN turns, the agent may say, “Before I plan this, I need to know whether duplicate events are acceptable or must be rejected.” That is a good outcome. The agent is now asking a targeted question from a grounded model of the code, not from a blank prompt.

Consequences

Benefits. Preframing improves the agent’s first mental model. It reduces rubber-stamping, catches wrong-layer fixes earlier, and gives you a cheap way to test your own hypothesis before implementation. It is also light enough for everyday use. You can preframe a five-minute bug fix without creating a research document or opening a separate planning artifact.

It also makes the conversation easier to audit. The ASK answer shows what the agent believed about the code before it heard your theory. If the later plan looks wrong, you can inspect whether the mistake came from the agent’s code reading, your hypothesis, or the handoff between the two.

Liabilities. Preframing adds latency. For obvious typo fixes and fully specified mechanical changes, the extra turn is wasted. It can also create false confidence if the ASK question is too narrow. If you ask only about the parser, the agent may miss that the bug lives in the caller. Good preframing asks about the behavior boundary, not just the file you already suspect.

There is also a social cost: you have to resist the urge to tell the agent everything at once. That restraint feels unnatural when you’re moving quickly. The payoff is not that the agent reads your mind. The payoff is that it reads the code before it inherits your bias.

  1. ComplementsQuestion Generation
    Question generation has the agent interview the user; preframing has the user interview the agent.
  2. Contrasts withResearch, Plan, Implement
    Research, Plan, Implement is a heavier phase structure; preframing is the lightweight conversational version for routine changes.
  3. Depends onContext Engineering
    Preframing is a conversational way to choose and order context before the agent acts.
  4. Depends onPrompt
    Preframing is a prompt discipline spread across three turns.
  5. EnablesPlan Mode
    The DIRECT turn often hands off to plan mode once the agent has read the code and reacted to the hypothesis.
  6. PreventsVibe Coding
    Preframing prevents the cold-start prompting that lets the agent accept a user's first guess and run with it.
  7. ReducesSteering Loop
    Better feedforward reduces the correction work the steering loop must do later.
  8. ReducesVerification Loop
    A better-framed change leaves fewer false starts for verification to catch.
  9. UsesFeedforward
    The first two turns are feedforward signals that shape the agent's later implementation attempt.

Sources

  • Wolf McNally introduced Preframing as an ASK / EXPLAIN / DIRECT tactic in a May 2026 post on X, naming the deliberate delay before revealing intent as the pattern’s core move.
  • Raymond S. Nickerson’s Confirmation Bias: A Ubiquitous Phenomenon in Many Guises (1998) supplies the cognitive-bias frame: people seek and interpret evidence in ways that favor the hypothesis already in hand.
  • Chris Dzombak’s LLM Q&A Technique: Context Priming (2025) describes a related practice of having an LLM gather reference material before substantive questions begin.
  • Birgitta Böckeler’s Context Engineering for Coding Agents (2026) gives the broader context-engineering frame: a coding agent works better when the relevant information is selected and ordered deliberately.
  • Anthropic’s Best Practices for Claude Code documents the explore-first discipline behind plan mode. Preframing is a lighter conversational version for cases where the agent should read before it knows the user’s preferred fix.