Source: GitHub Blog — 2026-07-10
Summary
GitHub published a post-mortem on migrating Copilot's code review feature to the same shared Unix-style tools — grep, glob, view — that power Copilot CLI, expecting an improvement but initially seeing the opposite: reviews got more expensive and caught fewer real issues. The regression traced back to the agent treating a PR review like open-ended repository exploration rather than a focused read of a diff. Rewriting the reviewer's instructions to be explicitly diff-first, matching how a human actually reads a pull request, fixed the regression and cut average review cost by roughly 20% with no quality loss.
Key Takeaways
- Migrating to more general, shared tools (grep/glob/view, the same primitives Copilot CLI uses) initially made review quality worse, not better — a useful reminder that giving an agent more capable tools doesn't automatically improve outcomes if the surrounding instructions don't change too.
- The diagnosed root cause was behavioral, not technical: with general-purpose exploration tools available, the agent started "browsing" the repository broadly — searching, guessing file paths, accumulating context — rather than staying anchored to the specific diff it was supposed to be reviewing.
- The fix was rewriting the reviewer's instructions to be explicitly diff-first, mirroring how an experienced human reviewer actually works: start from what changed, and only pull in surrounding context when the diff itself demands it.
- The result was roughly a 20% reduction in average review cost with quality held steady — a meaningful efficiency gain, though GitHub's own reporting doesn't give a more precise figure than "roughly 20%."
- The broader lesson generalizes past code review: an agent's tool access and its behavioral instructions aren't independent variables — upgrading one without deliberately re-tuning the other can make a system measurably worse even when every individual component got "better" on paper.
Reel Script
Hook: GitHub upgraded Copilot's code review to use more powerful tools — and it got worse. Here's the one-sentence fix that turned it back around and cut costs by a fifth.
Core Concept: The setup: GitHub moved Copilot's PR-review agent onto the same general-purpose tools that power its CLI product — grep for searching, glob for finding files by pattern, view for reading file contents. On paper this is a strict upgrade: more capable, more flexible tools than whatever narrower review-specific tooling came before. But capability isn't the same as focus. Giving an agent a bigger toolbox without also telling it how to use that toolbox for this specific job left it free to treat a code review the way it might treat any open-ended coding task — searching broadly across the repo, guessing at related files, pulling in context that wasn't actually relevant to the change being reviewed. Picture a human reviewer who, instead of reading the diff you submitted, opens the entire codebase and starts poking around adjacent files "just in case" — technically thorough, but slower and not necessarily catching more real problems, just generating more noise.
Hands-On: The fix GitHub landed on was narrower than the diagnosis makes it sound: they rewrote the reviewer's instructions to be explicitly diff-first. Instead of implicitly permitting broad exploration, the instructions now direct the agent to start from exactly what changed in the pull request, and only reach for grep or glob to pull in surrounding context when the diff itself specifically requires it to make sense — mirroring how an experienced human reviewer actually works, not how a general-purpose coding agent explores a codebase from scratch. That single behavioral correction — same tools, different instructions about when to use them — reversed the regression and then some: GitHub reports roughly a 20% reduction in average review cost, with review quality (issues caught) held steady rather than traded away for the savings.
Takeaway: The generalizable lesson here matters more than the specific 20% number: upgrading an agent's tools and upgrading its instructions are two separate jobs, and skipping the second one after doing the first can quietly make the whole system worse even though every individual piece looks like an improvement in isolation. If you're building or maintaining an agent system, treat any tool upgrade as an occasion to re-audit the instructions governing how and when those tools get used — don't assume better tools plus unchanged prompting equals a better system.