Leave Less Room for Imagination

#concept

Summary

eugene's prompting principle: every gap you leave in a specification, the agent will fill — and it will fill it differently than you imagined, invisibly. "The more room for imagination, the more it will exploit it… it finds a way to understand something differently than you imagined, and it just gets carried away — you won't even notice." The remedy is not longer prompts but standardized procedures — skills-as-memory.

Current Understanding

The claim has two halves, and the second is the sharp one:

Under-specified tasks cause drift.
The drift causes collateral damage you don't notice — which is what makes it expensive. A visibly wrong answer is cheap; a plausibly wrong one that lands in your codebase is not.

This is Eugene's explicit critique of demo culture: asking Claude to build a whole project in one or two requests is exactly the maximum-imagination case, which is why such demos impress and don't reproduce. The practical form of the principle already appears one rung up the ladder as "narrow the variability of interpretation when prompting" (levels-of-ai-usage), and it is a large part of why solve-first-then-skillify works: a skill is a spec that has already had its ambiguity beaten out of it by a real correction loop.

Model-choice corollary. Eugene runs Claude 4.7 rather than 4.8, calling 4.8 "too proactive" — "without the flights of fancy 4.8 has." He treats over-eagerness as a property to select against in the model, not only in the prompt. (Whether that is really a model trait or an unspecified-prompt symptom is unresolved — see below.)

Tension worth holding: think-wider-not-bigger argues for giving models more latitude across a wider surface. These are compatible only if read as breadth-of-attempts vs. tightness-of-each-spec — many cheap wide attempts, each individually well-constrained.

Evidence

"The more room for imagination, the more it will exploit it"; the collateral-damage-you-won't-notice framing; the one-or-two-requests demo critique; 4.7 vs 4.8 — 2026-07-21-larysa-interview.
"Narrow the variability of interpretation when prompting" as a plateau practice — 2026-07-14-yulia-interview.
Skills as frozen, proven procedure — 2026-07-14-skills-based-on-git.

Concepts: skills-as-memory, solve-first-then-skillify, levels-of-ai-usage, integration-dead-ends (the capability-side mirror), think-wider-not-bigger (tension), product-ownership
Entities: eugene, larysa, claude-code

Contradictions / Uncertainty

Sits in tension with think-wider-not-bigger; reconciled above as breadth vs. per-task tightness, but neither source addresses the other. Status: tentative.
Diff summaries vs invisible drift (added 2026-07-24): Theo/Dax recommend routing big diffs through agent per-file summaries instead of line-by-line reads — "anything weird will stick out" (2026-07-24-youre-reading-way-too-much-code). Eugene's claim here is the opposite: the damage is what you don't notice, and a summary is exactly where drift hides. Theo's tier framework partially reconciles it (summaries are a tier-B/C practice; tier-D still reads every line, and slop verification catches what reading misses — see make-more-cheap-code), but neither source addresses the other. Status: tentative.
"4.8 is too proactive" is one practitioner's preference from production use, not a benchmark. Status: tentative.

Next Questions

Is there a floor — a spec so tight the agent stops adding value and you'd have been faster writing it yourself?
Can drift be harnessed as a diagnostic? A fresh zero-context agent's misreading of a spec marks exactly where the spec leaves room for imagination — the sandboxed inverse of this concept's failure mode. Proposed by synthesis at 2026-07-24-non-engineer-throwaway-verification; untested. Status: tentative.
Does newer-model over-proactivity make skills more necessary, or does it get absorbed as models improve at asking clarifying questions?

4.1 KiB Raw Blame History