Part of Mechanisms of Vibe Coding

Mechanism: Scope Fence

One-sentence definition

A scope fence is a deliberate boundary around one session so it handles a single job — one goal, one area of the repo, one chat — before you open the next fence.

The problem

You start a chat to fix the health endpoint. By message twelve you are also updating Docker, tweaking CI, and “quickly” refactoring logging. The agent happily follows each tangent. Context fills with half-finished threads. You cannot review the diff because it is three tasks pretending to be one.

Without a fence, sessions grow by accretion. Every new request in the same chat expands scope unless you reset. The model has no instinct to say “that should be a new session.”

Symptoms:

• One PR or diff mixes bugfix, refactor, and unrelated cleanup
• You lose track of which goal the session started with
• Context is crowded with files from earlier tangents
• Closing the laptop means losing a entangled thread you cannot resume cleanly

How it works

A scope fence has three practical rules:

1. One goal per session — from Goal: one symptom, one verify, one bounded outcome.
2. One workspace slice — directories or features in play; everything else is out until the next session.
3. One chat lifecycle — when the goal passes verify, stop; new goal → new chat or explicit session handoff.

  Session opens
       │
       ▼
  Fence: goal + file slice + constraints
       │
       ▼
  Work until verify passes
       │
       ▼
  Close fence (merge / commit / handoff)
       │
       ▼
  New session for next job

The fence is a process choice, not a tool feature. You can enforce it with constraints in text, .cursorignore for hidden areas, or a fresh Composer tab per task.

When to use it

• Every non-trivial agent session
• When you catch yourself saying “while we’re here, also…”
• Monorepos and legacy folders where one wrong directory is expensive
• Before long agent or loop runs

When not to use it

• Initial repo exploration with no edits — scope is “learn,” not ship
• Tightly coupled changes that genuinely must land atomically — then write one compound goal with explicit verify for the whole slice, not three hidden tasks
• Pairing live with a human who steers scope in real time — still useful, but the human is the fence

Failure modes

Fence creep — New tasks added mid-chat without resetting goal. Fix: New task → new session or rewritten goal block at top.

Fence too wide — “Improve backend” as the slice. Fix: Narrow to one module or one endpoint; use split & conquer.

Fence without verify — Session ends at “looks good.” Fix: Run verify loop before closing.

Too many micro-fences — New chat per line change. Fix: Fence by shippable unit, not by keystroke.

Same fence, new goal silently — Goal drifts without a new session. Fix: That is vibe drift; reset or hand off.

Minimal example

Context: Health endpoint fix from Core articles — do not expand to CI or Docker in the same session.

Steps:

1. Open a new chat titled or prefixed: health-endpoint-fix.

1. First message only:

   Scope fence: this session is ONLY health endpoint + bootstrap startup flag.
   Out of fence: Docker, CI, logging refactor, other routes.
   Goal + constraints: [paste goal block]

1. When health.test.ts passes, do not ask for CI tweaks in the same thread. Commit or stash, then open ci-health-check as a new fenced session if needed.

Done when: The diff only contains in-fence files and you closed the session without in-chat scope expansion.

Tool instances (optional deep-dive)

Portable idea above; this section is tool-specific. Date: June 2026.

Cursor

• New Composer / Agent chat per fenced task — simplest enforcement.
• .cursorignore — removes out-of-fence paths from indexing so the agent does not wander into them.
• @ mentions — only @ files inside the fence; avoid @codebase for narrow fixes.
• Rules: “If the user asks for work outside the stated fence, suggest a new session.”

Other tools

Aider with --file list, Claude Code with explicit repo subtree — same fence, different UI.

Related mechanisms

• Goal — defines the job inside the fence
• Constraints — guardrails at the fence edge
• Split & conquer — planning multiple fences across a feature

Try it yourself

Exercise: Split your current backlog into fenced sessions. Write one line per session: goal + in-fence paths + explicit “out of fence” list. Do not start the agent until each session is one job.

You need: Backlog items; five minutes

Done when: No session line contains “and also” without a planned second session ID.