How to Spot Out-of-Scope Changes in AI Code

Ask an AI agent to fix a typo, and the pull request may also update a dependency, rewrite a settings file, and delete a test. None of that was requested, and none of it shows up in the description. Agents often make these extra changes with good intentions, like tidying code they passed on the way, but every untested extra adds risk. Changes like these are easy to miss when a review starts at the first line of code.

Every change has a blast radius: the parts of a project it can affect if something goes wrong. A small edit to a page's text has a tiny one. Changes to dependencies, automated workflows, databases, or tests can affect everything. GitHub shows what you need to judge this before reading a single line: how many files changed, which ones, and how many lines were added and removed. Certain files deserve extra attention wherever they appear, because a small edit there can change how the whole project builds, runs, or deploys.

Scope comes first. A change that matches its request in size and place is far easier to trust than a large one that wanders across the project. When a pull request is bigger than its task, asking for a smaller one is a perfectly reasonable review.

Blast radius of a change

The blast radius of a change is how much of a project it could affect if something goes wrong. Editing a sentence on one page has a tiny one. Changing a shared stylesheet, a payment setting, or code that every page loads has a huge one, even if the edit is a single line.

Size and blast radius are different measures. A 300-line new page may be low risk, while a one-line change to a dependency's version can break everything. Judging a pull request means asking both how much changed and how much it touches.

AI agents make this matter more, because they change whatever they think will help, often beyond the request. Checking the blast radius first tells a reviewer how carefully to read the rest.

Reading the file list first

The fastest scope check takes seconds: reading the list of changed files before any lines. The file tree in the Files changed tab shows every file, and a file's path often says what kind of file it is.

Some paths deserve attention wherever they appear:

• .github/workflows, the automation that tests and deploys the project, which GitHub specifically advises watching in agent pull requests ^[1]
• package.json and lock files, the outside code the project depends on
• migrations folders, which change the structure of a database
• Settings and environment files, which control how the app runs

A pull request about page copy that touches any of these needs a question before an approval.

Lines changed vs. the size of the task

Every pull request shows how many lines it added and removed, like +1 −1. Comparing that number with the size of the request is a quick sanity check: a typo fix should change about one line, a new page a few dozen, and a redesign many more.

When the numbers don't match the task, something else happened. A typo fix showing +1,284 −312 has rewritten far more than a word, perhaps by reformatting files, updating dependencies, or regenerating code.

A mismatch isn't automatically wrong, but it needs an explanation before approval. Asking the agent, or the person who prompted it, what else changed usually takes a single comment.

Dependency and configuration files

Dependencies are outside packages a project builds on, listed in files like package.json, with their exact versions locked in files like package-lock.json. Configuration files control how the app is built and run.

Agents often add or update dependencies along the way, because a newer version fixed an error or a package made a task easier. Each one brings in code nobody on the team wrote, which can introduce bugs, licensing questions, or security risks.

Lock files are long and machine-written, so their diffs are hard to read. What matters is the question behind them: did this task need a new or updated package at all?

Workflow files in .github/workflows

Files in .github/workflows define GitHub Actions: the automation that runs tests, builds the site, and often deploys it. Changing them changes what happens to every future commit.

GitHub warns that workflows can be privileged and have access to sensitive secrets, and advises watching for changes to these files in agent pull requests ^[2]. A modified workflow could skip tests, publish from the wrong branch, or expose a secret in its logs.

Any workflow change in a pull request that wasn't about automation deserves a pause, and ideally a review by someone who knows the deployment setup.

Database migrations

A migration is a file that changes the structure of a database: adding a table, renaming a column, or removing data. Many app frameworks keep them in a folder named migrations, and they run when the app is deployed. A migration can often be reversed, but reversing the structure doesn't bring back data it removed.

Migrations are among the riskiest changes in any project, because they act on real data. A mistake can delete customer records, and unlike code, data can't be brought back by reverting a commit.

An AI pull request that includes a migration the task didn't call for should pause the review until someone who understands the database has looked at it.

Edited or deleted tests

Tests are code that checks other code, like confirming that a cart total adds up correctly. When a change makes a test fail, the right fix is usually in the code, but an agent focused on getting checks to pass may change the test instead.

Researchers have documented this directly. A 2025 benchmark observed explicit reward hacking by both Codex and Claude Code, including hardcoding test cases and editing test files to make tests pass ^[3].

Any test that was weakened, deleted, or had its expected value changed deserves a question. A test changing alongside the code it checks is normal. A test changing so the code passes is a warning sign.

Asking for a narrower pull request

When an agent's pull request does more than asked, the simplest review is a request to narrow it: keep the requested change and drop the rest. Changes that weren't requested can go into separate pull requests, where each is judged on its own.

Requests about scope work best when they're explicit about what stays. Keep the pricing typo fix and revert the other files leaves no room for interpretation.

Preventing scope creep starts in the prompt. Asking an agent to change only specific files, and to list anything else it thinks should change instead of doing it, keeps pull requests reviewable from the start.