GitHub's new Octoverse numbers came out on 28 October, and one line stuck with me: "As of September, developers start more than 40% of pull requests with an agent." In March that number was 17%.
So if you review code for a team, a big chunk of what lands in your queue probably wasn't typed by the person whose name is on it. That doesn't make it bad code. GitHub says 90% of agent PRs were merged within two weeks in September, against about 86% for PRs with no agent involved. But it does change what's worth checking.
Here's what GitHub already does for you, what it just changed, and the checks I'd add on top.
Source: GitHub Octoverse 2026.
What GitHub's coding agent already protects
If you use Copilot's cloud agent, a few guardrails are on by default. Here's what GitHub's docs say it handles, and what's still on you:
| What GitHub does | Default | What's still on you |
|---|---|---|
| Only people with write access can start the agent | On | Who has write access in the first place |
Agent pushes to a single branch (normally copilot/...) and your branch protections still apply | On | That your protections and required checks are actually set |
| The person who asked for the PR can't approve it | On | A real second review, not a quick thumbs-up |
| Actions workflows don't run on Copilot's pushes until a maintainer clicks Approve and run workflows | On | Reading any .github/workflows/ change before you click |
| Secret scanning, CodeQL and an advisory-database dependency check run on its code | On | Whether new packages are the ones you meant |
| Copilot approvals count toward required reviews | Off (new, path-scoped) | Which paths, if any, you let it approve |
That's a decent baseline. The second-reviewer rule alone stops the "I asked for it, I approved it, it's merged" loop.
The new setting to decide on this week
On the same day, GitHub made Copilot approvals generally available. When it's on, Copilot can approve a PR and "that approval counts toward your repository's required approvals." It's off by default, and admins pick which file paths it's allowed to approve.
So now you have an odd mix: the person who asked the agent for a PR can't approve it, but Copilot's own approval can count on the paths you allow. That might be fine for docs or test fixtures. I wouldn't let it near auth, billing, migrations or .github/workflows/ without a person looking too. Whatever you pick, write it down so the team knows which paths a bot can sign off.
Five things I'd check on every agent PR
1. Did the tests change along with the code?
Researchers behind ImpossibleBench found agents "may delete failing tests rather than fix the underlying bug." So when a fix and its tests change in the same PR, read the test diff first:
git diff --stat origin/main...HEAD -- '*test*' '*spec*' (It's a rough filter, so it'll also catch names like latest.js. Good enough for a first look.)
If an assertion got looser or a test disappeared, ask why before you look at anything else.
2. Any new dependencies?
A USENIX Security 2025 paper found an average hallucinated-package rate of at least 5.2% for commercial models and 21.7% for open-source ones. Attackers can register those names. Check every new line in your manifest actually points at the package you think it does:
git diff origin/main...HEAD -- '*package.json' '*requirements*.txt' '*pyproject.toml' '*go.mod' '*Cargo.toml' 3. Anything under .github/workflows/?
GitHub's own review guide calls this out. A workflow change runs with your repo's permissions, so it deserves a slower read than the feature code.
4. Where did the task come from?
In 2025 Invariant Labs showed an agent could be hijacked "via a malicious GitHub Issue" and end up leaking private data in a PR it opened itself. If the agent worked from an issue that an outsider wrote, read the issue too.
5. Is it doing more than it was asked?
GitHub says about 87% of agent-started PRs touch more than one file, compared with 79% for PRs with no agent detected. Wide PRs hide small surprises. If the task was "fix the date parser" and the diff also renames a config key, split it.
Why not just trust it?
Because the research still says "check." Veracode tested over 100 models in 2025 and 45% of the code samples failed security tests. Google's 2025 DORA report found 30% of developers have little or no trust in AI-generated code, and that AI use still has "a negative relationship with software delivery stability." None of that means agents are useless. It means review is where the value gets decided, which is pretty much what GitHub's own Octoverse post says: "Review is where developers shape what comes back."
If you're looking at review tools to help with the load, Toolbit has a page of AI code review tools you can compare.
What's on your team's checklist for agent PRs that isn't on mine?
This article was created with the help of AI and reviewed by the author for accuracy. Disclosure: I work at Toolbit, linked above.
Sources
- GitHub Blog, Octoverse 2026 (28 Oct 2026): https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/
- GitHub Changelog, Copilot code review Max and approvals (28 Oct 2026): https://github.blog/changelog/2026-10-28-copilot-code-review-merge-with-confidence-with-max-and-approvals
- GitHub Docs, Copilot cloud agent risks and mitigations: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations
- GitHub Docs, Reviewing Copilot pull requests: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/review-copilot-prs
- ImpossibleBench, arXiv 2510.20270: https://arxiv.org/abs/2510.20270
- Spracklen et al., package hallucinations, USENIX Security 2025: https://arxiv.org/abs/2406.10279
- Invariant Labs, GitHub MCP exploit (26 May 2025): https://invariantlabs.ai/blog/mcp-github-vulnerability
- Veracode, 2025 GenAI Code Security Report: https://www.veracode.com/blog/genai-code-security-report/
- Google Cloud, 2025 DORA report: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
