Do not merge it on trust. A pull request that edits application code is a code change, whoever opened it, so it needs a human review, passing tests and a clear reason. Update bots that only bump versions touch manifests and lockfiles. Source edits mean a different kind of tool.
Two kinds of automated pull request
It helps to separate them, because they carry different risks.
| Type | Typical files | Main risk |
|---|---|---|
| Dependency update | Manifest, lockfile | A new version pulls in new behavior or a new publisher |
| Code change | Source, tests, config | The edit itself is wrong, or fixes the wrong thing |
GitHub's description of Dependabot security updates is a good example of the first type: it raises a pull request to update the dependency to the minimum version that includes the patch and links it to the alert. That is a narrow change. A tool that rewrites your functions is making a design decision on your behalf.
What to check on a source change
- Scope. Does the diff match the title? Any extra file is a question.
- Behavior. Does it change what callers see: return values, errors, defaults, timing? Security fixes often do, and that is when downstream users get surprised.
- Tests. Is there a test that fails on the old code and passes on the new? If the bot added none, ask for one or write it.
- Neighbors. Search for other callers of what changed. A fix in one place can leave the same pattern elsewhere.
- Style and ownership. Does it follow your conventions? Does the person who owns that module agree?
Read it the way you would read a first contribution from a stranger. See review a first-time contributor pull request checklist for a longer list.
Keep the blast radius small
You can limit what any bot is allowed to change. Use CODEOWNERS so edits to sensitive paths ask for a named reviewer. Require status checks before merging. For Dependabot, GitHub's Actions guide notes that you should enable required status checks on the target branch so that pull requests cannot merge until all required checks pass. The same rule works for any other bot.
If the tool can open pull requests against many files at once, ask for smaller batches. A 40 file pull request cannot be reviewed honestly.
When it is fine to say yes
Plenty of automated code changes are sensible: a formatter run, a codemod for a deprecated API, a mechanical rename. Merge those when the transformation is described, the tests pass, and you can spot check a sample. Agree the rule in advance in your CONTRIBUTING file. See what to put in CONTRIBUTING about bot pull requests.
Where Safeguard fits
Safeguard offers autonomous remediation with fix pull requests, off by default, with every category set to Manual so a person approves the change. Where a fix touches code, a maintainer still decides. A free scan at https://gold.safeguard.sh/scan shows what a dependency change brings in before you read the diff.
Quick check
The bot says the change fixes a CVE. Is that enough to merge?
No. Confirm the vulnerable path applies to your project, read the diff, and run the tests.
Can I let a bot edit source files if tests pass?
Only for changes you have agreed in advance, such as a described codemod. Passing tests show the tests pass, not that the change is right.
Sources
- About Dependabot security updates, GitHub Docs
- Automating Dependabot with GitHub Actions, GitHub Docs
Last reviewed: 19 October 2026.
