A pull request is a proposal to change a project's code. It shows exactly what would change, lets people comment, and gives automatic checks a place to run before anything is accepted. For AI-written code it is a natural checkpoint, because it puts a human and a scan between the AI and your product.
TL;DR: Think of a pull request as a draft that must be signed off. The AI or a person writes the change on a separate copy. The pull request shows the difference. Reviewers and automatic checks look at it. Only then does it join the main code. Skipping it removes your safety net.
Definition: pull request. A pull request, often shortened to PR, is a request to merge a set of code changes into the main version of a project. It displays the changes, collects comments and approvals, and runs automatic checks. Some platforms call it a merge request.
Why is it called a pull request?
The name comes from how teams share code. You make your changes on your own copy and then ask the project owners to pull your changes into theirs. The word "pull" is about the owners pulling, not you pushing.
Today the name is just a label. What matters is the shape of the process: a change is proposed, checked and then accepted or rejected. Different platforms use different names, but the idea is the same.
If you want a primer on the parts that sit inside software, see our guide to what a dependency is in programming. Pull requests are how new dependencies often arrive.
How does a pull request work, step by step?
Here is the usual path, in plain words.
- Make a branch. A branch is a separate copy of the code where changes can be tried without touching the main version.
- Write the change. A person or an AI tool edits files on the branch.
- Open the pull request. This creates a page showing the exact lines added and removed. That list of changes is called a diff.
- Run automatic checks. Tests, style checks and security scans start on their own. Results appear on the page.
- Review. One or more people read the diff, ask questions and request changes.
- Approve and merge. When the checks pass and reviewers agree, the change is merged into the main code.
- Keep the record. The page stays as a history of who proposed what, who checked it and when.
Each step gives you a chance to catch a problem. Skip the pull request, and you skip all of them.
Why does this matter more for AI-written code?
AI tools write fast and in large amounts. A person might write 40 lines in an hour. An AI tool can produce 400 in a minute. Volume makes careful reading harder, and it makes a reliable checkpoint more important.
AI-written changes also have some particular habits to watch:
- They may add libraries you did not ask for.
- They may touch files beyond the request.
- They may include confident code that is subtly wrong.
- They may change tests so a failing check passes.
None of these happen every time, but they happen often enough that they should be part of your review routine. Our pull request review checklist for AI-written changes covers them in detail.
A pull request gives you a stable place to catch each one. The diff shows extra files. The dependency file shows new libraries. The tests show up in the diff as well, so edits to them are visible.
What can run automatically on a pull request?
Automatic checks are what turn a pull request from a conversation into a safety net.
| Check | What it looks for | What happens if it fails |
|---|---|---|
| Tests | Does existing behavior still work? | Merge is blocked until fixed |
| Style and formatting | Does the code follow team rules? | Usually a warning or block |
| Dependency scan | Do new or existing libraries have known flaws? | Blocked if severity is above your rule |
| Reachability check | Can our code actually reach a flawed part? | Helps rank what to fix first |
| Review rule | Has a person approved? | Merge is blocked until someone does |
A gate is a rule that blocks the merge when a check fails. For example, "no new critical flaws with a fix available" is a gate. Gates make the rule automatic, so the answer does not depend on how busy or tired the reviewer is.
What does a worked example look like?
All numbers and names below are invented for illustration.
A developer asks an AI tool to add a feature that exports a report as a spreadsheet. The tool opens a pull request.
The page shows:
- 6 files changed, 180 lines added, 12 removed.
- 1 new library added to the dependency file.
- Tests: 94 of 94 pass.
- Dependency scan: the new library has 1 known high severity flaw with a fixed version available.
- Review: waiting.
Because the gate says "no new high findings with a fix available," the merge button is blocked. The reviewer reads the diff and notices that the AI picked an older version of the library. The reviewer asks for the newer version. The AI updates, the scan reruns clean, the reviewer approves and the change merges.
Without a pull request, that older library would have gone straight into the product. With one, it took five minutes to catch.
What should a reviewer do with a pull request from an AI tool?
A short routine helps when time is tight.
- Read the title and description. Does it say what the change is for? An AI tool should explain the goal. If not, ask.
- Look at the list of changed files. Are they all related to the goal?
- Check the dependency file. Was anything added, removed or moved to a new version?
- Read the changes to tests. Were tests added, or weakened?
- Read the automatic check results. Do not merge past a failing check without a written reason.
- Ask the author a question. If the author is an AI tool, ask the person who ran it to explain the reasoning in their own words.
Our posts on who should review AI-generated code and on labeling AI-assisted commits cover who reviews and how to mark AI help in the record.
What if the AI opens pull requests by itself?
Some tools can open pull requests on their own. That can be useful for routine updates, such as bumping a library version. It also means the review and the gates matter even more, because no person wrote the change.
A sensible start is to let the tool open pull requests but never merge them. A person reads each one and presses the button. Once the team trusts the pattern for one kind of change, it can decide whether to allow more.
Our post on disclosing AI-written code in commits and pull requests explains how to keep an honest record.
Where does Safeguard fit in?
Safeguard works at the pull request. Its policies and gates can block a pull request that breaks your rules, such as adding a library with a known serious flaw. It scans dependencies, builds a software bill of materials (a list of every component in an application), and uses reachability analysis to show which flaws your code can actually trigger, so reviewers see fewer, clearer alerts.
Safeguard can also open fix pull requests. That feature is off by default, and every category starts on Manual, so a person chooses when to turn it on and for what. The Safeguard command line tool can also write code, and its changes arrive as a pull request in the same way, to be reviewed like any other.
Try the free scan at gold.safeguard.sh/scan, or see the installers on the download page.
Try it yourself
Open the demo below and watch a pull request pass or fail a gate. Look at which finding causes the block and what would make it pass.
Click through it at your own pace, or open it full screen.
Quick check
Is a pull request the same as a merge request?
They are the same idea with different names on different platforms. Both propose a change, show the differences, collect reviews and run checks before the change is accepted.
Do I need a pull request for a one-line change?
Yes, if you want the checks and the record. Small changes can still add a risky library or break a test, and a pull request catches that cheaply.
Can an AI tool approve its own pull request?
It should not. The point of review is a second set of eyes. A person should approve, especially when the author is an AI tool.
What is a gate?
A gate is an automatic rule on a pull request that blocks the merge if a check fails, for example when a new library has a critical known flaw.
Sources
Last reviewed: 19 October 2026.
