The Brief — Dos & Don’ts (engineer’s one-pager)

The whole essay, distilled to rules you can apply today — grounded in established research and first-hand practice, with each rule traced to its source.

The frame (two laws everything hangs off)

• DO decide where each piece of judgment lives — in you, frozen into infrastructure, assigned to a persona, or judged in a fresh context. (the spine.)
• DO treat context as a budget. Everything you put in front of the model is spent, not free. (the attention budget.)

Briefing

• DO put your thinking into the brief before you lean on the answer — context, criteria, scope. It needn’t be complete upfront; the back-and-forth is what fleshes a half-formed idea out, and surfaces what you actually wanted. Writing it down forces your thinking into the open, which pays off even if the AI never responds. (self-explanation: Chi 1989; preference is constructed in the asking: Slovic 1995.)
• DO carry worked examples in the brief, not just rules. “Check domain constraints” with no example is too vague to act on — for the model and the reader. (first-hand: stripping the worked examples dropped a skill’s score 9.5→5.3.)
• DON’T fire a one-line prompt at a non-trivial task and walk away. Short prompts left to run produce unusable output; a 200–500-word brief is the floor — front-loaded, or built through the back-and-forth. (first-hand.)
• DO bound the output (“the single most important change,” “under 12 findings”). A cap forces prioritization; unlimited produces noise. (a bound is stored judgment.)
• DO describe the problem, not dictate the solution. A brief aimed at a conclusion gets you that conclusion, faithfully, even when it’s wrong — the model develops your bad diagnosis as readily as a good one, because it aligns with the premise you embed. Hand it the symptom, not your guess at the cause: asking “isn’t this just measuring the wrong thing?” and getting back “that’s Goodhart, here’s the literature” beats asserting the fix and watching it get dressed up. (premise-loading / sycophancy: Sharma 2023; Perez 2022.)
• DON’T assume the model will question your plan — get the critique on purpose. Models tend to take confident input as settled (sycophancy/deference: Sharma 2023, Perez 2022, Wei 2023), and the bias is mutual: you’ll rubber-stamp its confident output as readily as it rubber-stamps your confident plan (automation bias: Skitka et al. 1999). A standing decision-quality checklist gives the model structure that an after-the-fact “poke holes” on a finished plan doesn’t. (grounded in the deference literature; I tried to measure the plan-specific version head-on and it stayed inside run-to-run noise at small n — a known-bias guard, not a first-hand result.)
• DO debug the goal before the wording. When an answer comes back wrong-shaped, ask: wrong words, or wrong want? If the model did exactly what you asked and you’d still reject it, your brief captured the request, not the want — and rewording only entrenches it. You often don’t know the real goal until you’ve briefed it badly and watched the machine chase the wrong thing. (preferences are constructed in the asking: Slovic 1995; self-explanation.)
• DO interrupt your own brief. When your second thought corrects your first before the model has answered, cancel the in-flight reply and restart on the better line — don’t let it finish chasing the version you’ve already outgrown. (first-hand.)

Perspectives & panels

• DO use a panel for coverage of considerations, not decision-disagreement. Personas mostly agree on the call and vary the framing — semantic convergence, stylistic divergence (Hu & Collier 2024, arXiv:2402.10811: persona variables <10% of annotation variance). (first-hand persona runs.)
• DON’T expect named personas to “decorrelate.” They flip a decision only when a corpus genuinely dissents on that question; otherwise it’s coverage, not conflict. (first-hand; and Argyle et al. 2023, “Out of One, Many” — persona conditioning tracks real subgroup response distributions, so personas diverge where populations genuinely differ, not as arbitrary noise.)
• DO get real independence from a different model, not five personas on one model. Same-model agreement is suspect (shared training); cross-model agreement means something. (first-hand: cross-model judging.)
• DON’T convene a 5-persona panel to rename a variable. It’s ~5× the tokens — reserve it for decisions that are expensive to reverse. (cost gate.)
• DO name a persona to write, a generic to critique. Naming buys irreducible flavour for generation — a generic “make it tight” won’t reproduce Hemingway’s voice. But for finding flab, the named critic and a well-instructed generic catch the same things; naming the critic changes the voice of the critique, not the findings. (first-hand: write-vs-critique run.)
• DON’T point a name off its corpus. A name is a pointer to that person’s indexed writing; aim it outside their domain and it dereferences to the generic base — the centroid in a costume. A famous marine biologist, asked about a microservices split, gave the consensus answer citing the same generic references as everyone else. Put the model in a wetsuit and it still hands you the consensus, dressed in anatomy. (first-hand: named-off-corpus run.)
• DO surface with a panel; decide with advocates + a cross-model judge. A panel doesn’t vote. To actually decide, have two advocates pull the strongest grounded case each way, then let a different-model judge adjudicate against your real constraints — and keep the verdict yourself. Beware: a generic told to argue the wrong answer will build a rigorous, correctly-cited case for it, so grounding never settles it. (first-hand; Irving et al., “AI safety via debate,” 2018.)
• DON’T pick a panel by headcount. Three in-corpus lenses usually cover it — but you can’t stop by counting, because the one genuine dissenter could be the Nth. Aim at the divergences that matter, not a number. (first-hand: saturation run.)

Trust & rejection

• DON’T trust fluent output. Fluency isn’t correctness; the model sounds most confident where it’s most wrong. (the jagged frontier.)
• DON’T mistake the feeling of speed for progress. Momentum is the sensation of crossing into where the AI is confidently wrong — not proof you’re winning. (first-hand.)
• DO reject the trajectory, not just the artifact. Ask “are we still solving the right problem?”, not only “is this output good?” (protect the problem, not the plan.)
• DON’T let the AI grade work it produced in the same conversation. It’s biased to approve its own context. (self-preference bias; the cleanroom.)
• DO make it argue against you. Ask for the strongest case against the thing you (or it) just landed on. It has no commitment to the position — it re-derives the frame every turn — so the counter-case costs it nothing, and forcing it breaks the agree-by-default. Stress a decision this way before you commit. (sycophancy counter; the model’s no-stake re-derivation.)

The trust ladder — calibrate, don’t reject everything

“Treat any summary as a claim” is the rule; the ladder is how you afford it. Rejecting everything is too expensive to sustain, so match the check to the stakes — cost of being wrong × how hard it is to reverse:

• Accept — cheap, reversible, low cost if wrong (a rename, a phrasing). Don’t spend a check; you’ll catch it downstream for free.
• Spot-check — verify one or two claims in seconds (a number, a file path, a citation). The default for routine summaries and reports.
• Full-check — the raw behind every load-bearing claim, reconciled against it. You rarely read it yourself: point a model at the raw and the claim and have it check one against the other — better a different model, which won’t share the first’s blind spots. Make it quote the exact span it relies on, so you spot-check the pointer in seconds instead of re-reading the source — a confident “it checks out” you can’t locate is just a second fabrication. You bring the suspicion and keep the verdict; the reading is labor you can hand back. For anything you’ll act on, build on, or repeat: a result you’ll cite, a diff you’ll merge, a summary that sets direction.
• Cleanroom — re-derive it in a fresh context (a different model, or a new session with none of the thread), then compare. For the expensive-and-irreversible: a release call, a security-sensitive change, a claim going in front of others.

The rung climbs with the stakes. A wrong rename costs a minute; a wrong “all tests pass” before a release costs a weekend. Spend the check where being wrong is expensive, not everywhere. (rejection, made affordable.)

Making vs judging (infrastructure)

• DO use continuity for making; use separation for judging. Build inside a session; evaluate in a fresh one. (the core law.)
• DO freeze repeated judgment into infrastructure — skills, rules, checklists. But frozen bad judgment is durable, scalable wrongness; re-validate guards against new models. (stored judgment — guarantees repeatability, not correctness.)
• DON’T mix a voice/style pass with a content pass. Style doesn’t self-correct mid-content-review — run it as its own pass. (first-hand.)
• DO keep a session journal for handoffs. Reconstructing intent every session is the tax; an external log pays it down.

Owning the ground (the moves only you can make)

Context management is automated now; these four aren’t, and they share one mechanism: you declare what’s authoritative. The model won’t treat a casual, buried mention as binding — often correctly — so the ground has to come from you. The cheapest and truest setup is a short, fresh session seeded from the source file, not a long stale one.

• DO pull the reset — start fresh from the file at direction decisions, or when you smell drift. The model optimizes for continuity and never resets itself; it’s the cheapest move (smallest context) and ties for the most effective.
• DO edit the source of truth, not the chat, when a decision changes. The model re-grounds from the artifact; only you know it changed.
• DO mark reversals explicitly (“this supersedes X; don’t use the old one”). The model weights context roughly flat and won’t know your latest word overrides the old.
• DO name the 2–3 load-bearing facts at task start. Auto-retrieval prioritizes by its own heuristic; only you know what must hold for this task.

Apply it silently — bake it into setup (auto-loaded source file, fresh-per-task default, output bounds), not per-turn ceremony, and externalize the ground to a file before you compact. (Measured on Haiku, 2026-06-16; effects are an upper bound on a weaker model, and much of the original “drift” turned out to be the model reasonably declining a buried change.)