Diff Review and Incremental Adoption

How something is received is itself a human checkpoint. A binary of accept everything or reject everything cuts the resolution of judgment down to the size of the deliverable. Match the grain of receiving to the grain of judgment.

Problem

Agents produce large deliverables, and fast. Open the diff, and often only a small part needs fixing while the rest is sound. If the human side can only receive it as a binary — accept all or reject all — then either most of it gets rejected for the sake of that small part, or that small part gets waved through for the sake of the rest. The resolution of judgment gets cut down to the size of the deliverable. An agent's speed only becomes an advantage if the receiving side's grain keeps up with it.

Context

Applies when:

• The deliverable is large and can't be taken in all at once
• Only part of it is sound, and the rest has problems
• The agent's intent and the human's intent can drift apart
• Untangling things after they've already been merged in costs more later

Does not apply when:

• The output is small enough to judge as a whole at a glance. There's no point in narrowing the grain
• The whole change is indivisible. A change that breaks if adopted only in part (a refactor left in a half-finished state, for instance) falls here. Whether partial adoption is possible depends on the nature of the change — it isn't always an available option

Boundary with neighboring patterns:

• Strong Gates for Unattended Paths — that pattern owns the structure of the path: who can merge, when a workflow runs. This pattern owns how to read the diff that comes out. A cloud agent submitting a draft PR is that pattern's structure; adopting it partially is this pattern's practice
• Preemptive Plan Review — both are human checkpoints, but the time axis differs. That pattern verifies before the deliverable comes out; this pattern is how to receive it after it does
• Separating Mechanical Gates from Semantic Gates — diff review is a semantic gate. Filtering out what a machine can judge first shrinks the sheer volume of diff a human has to read
• Bounding Permissions by Structure — edits to sensitive files can be put behind approval. A point of contact where the grain of receiving gets enforced from the structure side

Solution

Why this works. An agent's unit of output (one big diff per task) and the unit of judgment (is this particular change sound) don't match. Receiving it without reconciling the mismatch leaves only two options: round the judgment up or down to the output's unit. Round "mostly fine" up to "fine" and problems slip in; round "partly bad" down to "bad" and sound work gets thrown out too. Matching the grain of adoption to the grain of judgment is what stops this rounding.

There's another benefit: rejection itself becomes information. Reject the whole thing, and all that reaches the agent is "it was no good." Adopt it piece by piece, and what passed and what didn't stays right there as a diff — feedback far more concrete than the next instruction (the same principle Failure as Institutional Memory states as "the more concrete, the more it works," applied to the moment of review).

⚠ There's an important limit here. This pattern assumes reading happens. However fine the grain gets, mashing accept without reading achieves nothing. Even the official docs, discussing a setting that auto-accepts changes, state plainly that content should be checked before it's brought in (Official, in Practice section). Grain only creates the opportunity for judgment — it doesn't substitute for the judgment itself.

Trade-offs

Advantages

• Sound parts don't have to be thrown away. There's no longer any need to reject everything else for the sake of one problematic part.
• Rejection becomes concrete feedback. What passed and what didn't stays as a diff, carrying more information than the next instruction would.

Costs

• It consumes human time. Reading a diff can't keep pace with how fast an agent produces one. Review absorbs part of the speed gained from automation.
• Partial adoption can break consistency. A change adopted halfway can produce a half-finished state that matches neither the pre-adoption state nor the fully-adopted end state.

GitHub Copilot in Practice

Copilot isn't a single product. This pattern in particular shows the unit of adoption itself changing by orders of magnitude across surfaces — VS Code works at the edit level, the cloud agent at the PR level.

VS Code — accepting at the edit level

Source: Chat overview (retrieved 2026-07-16) Official:

After the AI makes changes to your files, review and accept or discard them.

• Review inline diffs: open a changed file to see inline diffs of the applied changes. Use the editor overlay controls to navigate between edits and Keep or Undo individual changes.
• Stage to accept: staging your changes in the Source Control view automatically accepts any pending edits. Discarding changes also discards pending edits.

Being able to Keep / Undo individual changes is, as it stands, the direct implementation of "matching the grain of adoption to the grain of judgment."

The most commonly misread behavior on this page

Source: Review AI-generated code edits (retrieved 2026-07-16) Official:

After the agent updates your files, VS Code applies and saves the edits to disk. VS Code keeps track of which files have pending edits and lets you review them individually or all at once.

It's not that nothing applies until it's accepted. The moment the agent updates a file, the change is already written to disk. What "pending" means is "not yet decided whether to keep," not "not yet reflected." The grain of adoption and the timing of applying to the file are separate matters.

When you close VS Code, the status of the pending edits is remembered and restored when you reopen VS Code.

Sending something back is done through comments Official:

Select a range of code in a changed file, select Add Feedback, and enter a comment that describes the change you want. Add more comments on other selections or files, and then select Submit Feedback to send them to the agent. The agent reads your comments, makes the requested edits, and resolves each comment.

A mechanism also exists to remove the human checkpoint entirely, and the official docs attach a warning about using it Official:

You can configure VS Code to automatically accept AI-generated code edits after a configurable delay with the setting. Hover over the editor overlay controls to stop the auto-accept countdown.

If you automatically accept all edits, review the changes before you commit them in source control.

Turning on auto-accept doesn't make the responsibility to read disappear. Sensitive files can be excluded from auto-accept and put behind approval Official:

To prevent inadvertent edits to sensitive files, such as workspace configuration settings or environment settings, VS Code prompts you to approve edits before they are applied.

"chat.tools.edits.autoApprove": {
  "**/*": true,
  "**/.vscode/*.json": false,
  "**/.env": false
}

This setting is an example of enforcing the unit of receiving sensitive files from the structure side, and also connects to Bounding Permissions by Structure. ⚠ The setting key that controls the auto-accept delay itself couldn't be confirmed (a gap at the time of retrieval — only chat.tools.edits.autoApprove in the code block above could be confirmed).

cloud agent — accepting at the PR level

Source: Risks and mitigations for Copilot cloud agent (retrieved 2026-07-16) Official:

Draft pull requests created by Copilot cloud agent must be reviewed and merged by a human. Copilot cloud agent cannot mark its pull requests as "Ready for review" and cannot approve or merge a pull request.

Who can merge, and the structure of this draft-PR path itself, belongs to Strong Gates for Unattended Paths. This pattern covers how to read that draft PR, and where to send it back — the receiving practice.

There are two ways to send something back (source: Review Copilot's output, retrieved 2026-07-16) Official:

To request changes from Copilot on its pull request, mention @copilot in a comment, or push commits directly to the branch.

Beyond having Copilot fix things through comments, committing directly to the branch is also a form of incremental adoption. Rather than sending the whole PR back, a human takes over part of it directly and leaves the rest to the agent.

The same page also names what deserves special caution when reading Official:

GitHub Actions workflows can be privileged and have access to sensitive secrets. Inspect the proposed changes in the pull request and ensure that you are comfortable running your workflows on the pull request branch. You should be especially alert to any proposed changes in the .github/workflows/ directory that affect workflow files.

This isn't about the structure of the path — it's about how carefully the diff gets read, a matter of where the receiving practice puts its weight, and falls within this pattern's scope.

Differences across surfaces

Surface	Unit of adoption	Means of sending back	Source
VS Code	Edit level (Keep / Undo individual changes). Bulk adoption also possible by staging in Source Control	Add Feedback → Submit Feedback	Chat overview / Review AI-generated code edits, above
cloud agent	PR level (a human reviews and merges the draft PR)	Mentioning @copilot / committing directly to the branch	Risks and mitigations / Review Copilot's output, above

The grain differs by orders of magnitude across surfaces. In VS Code, the human can choose the unit to read; on the cloud agent, the PR is given first as an institutional unit, and the grain within it is left entirely for the human to build. A blanket statement like "Copilot lets you review diffs" erases this difference.

Also Known As

Name	Source
Diff Review and Incremental Adoption	Descriptive — a descriptive name coined by this catalogue; no primary source uses it

Individual operations have established names. Keep / Undo / Add Feedback / draft pull request are all official terms (Primary, source: in Practice section). But no established name could be found for the practice itself of "not going all-or-nothing, and adopting part by part at the grain of judgment." The tooling provides the Keep / Undo buttons, but it doesn't prescribe how to press them. This pattern was added to this catalogue's design spec's third revision on a second opinion's suggestion, which is why its name has a more recent origin than the others. Naming the container (the buttons, the PR as a unit) separately from the contents (the judgment of how to adopt) follows the same structure as the Also Known As section of Failure as Institutional Memory.

Related

• Strong Gates for Unattended Paths — the structure of the path (who can merge, when a workflow runs) is that pattern; how to read the diff that comes out is this pattern. A cloud agent submitting a draft PR is that pattern's structure; adopting it partially is this pattern's practice
• Preemptive Plan Review — both are human checkpoints, but the time axis differs. That pattern verifies before the deliverable comes out; this pattern is how to receive it after it does
• Separating Mechanical Gates from Semantic Gates — diff review is a semantic gate. Filtering out what a machine can judge first shrinks the sheer volume of diff a human has to read
• Bounding Permissions by Structure — edits to sensitive files can be put behind approval. A point of contact where the grain of receiving gets enforced from the structure side
• Failure as Institutional Memory — of the failures found through diff review, the ones that recur should be written into the instruction file concretely, not as an abstract admonition
• If reading just one more next: Making the Verification Target Explicit — worth handing over what to check before receiving anything