Part of Mechanisms of Vibe Coding

Mechanism: Diff-as-Context

One-sentence definition

Diff-as-context is using the actual change set — git diff, PR patch, or rejected hunks — as the primary steering input for the next agent pass, instead of re-explaining the whole problem in prose.

The problem

The agent made a messy diff. You write three paragraphs describing what went wrong. The agent misreads your description and edits different lines. Meanwhile the diff already shows exactly what to revert, keep, or fix.

Prose is lossy. Diffs are ground truth for what the agent did. Review and follow-up should anchor on them.

Symptoms:

• Long explanations that do not match the changed lines
• Agent fixes description while diff still has junk hunks
• Reviewers and agents talk past each other
• You accept some hunks mentally but never say which to drop

How it works

After each agent pass:

1. Run git diff (or review PR diff).
2. For next prompt, lead with diff facts:

– Hunks to revert (lines 42–50 in bootstrap.ts — out of fence)

– Hunks to keep

– What is still wrong per verify output

  Agent pass
       │
       ▼
  git diff / PR view
       │
       ▼
  Next prompt: diff directives + verify output
       │
       ▼
  Smaller, targeted pass

At checkpoint, diff-as-context is how you enforce constraints — reject hunks, not vibes.

Pair with verify loop: tests say what behavior is wrong; diff says what code changed.

When to use it

• Reviewing agent output before commit
• Second pass after a partially wrong edit
• Teaching the agent which of its changes were unwanted
• PR review of agent-generated branches

When not to use it

• Problem is wrong but diff is empty — agent did not edit; disclosure or goal issue, not diff steering
• Huge generated diff — rollback and narrower slice beat line-by-line commentary
• Secrets in diff — redact before pasting into cloud chat

Failure modes

Prose only — No diff in follow-up. Fix: Paste hunks or git diff --stat + specific file excerpts.

Accept all mentally — Click accept without scan. Fix: Checkpoint every hunk.

Diff without verify — Revert style, tests still fail for other reason. Fix: Verify + diff together.

Stale diff — Agent edited again; you reference old hunk. Fix: Fresh git diff each pass.

Whole-file revert — One bad line in file; revert entire file. Fix: Hunk-level reject in editor.

Minimal example

Context: Agent touched middleware.ts (out of fence) and bootstrap.ts.

Follow-up message:

Revert all changes to src/middleware.ts — out of scope.

Keep bootstrap.ts hunk that sets config.ready.

health.test.ts still fails:
  expected details.uptime > 0, got 0

git diff --stat:
  middleware.ts | 24 lines (REVERT)
  bootstrap.ts  |  8 lines (keep, fix uptime source)

Done when: Next pass diff shows middleware clean and bootstrap fix targeted.

Tool instances (optional deep-dive)

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

Cursor

• Reject hunk in diff view before re-prompting.
• Paste git diff output into chat — often faster than describing.
• @Git / source control context when available.
• Agent: “Review your diff against constraints; list hunks to revert before continuing.”

Other tools

git add -p, GitHub PR review comments on lines — human diff-as-context for teams.

Related mechanisms

• Verify loop — behavior signal alongside diff
• Checkpoint — human reads diff at gate
• Progressive disclosure — diff shows what to disclose next

Try it yourself

Exercise: On the last agent diff you have, write three lines: revert / keep / still failing. Paste git diff --stat into your note.

You need: Recent agent edit; two minutes

Done when: Your next prompt could be only diff directives + test output — no story paragraph.