Key Takeaways

  • Thariq Shihipar points out that across evaluation problems, Claude often considers the correct solution in its reasoning path but discards it before execution.
  • Shihipar recommends forcing agents to output explicit "decision notes" or "implementation notes" to expose and test these rejected paths.
  • swyx observes that advanced prompt engineering has converged with executive communication: high-level delegation requires structured context rather than conversational chatter.
  • Building accurate prompts requires developing domain taste by mapping unknown unknowns through repeated exposure and precise vocabulary.
  • Engineering teams can delegate ambiguous architecture tasks cleanly by using the SCQA Prompting Framework (Heavybit Executive Communication Model).

The SCQA Prompting Framework (Heavybit Executive Communication Model)

Component 1: Situation (S)

Establish the current context, background, and existing state of the codebase or system.

Component 2: Complication (C)

Detail the specific challenge, failure mode, constraint, or blocker that disrupted the situation.

Component 3: Question (Q)

Define the core question or problem that needs to be addressed based on the complication.

Component 4: Answer (A)

Provide the proposed resolution or hypothesis. If unknown, leave this component open for the agent to resolve based on the S, C, and Q context.

When This Works (and When It Doesn't)

This framework works when delegating complex, ambiguous tasks to agents or communicating downward to align agent behavior with high-level system requirements.

It succeeds because modern reasoning models mirror human direct reports. If you give a senior engineer a one-line request with zero context on legacy constraints, they will build the wrong architecture. Claude Code operates under the same constraint. As swyx argues, “Sufficiently advanced prompting is indistinguishable from sufficiently advanced executive communication.” When you define the baseline state, the specific obstacle, and the exact question, the model stops guessing your intent.

Where this breaks down is rapid exploratory hacking or single-file bug fixes. If you are fixing a typo or running a simple regex script, drafting a full SCQA brief creates unnecessary overhead. Use quick commands for low-context edits. Reserve SCQA for tasks spanning multiple services or files where an incorrect assumption breaks downstream components.

Another trap is omitting the implementation reasoning. Shihipar notes that prompting resembles public speaking to a specific audience: “You need to build a mental model of Claude and how it thinks and how it works.” During benchmark evals, frontier models frequently outline the right approach in their chain of thought, only to talk themselves into an inferior alternative. Demanding decision notes forces the model to justify its trade-offs explicitly before writing code.

What to Do With This

Take the most complex ticket in your backlog this week. Instead of pasting a rough slack message into your agent harness, structure your prompt using SCQA:

Set the Situation by pasting the existing schema and background system dependencies. Add the Complication by specifying the latency bottleneck or failing integration test that broke production. Frame the Question around how to restructure the handler without introducing database locks. Leave the Answer blank, but instruct the agent: "Generate decision notes listing three candidate approaches with pros and cons before writing any code."

Run the prompt through Claude Code. Review the generated decision notes. You will catch the model considering and discarding the exact fix you needed.