What are out-of-scope edits by coding agents?

What are out-of-scope edits by coding agents?

Out-of-scope edits are changes a coding agent makes beyond what its task asked for, e.g. rewriting a helper function the task did not need. They are also called unrequested changes or collateral edits, and a series of them is often called scope creep. Each one can break a feature that the task's tests never check.

The task sets the scope. A developer often spots an out-of-scope edit as a changed file that the request never mentioned. A change is in scope when the task needs it, even in a file the request never named, e.g. a shared type the added code depends on. A change is out of scope when the work would be complete without it.

In a 2026 study of 33,596 pull requests opened by coding agents, the pull requests that were not merged tended to touch more files. The authors report that maintainer feedback "discourages agentic submissions that combine substantive modifications with unrelated edits."

Reading the diff finds out-of-scope edits, and it is one of three kinds of evidence teams use to test AI-generated code. An extra edit can also widen the blast radius of the change, the set of features that could break because of it.

What causes out-of-scope edits?

Out-of-scope edits usually come from one of these causes, and only the first lies in the request itself:

• The task states a goal, not a boundary. A request names what to add. It rarely says which files and behavior to leave alone, so nothing in it marks shared helpers or unrelated pages as off limits.
• The project's checks already failed. An agent that runs the project's checks before it stops can hit failures that existed before the task. It can then edit unrelated files until those checks pass, and the fixes land in the same diff.
• An instruction file asks for more than the task. A line in AGENTS.md that asks for clean, consistent code applies to each file the agent opens, not only the files the task needs.
• Files get rewritten in full. An agent can write a whole file instead of changing a few lines, and the rewrite can change the indentation. A formatter run across the repository, e.g. npx prettier --write ., rewrites each file whose formatting differs from the configured style.
• Code read for context gets edited too. The agent reads nearby files to find how the code works. It can then refactor a function there, or delete a helper that no file it read calls.

The agent usually writes its tests from the request, so they check the edits the task needs. Extra edits that nobody asked for or checked add to AI slop, output that looks finished but is bloated or unchecked.

What does an out-of-scope edit look like?

Here is an illustrative example. Acme Co. sells furniture online. A developer asks a coding agent to "Let customers edit their delivery address during checkout." The agent's session runs in four steps:

1. The agent adds an address form in src/checkout/address.ts and a test for it.
2. The agent reads src/cart/cart-page.tsx for the code that loads the cart, then writes the whole file back indented with 4 spaces instead of 2.
3. The agent reads src/lib/money.ts and rewrites formatTotal() as a shorter function.
4. The tests pass, and the agent's summary says "done" and calls the money change "a small cleanup."

The developer lists the changed files against the main branch:

$ git diff --name-status --no-renames origin/main...HEAD
M	src/cart/cart-page.tsx
M	src/checkout/address.ts
M	src/lib/money.ts
A	tests/checkout/address.test.ts

Two of the four files are outside the task. The developer runs git diff -w origin/main...HEAD, which ignores whitespace, and cart-page.tsx shows no changed lines. That edit only reformatted the file. The edit to money.ts changes behavior:

-export function formatTotal(cents: number): string {
-  return `$${(cents / 100).toFixed(2)}`;
-}
+export const formatTotal = (cents: number) =>
+  `$${Math.round(cents / 100)}`;

The shorter function drops the cents, so a cart total of $239.99 shows as "$240" in the order summary. The agent's summary called it a cleanup, but a refactoring keeps behavior the same, and this edit does not. The address test never renders the order summary, so it still passes. This example is simplified. A real review would also check every caller of formatTotal(), e.g. the order confirmation email.

How do you find or prevent out-of-scope edits?

These practices find extra edits before merge or keep them out of the diff:

• List the changed files first. git diff --name-only --no-renames origin/main...HEAD prints each path the branch changed since it left main. Without --no-renames, Git lists a moved file under its destination only, so a cart file moved into the checkout folder shows up only as a checkout file.
• Hide whitespace. The git diff documentation says -w ignores whitespace when comparing lines, so a file that was only reindented drops out. Changed quotes and reordered imports still show. The flag also hides whitespace that changes behavior, e.g. a space removed inside a string.
• Give each extra file a reason or a revert. The developer who ran the agent explains each file outside the task. git restore --source=origin/main...HEAD -- src/lib/money.ts puts a file back as it was where the branch started, and a commit records the revert. A useful extra change goes into its own pull request instead, on a branch from main, which also keeps pull request size down.
• Read changed tests first. An edit to a test the task did not need can be test tampering.
• Ask for proposals instead of edits. A rule in the instruction file can tell the agent to list extra changes in its summary and leave those files alone. In plan mode, a person can delete a step that touches an extra file before the agent edits anything. The agent can still skip a rule or depart from the plan, so the diff stays the check.
• Format the repository on its own. One pull request formats every file to the project's style. After that, the same formatter run on changed files returns a reindented file to that style.

The scope check is step 2 when a team reviews a pull request from an agent, and it comes first in a code review checklist for AI-generated code. A file list shows where the agent wrote, not what its edits did. An extra edit that the developer explains can still break a feature, and only running that feature shows it.

How is an out-of-scope edit different from a regression?

An out-of-scope edit is a fact about the diff. A reader can find one without running anything, by comparing the diff with the task. A regression is a fact about the running software, behavior that worked before a change and fails after it. Reading a diff can point to one, and a run confirms it.

The two overlap when an extra edit breaks a feature, as the money.ts edit did at Acme. They also occur apart. The reformatted cart page changed no behavior. Many regressions come from edits inside the task, which is one way agents break working features.

What should run when a diff reaches beyond the task?

Run the features that each extra file serves, and compare their output with the same steps on the main branch. At Acme, that means the cart page, the order summary, and the confirmation email, not only the address form. The last two call formatTotal().

An extra edit can change behavior that nobody chose to change. What passed before needs to remain true, unless someone explicitly decides otherwise. RunStory runs your software in a separate environment, tries relevant workflows, and checks the results. It is in private alpha for CLIs and web apps.

Join the RunStory alpha →

FAQs

Is every out-of-scope edit a mistake?

An out-of-scope edit is not always a mistake. Some are useful, and they belong in their own pull request, where a reviewer can read and run them. The trouble starts when an extra change arrives unexplained and unchecked, inside a diff meant for something else.

Should a reviewer reject unrequested changes in a pull request?

A reviewer can ask for unrequested changes to be explained, reverted, or moved to their own pull request, instead of rejecting the whole pull request. An extra change can stay in the same pull request when the developer explains it and the team agrees to review it with the task.

Why do agents reformat files the task did not mention?

Agents reformat files the task did not mention when they write a whole file instead of changing a few lines, or when a formatter runs across the repository. A diff that ignores whitespace hides indentation changes, so fewer lines are left to read, but it also hides a space removed inside a string.

How do you split a useful extra change into its own pull request?

A useful extra change moves to its own pull request in two steps. The developer makes the same change on a separate branch from main, then restores the file on the task's branch to its state where the branch left main. Each pull request then holds one change that a reviewer can read and run.