a builder's codex
codex · operators · Dan Shipper · ins_shipper-front-brief-autonomous-run

Front-load the full brief and evaluate the finished artifact; interrupting an autonomous run resets the model's planning state

By Dan Shipper · CEO and co-founder, Every · 2026-07-28 · essay · Taming Opus 5

Tier B · TL;DR
Front-load the full brief and evaluate the finished artifact; interrupting an autonomous run resets the model's planning state

Claim

Autonomous frontier models are optimized for single-run execution, not iterative chat. The correct operating protocol is: write the complete brief in the first prompt, let the model run without interruption, then evaluate the finished artifact rather than the model's in-progress narration. Mid-task correction resets the model's planning state and produces worse output than a clean uninterrupted run.

Mechanism

A frontier model that receives a full brief at the start allocates reasoning across the entire task scope. When a user interrupts mid-run to redirect or correct, the model re-enters a narrower context: the current exchange rather than the original full-scope brief. The planning trajectory resets. Subsequent output reflects the interrupted context, not the original intent.

Narration compounds the problem. Models describe their process while executing. Users who correct based on narration are responding to process commentary, not to output quality. The narration may be verbose or hedged even when the final artifact is correct. Evaluating the narration as if it were the output trains users to intervene unnecessarily, making outcomes worse.

Every's operational protocol for Opus 5 following this insight: write the full brief, include output format expectations, run batch jobs where possible, and filter output rather than redirect mid-task. The task boundaries matter. A model that can run a three-hour coding job should be handed a three-hour brief, not a sequence of fifteen-minute prompts.

Conditions

Holds when: the model has sufficient capability to execute the full brief from a single initial prompt, and when the task can be fully specified before execution begins. Strongest for coding, research, and writing tasks with clear completion criteria.

Fails when: the task is genuinely exploratory and the brief cannot be written until intermediate results are known. Also fails when the model makes a consequential error early in the run that, if uncorrected, invalidates all subsequent work. In those cases, early intervention is correct.

Evidence

Shipper in "Taming Opus 5":

"Skills preserve assumptions about the model they were written for. Try them freely but treat each new model release as a reason to prune."

The pruning instruction is the operational signal: each new model generation changes what instructions are load-bearing and which are now constraints the model no longer needs. The brief itself must be audited at each model upgrade, not just the scaffolding.

Every's testing found that when they provided complete upfront context and resisted mid-task correction, output quality improved substantially. The model's autonomous runs outperformed the interrupted ones even when the interruptions were well-intentioned attempts to improve the output.

Signals

Counter-evidence

Full-brief construction is harder to write and easier to get wrong than iterative prompting. A poorly written upfront brief with no mid-course correction produces a finished artifact that is entirely wrong, whereas iterative correction catches errors earlier. For teams without a strong brief-writing discipline, iterative correction may produce better average outcomes even if it produces worse ceiling outcomes. Shipper's findings are based on Every's internal use of Opus 5 on coding and writing tasks; results may not generalize to all task types or model capabilities.

Cross-references

Open the interactive view → View original source → Markdown source →