Scope Discipline

Constraining agents (and AI-accelerated teams) to touch only what was asked — countering over-editing, opportunistic rewrites and AI-fueled scope creep.

Also known as: scope discipline, agent drift, Agent drift, Over-Editing, over-editing, scope creep, Scope Creep Kraken, tentacle, tool-driven momentum, anti-rationalization table

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (11)

• Agent Skills: Bridging AI and Senior Engineer Practices Addy Osmani · 2026-10-08 source ↗ Reader 🖥️
  AI coding agents are capable junior engineers with no instinct for the invisible, non-diff parts of senior engineering — specs, tests, reviews, scope discipline, verification — so Agent Skills exists to make those parts structurally non-negotiable, because they are no longer optional even when the 'engineer' is a model.
• The Work Behind Delegation: A Framework for Supervising AI Coding Agents Yeon Su Park; Nadia Arvi; Hae Ri Lee; Sehoon Lim; Qianou Ma; Juho Kim · 2026-09-22 Reader 🖥️
  Developer supervision of AI coding agents is not a single activity performed at fixed checkpoints but a connected process organized into seven distinct, loop-connected stages (Plan, Monitor, Wait, Review, Teach, Manual Fix, Update Assets) -- a reconfiguration of Sheridan's classical five-stage human-supervisory-control framework made necessary by agents' greater autonomy -- and developers manage the resulting cross-stage demands (alignment, quality, understanding) by concentrating effort in planning, distributing supervisory work to other agents and automated hooks, and externalizing recurring corrections into reusable assets.
• All models, no matter how smart, will eventually build systems... Steve Yegge · 2026-09-02 Reader 🖥️
  Any AI coding model, left unconstrained, will eventually build a system that outgrows its own capacity to understand or maintain it — so the durable fix is not a smarter model but an externally imposed cap on system size.
• Human judgment doesn't leave the software factory. It relocates. Addy Osmani · 2026-08-21 source ↗ Reader 🖥️
  As software development moves from hand-coding to operating repeatable, event-driven 'software factories' of coding agents, human judgment does not leave the loop -- it relocates upstream to intent, system design, and the quality bar, and downstream to verification design, risk, and ownership of what ships -- so the best factories are defined by how intelligently they place human attention, not by how completely they remove it.
• agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub Addy Osmani · 2026-07-28 Reader 🖥️
  agent-skills, Superpowers, and Matt Pocock's skills all encode good agentic-engineering discipline but optimize for different moments in the work — full product-lifecycle governance with human checkpoints (agent-skills), autonomous reasoning-heavy execution (Superpowers), or a sharp personal daily toolkit (Matt Pocock) — and while the piece insists 'none of them is best in the abstract,' its own structure (author's project profiled first-person, most elaborated column, sole cited empirical case study, broadest 'reach for X' pitch) quietly tilts the honest map toward agent-skills.
• 11 Tips For AI Coding With Ralph Wiggum Matt Pocock · 2026-07-11 source ↗ Reader 🖥️
  Autonomous agent loops ("Ralph") become reliably productive only when the human stops writing code and instead wraps the loop in disciplined scaffolding — an explicit end-state/stop-condition, an externalized progress file, commit-blocking feedback loops, small steps, risk-first sequencing, stated quality expectations and a sandbox — scaffolding that compensates for the agent's lack of judgment and cross-session memory and that, unguardrailed, would let the loop accelerate software entropy.
• Agent Skills Addy Osmani · 2026-05-09 source ↗ Reader 🖥️
  AI coding agents default to the shortest path to 'done' and systematically skip the invisible senior-engineer work (specs, tests, reviews, scope discipline) that separates reliable software from code that breaks — skills are portable, workflow-shaped markdown files that bolt that scaffolding back on by making it impossible for the agent to rationalize skipping it.
• Accelerating Delivery: How AI Agents Can Own the Initial Code Draft Stephen Walker · 2026-04-20 source ↗ Reader 🖥️
  Autonomous AI agent workflows can reliably automate the journey from a Jira ticket to a first pull request if teams wrap inherently probabilistic LLMs in deterministic guardrails (branch scoping, hooks, orchestration) and multi-stage adversarial review loops that enforce architectural standards before human eyes ever see the code.
• Coding Models Are Doing Too Much nrehiew.github.io · 2026-04-20 source ↗ Reader 🖥️
  Current coding models systematically rewrite code beyond the minimal fix required — a widespread, measurable failure mode called over-editing — and reinforcement learning can train models to produce faithful minimal edits without degrading their general coding ability.
• Meet the Scope Creep Kraken Tim O'Brien · 2026-04-16 Reader 🖥️
  AI-assisted development breaks the natural friction that once constrained scope creep by making feature generation so fast that demonstrations replace deliberate decisions, and the only remedy is to reassert traditional project discipline — written scope, explicit decision-making, and downstream-impact assessment — over the seductive momentum of tool-driven output.
• Ashutosh Singh's Post Ashutosh Singh · 2026-04-10 Reader 🖥️
  Traditional product specs fail for AI features because they lack the technical specificity engineers need; PMs must replace vague feature descriptions with precise behavioral definitions, golden examples, failure-mode handling, cost/latency constraints, explicit scope boundaries, and eval criteria.

Propositions touching this concept (14)

By publication month, oldest first (extraction month when no publication date is known).

2022-11

• explicitClassic team problems — faulty communication, indecision, scope creep beyond 'barely sufficient,' sustainability erosion, thrashing, politics, excess meetings — did not each need a separate solution; they faded away as side effects of restructuring how the team works together, because most were symptoms of separation rather than independent defects.
  Software Teaming: A Mob Programming, Whole-Team Approach · p11

2026-04

• implicitScope creep is the primary killer of AI features, more so than technical failure.
  Ashutosh Singh's Post · p6
• explicitCurrent coding models systematically modify code beyond what is necessary to fix bugs, a behavior the author calls Over-Editing
  Coding Models Are Doing Too Much · p1
• explicitOver-editing is invisible to test suites because the rewritten code is still functionally correct
  Coding Models Are Doing Too Much · p2
• explicitOver-editing makes code review dramatically harder and risks quiet degradation of codebase quality
  Coding Models Are Doing Too Much · p3
• explicitA simple explicit prompt instruction to preserve the original code reduces over-editing across all models
  Coding Models Are Doing Too Much · p7
• explicitOver-editing in reasoning models is a default behavior that can be overridden, not a fundamental limitation
  Coding Models Are Doing Too Much · p10
• implicitWriting more tests is not a sufficient mitigation for over-editing because over-editing is invisible to test suites
  Coding Models Are Doing Too Much · p15
• explicitcorroboratedAI-assisted development removes the staffing friction that historically constrained scope creep.
  Meet the Scope Creep Kraken · p1

2026-05

• explicitestablishedThe default behavior of any AI coding agent is to take the shortest path to 'done,' skipping specs, tests, reviews, scope discipline, and verification.
  Agent Skills · p1
• explicitcorroboratedScope discipline is the single biggest determinant of whether an agent's PR is mergeable or has to be unwound.
  Agent Skills · p9

2026-09

• explicitRepeated correction of agent drift can itself produce further drift ('scope drift over long sessions'), because an agent that has been redirected multiple times 'starts building on its own previous assumptions' across successive fixes -- correction is not a costless or self-terminating process.
  The Work Behind Delegation: A Framework for Supervising AI Coding Agents · p9

2026-10

• explicitA senior engineer's job is mostly the parts that don't show up in the diff: specs, tests, reviews, scope discipline, and refusing to ship what can't be verified.
  Agent Skills: Bridging AI and Senior Engineer Practices · p1
• explicitScope discipline — touching only what was asked — is the single biggest determinant of whether an agent's PR is mergeable.
  Agent Skills: Bridging AI and Senior Engineer Practices · p4

Tensions

Open gaps (26)

• incompleteEvery worked example is a small, mostly greenfield repo the author owns (an AI Hero CLI, a course-video manager, a test-coverage backfill). The article's own principle — 'agents amplify what they see' — implies loops degrade most on large, messy, legacy/brownfield systems, where scope ambiguity, integration risk and entropy-amplification are worst, yet it never addresses running AFK loops on such codebases or where the technique breaks down at scale.
  11 Tips For AI Coding With Ralph Wiggum — read next: Agent work on brownfield/legacy systems: how autonomous loops fare where existing code quality is uneven, comprehension debt is high, and 'keep the codebase clean before letting Ralph loose' is not an option.
• argumentativeAnti-rationalization tables assume static excuses. The article treats rationalization as a finite, enumerable set. But LLMs can generate novel justifications not covered by any pre-written table. No discussion of what happens when the agent rationalizes in a way not anticipated by the table.
  Agent Skills
• practicalNo discussion of the cost of false enforcement. Skills add friction. What happens when the skill system forces an agent to write a spec for a one-line typo fix? The article mentions that 'a small bug fix might use three' skills but doesn't address the overhead/accuracy tradeoff.
  Agent Skills
• evidentiaryPortability is claimed but not demonstrated. The article asserts the same SKILL.md works across Claude Code, Cursor, Gemini CLI, Codex, etc. but provides no evidence that different harnesses interpret the same markdown workflow identically.
  Agent Skills
• incompleteThe entire evidence base is a single unnamed client engagement. No quality metrics, error rates, time-to-merge data, or controlled comparison against non-agent workflows are provided. The '4x PRs opened' metric could reflect PR fragmentation rather than genuine productivity gains.
  Accelerating Delivery: How AI Agents Can Own the Initial Code Draft — read next: Look for published case studies from Harness Engineering adopters (OpenAI Codex internal metrics, Stripe Minions data) that include quality and cost metrics alongside volume
• uninformedNo discussion of cost economics — token consumption for multi-agent adversarial review (planner + reviewer + coder + review agent + retrospective) could be substantial. Without cost data, the ROI claim is incomplete.
  Accelerating Delivery: How AI Agents Can Own the Initial Code Draft — read next: Token economics analyses for multi-agent coding workflows; Anthropic and OpenAI pricing models for high-volume agent usage
• incompleteThe 'self-improvement loop' is described as agents saving learnings back to context files, but there is no discussion of knowledge curation — who reviews what the agents learn? Unbounded accumulation of agent-generated context could itself become a source of context rot.
  Accelerating Delivery: How AI Agents Can Own the Initial Code Draft — read next: Knowledge management literature on automated knowledge bases; the 'wiki decay' problem applied to agent memory
• uninformedThe article does not address what kinds of tasks or codebases this approach works poorly for. There is no discussion of limitations by domain (e.g., security-critical code, novel algorithmic work, legacy systems with poor documentation).
  Accelerating Delivery: How AI Agents Can Own the Initial Code Draft — read next: Research on task complexity taxonomies for AI-assisted coding; empirical studies of where coding agents fail
• evidenceNo data, case studies, or examples are provided to support the central claim that these six practices actually change engineer behavior. The argument relies entirely on the author's authority and the reader's intuition.
  Ashutosh Singh's Post — read next: Look for empirical studies on spec quality and engineering compliance, or case studies from AI product teams.
• scopeThe post assumes a team structure where PMs write specs and hand them to engineers. It does not address embedded/cross-functional teams, pair-programming approaches, or iterative spec development — all common in AI product development.
  Ashutosh Singh's Post — read next: Explore literature on AI product development process models (e.g., Google's ML product management practices).
• depthThe assertion that engineers 'shouldn't' make failure-mode decisions is stated without justification. In practice, failure modes often require deep technical knowledge (e.g., model calibration, confidence thresholds) that PMs may lack.
  Ashutosh Singh's Post — read next: Consider shared-ownership models where PMs define user-facing fallback behavior while engineers define technical thresholds.
• uninformedThe claim rests on a single practitioner's single-tool, single-incident experience (one model family, one week, no quantification of 'flailed'), with no comparison across other frontier coding agents, no data on how large the system actually was, and no independent verification that 5.1 actually fixed the underlying cause rather than coincidentally shipping alongside Yegge changing his own usage pattern.
  All models, no matter how smart, will eventually build systems... — read next: Read alongside the corpus's broader over-editing/scope-creep data points (extract-coding-models-are-doing-too-much, extract-scope-creep-kraken) to see whether 'system outgrowing the model's grip' shows up as a measured phenomenon elsewhere, not just as anecdote.
• incompleteThe benchmark uses only single-function, single-bug corruptions. Real-world brown-field edits often span multiple files, involve multi-step reasoning, and require understanding broader architectural context. The author acknowledges this but does not address how the metrics or training approach would scale to more realistic settings like SWE-Bench Pro.
  Coding Models Are Doing Too Much
• incompleteThe corruptions are all value-level (operator flips, boolean swaps) rather than structural (control flow, API misuse, concurrency bugs). It is unclear whether the over-editing phenomenon and the RL remedy hold for structural bugs where the minimal fix may itself be structurally complex.
  Coding Models Are Doing Too Much
• incompleteThe paper does not investigate whether over-editing correlates with RLHF training that optimizes for helpfulness. Models may be trained to be maximally helpful, which in a coding context manifests as 'improving' code proactively. This would be a root-cause analysis the paper does not attempt.
  Coding Models Are Doing Too Much
• incompleteNo analysis of how the system prompt, context length, or conversation history affects over-editing. In practice, coding agents operate with long contexts and multi-turn interactions — does over-editing get worse with more context?
  Coding Models Are Doing Too Much
• incompleteThe RL reward function combines correctness and Levenshtein distance with a fixed weighting (pass bonus +0.1, fail penalty -0.2). No sensitivity analysis on these hyperparameters is provided, and the Pareto frontier between correctness and minimality is not explored.
  Coding Models Are Doing Too Much
• incompleteEach of the five centering types is given a named risk (mission drift, goal conflict, technological narcissism, geopolitical dependency, scope creep), but no instance is given of a company whose centering failed because that risk actually materialized. Without an observed failure case per risk, the framework offers no falsification criterion — it cannot currently be distinguished from 'successful companies, described after the fact, can always be shown to have had a coherent internal logic.'
  The Power of Strategic Centering — read next: Popper on falsifiability as a demarcation criterion; compare against how the 'resource-based view' and 'core competence' literatures the article dismisses were themselves originally supported by anecdote before later empirical scrutiny — is this critique specific to strategic centering, or standard for the strategy-framework genre at its introduction?
• incompleteThe claim that well-managed platforms 'become less expensive over time' is stated as a general truth but not supported with evidence or even a clear mechanism. This is a strong empirical claim that could easily be false for many organisations (e.g., scope creep, expanding user base, evolving cloud landscape).
  Platform as a Product: Delivering Value While Balancing Competing Priorities — read next: Case studies from organisations like Spotify, Zalando, or Mercado Libre that have published on platform economics would either support or challenge this claim.
• incompleteThe essay prescribes 'put the old discipline back' but does not address why those disciplines eroded in the first place or what specific mechanisms (governance structures, tooling, ceremonies) make them stick in an AI-accelerated context. If the old discipline was sufficient, it would not have been so easily displaced.
  Meet the Scope Creep Kraken
• uninformedNo distinction is drawn between scope creep in exploratory/prototyping phases (where rapid expansion may be desirable) vs. committed delivery phases (where it is destructive). The Kraken metaphor treats all unplanned expansion as harmful.
  Meet the Scope Creep Kraken
• incompleteThe essay does not address the cost of the friction it mourns. The old staffing-constraint model also prevented valuable features from being built. The analysis is one-sided: it treats lost friction purely as lost governance, not as lost waste.
  Meet the Scope Creep Kraken
• illogicalThe essay implicitly assumes that the integration cost of AI-generated features is comparable to that of human-generated features. If AI can also assist with integration, testing, and documentation, the cost calculus may differ from what the argument assumes.
  Meet the Scope Creep Kraken
• incompleteThis is a single-author, opinionated, model-dependent toolkit. Skill behaviour varies by model (the grilling-itself bug 'especially with Fable'), the design reflects one person's taste ('it brings me joy'), and there is no account of when the full lifecycle is overkill (small changes), how it holds up on large or brownfield codebases, or whether rigid phase-gating (grill -> spec -> tickets -> implement) helps or hinders an agent that might benefit from lookahead across phases.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets — read next: Read on model-dependence of skill/agent behaviour, on when phase gates help vs hinder AI-assisted problem-solving, and on running staged agent flows against large / legacy codebases where the assumptions (clean start, session-sized decomposition) hold least.
• incompleteThe article presents its full component list (filesystem, bash, sandbox, memory/search, context management, long-horizon patterns) as what agents need in general, without engaging when a task is simple enough that most of this machinery is unnecessary overhead — a tension with this corpus's own finding (extract-stop-overengineering-your-agent-harness) that harness complexity should be matched to a task's action-complexity/context-complexity profile, not applied uniformly.
  The Anatomy of an Agent Harness — read next: extract-stop-overengineering-your-agent-harness#p13 for the complexity-mapping counter-frame.
• incompleteThe workflow-diagramming method relied on retrospective reconstruction after a single ~40-minute task, and participants were introduced to Sheridan's five-stage framework before drawing their own diagrams -- a sequencing the authors themselves flag (§9) as a possible anchoring effect on how participants segmented their own supervision, even though they were explicitly told not to follow it.
  The Work Behind Delegation: A Framework for Supervising AI Coding Agents — read next: A within- or between-subjects comparison of workflow diagrams elicited with versus without prior exposure to Sheridan's framework, to measure the anchoring effect directly rather than only naming it as a limitation.