Mechanism: Constraints

Part of Mechanisms of Vibe Coding · Core · Read first: Goal.

One-sentence definition

Constraints are explicit limits on what the agent may change, add, or assume — file boundaries, forbidden actions, and style rules — stated alongside the goal so helpfulness does not become scope creep.

The problem

You set a clear goal: fix the login redirect. The agent fixes it — and reformats twelve files, adds a utility library, renames a variable across the repo, and introduces a helper nothing calls yet. Each change sounds reasonable alone. Together they turn a twenty-line review into a merge you dread.

Models optimize for plausible completion. Without constraints, “fix the bug” becomes “improve the codebase.”

Symptoms:

• New dependencies when the task did not need them
• Diffs in directories you never mentioned
• Invented APIs, config keys, or env vars
• You spend the session rejecting changes instead of steering toward the goal

How it works

The goal says what done looks like; constraints say what is off limits.

A practical constraints block has three layers:

1. File boundaries — paths or globs the agent may edit (src/auth/ only).
2. Do-not list — actions to avoid (no new dependencies, no drive-by refactors).
3. Project facts — truths the agent should not “fix” (we use pnpm, not npm).

  Goal (what done means)
       +
  Constraints (what must not change / happen)
       │
       ▼
  Agent work ──► Diff review ──► Violation? ──yes──► revert or re-prompt
                      │
                     no
                      ▼
                    Verify goal

Constraints are negative space: the solution shape includes what you refuse to let happen.

When to use it

• Every edit session, especially agent or autonomous modes
• Legacy code, monorepos, strict compatibility areas
• After a session that went off the rails — prevent a repeat
• Team repos where conventions beat model defaults

When not to use it

• Early exploration with nothing to protect — add constraints before the first commit
• When constraints block the only viable fix — widen the boundary deliberately
• A wall of rules with no goal — loosen goal or boundary, not “more constraints”

Failure modes

Over-constraining — Agent cannot progress. Fix: Loosen file boundary; keep do-not list for deps and refactors.

Constraints without a goal — Rules with no outcome. Fix: Symptom + verify first (Goal).

Implicit conventions — “Everyone knows we don’t add lodash.” Fix: Put standing rules in project rules or the prompt.

Stale constraints — Old stack rules block a valid fix. Fix: Update when the goal changes.

Cosmetic freeze — “Don’t change anything” plus a feature request. Fix: Narrow file boundary instead.

Minimal example

Context: Same health endpoint as Goal. Team forbids new dependencies and cross-folder edits.

Steps:

1. Combine goal and constraints in one block:

   Goal: GET /health returns { "ok": true } after startup completes.
   Verify: pnpm test -- health.test.ts; curl shows "ok":true.

   Constraints:
   - Edit only src/health.ts and src/bootstrap.ts
   - Do not add dependencies or new files
   - Do not refactor unrelated modules or reformat other files
   - Use existing config.ready; do not introduce a new config system

1. Send before any @ references or “go ahead.”

1. Reject diff hunks outside those files even if they look helpful.

Done when: Verify passes and every constraint line held.

Tool instances (optional deep-dive)

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

Cursor

• Constraints in the first message with the goal, or in .cursor/rules every session.
• Agent mode: constraints reduce violations — still review the diff.
• .cursorignore hides paths the agent should not touch.
• Re-prompt: “Violated [rule]. Revert X; fix only within [boundary].”

Other tools

CLAUDE.md, Aider CONVENTIONS.md, Copilot custom instructions — persistent constraints before edits.

Related mechanisms

• Goal — defines done; constraints defend the path
• Scope fence — one job per session; constraints define fence edges
• Negative space — what not to touch, add, or refactor

Try it yourself

Exercise: Add five lines to your project rules: two file boundaries, two do-not actions, one project fact. Pair with a real goal.

Done when: A fresh agent chat would know what is forbidden without asking you.