{"slug": "better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it", "title": "Better tools made Copilot code review worse. Here’s how we actually improved it.", "summary": "GitHub's Copilot code review performance declined after swapping in shared CLI tools (grep, glob, view) due to poorly adapted instructions, but rewriting those instructions for pull request review workflows yielded a 20% cost reduction while maintaining quality.", "body_md": "Give an agent better tools and it should do better work. That’s the instinct, anyway.\n\nWhen you open a pull request, Copilot code review reads the diff and explores the surrounding code to find the problems that matter before they ship. To do that, it used its own code exploration tools. So when we swapped in the better-maintained, shared tools that power the Copilot CLI, grep, glob, and view, we expected a clean upgrade.\n\nInstead, in our benchmarks, we found that the cost of reviews was higher and fewer issues were being caught.\n\nBut the tools weren’t the problem. The instructions were. Once we rewrote them for the way a reviewer actually reads a pull request, the regression flipped into a win: roughly 20% lower average review cost, while maintaining the same review quality.\n\nThis is the story of how adjusting the workflows around the tools led us to a fix.\n\nSame tools, wrong instincts\n\nIf you’ve built on top of an agent framework, you’ve probably inherited its tools too. They work, so you keep them, until the day your use case drifts far enough from what they were designed for that they quietly start working against you. That’s the situation we were in. Before trying to use the shared CLI tools, Copilot code review used its own code exploration tools. That tool layer was inspired by earlier agentic systems, including ideas from SWE-agent-style repository navigation and GitHub Copilot Autofix: list directories, search files, search directories, and read code. Those tools worked, but they were specific to Copilot code review, and they were designed for how models behaved at the time. Earlier agentic coding models made fewer tool calls and were worse at automatically pulling in necessary context. This meant it was more important to include all relevant information in the few tool calls that the model made.\n\nMeanwhile, the Copilot CLI harness has a shared set of Unix-inspired code exploration tools: grep, glob, and view. That harness is also used by a growing number of Copilot agent products, including GitHub Copilot cloud agent, so harness improvements can benefit more than one product. We wanted to clean up and share infrastructure where possible, so we experimented with using the tools from the Copilot CLI harness in Copilot code review. The goal was to reduce duplicated tool implementations, create one shared place to improve code exploration tools, and make it easier to carry those improvements across Copilot products.\n\nOn paper, the migration looked simple:\n\nOld Copilot code review\n\nGitHub Copilot CLI\n\nPurpose\n\nlist_dir\n\nglob\n\nDiscover candidate files and directories before opening code.\n\nsearch_file and search_dir\n\ngrep\n\nSearch code for matching text, symbols, or call sites.\n\nread_code\n\nview\n\nRead the relevant file contents once a path or range is known.\n\nThe existing review tools were not thin wrappers. When searching for a directory or reading a code range, they could return the matched or requested lines plus extra surrounding code context. That added token cost, but it also matched how earlier models often benefited from having nearby context included automatically.\n\nInitially, we hoped this would be a simple migration: swap one set of tools for another. But when we tested the shared tools in offline benchmarks, the review agent became less efficient and less effective. Average cost increased, and the number of useful comments dropped.\n\nThe trace revealed a browsing loop\n\nOur internal Copilot code review benchmarks were useful because they show more than a final score. They show the path the agent took, including which tools it called, how much output came back, where errors happened, and whether it was narrowing toward evidence or widening the search.\n\nWhen we first tried the shared Copilot CLI tools in offline benchmarks, the agent often behaved as if it was browsing a repository instead of investigating a pull request. It would search broadly, guess likely paths, read broadly, find more things to search, and carry that extra context forward.\n\nThat pattern is understandable. Broad exploration can be useful when the task is “understand this repo.” But it’s not how a reviewer would usually review a pull request.\n\nWhen I review a pull request, I start from the diff and ask targeted questions:\n\nWhere is this function called?\n\nIs this config key used anywhere else?\n\nIs there a test or helper with the same pattern?\n\nWhat is the smallest nearby code range that explains this behavior?\n\nI do not want to open a large part of the repository before I know what I am looking for. I want the minimal context needed to answer the question, without overloading the review with unrelated code.\n\nThat matters because every tool result becomes part of the agent’s working context. Extra file contents can be carried forward into later reasoning, increasing cost and sometimes making the review less focused. A tool result is not a disposable printout; for an agent, it’s extra tokens that stay in the context window.\n\nThe traces made that difference visible. The shared tools were not the problem. The instructions were giving the agent the wrong instincts to do an efficient and effective review.\n\nThe tools themselves worked, but their instructions were tuned for their use within the Copilot CLI and implied the wrong workflow: the agent used grep, glob, and view like a broad coding assistant instead of a reviewer. A coding assistant may map a whole area before making a change to ensure it doesn’t break some other corner of the code. On the other hand, a reviewer usually starts from the diff, asks whether the change introduced a problem, and then looks for the narrowest nearby evidence required to confirm or dismiss it.\n\nGeneral coding-assistant tool instructions, like the ones used by Copilot CLI or Copilot cloud agent, make sense for an interactive assistant. A developer may ask it to understand a repository, plan a change, edit files, and continue over multiple turns.\n\nCopilot code review has a narrower job: start from a pull request diff, gather enough surrounding evidence to decide whether a change introduces a real issue, and avoid loading context that is not needed for that review question.\n\nIt was therefore clear that we couldn’t simply replace the previous Copilot code review tools with the tools from the Copilot CLI without additional prompting work. The problem became: how do we design tool instructions that use these shared tools effectively in a code review setting?\n\nRewriting the tool instructions for a reviewer’s workflow\n\nThe next iterations made the guidance specific to code review. The workflow we wanted Copilot code review to follow was:\n\nStart from the diff and form specific review questions.\n\nUse glob when the path is uncertain and grep to find candidate files, symbols, and call sites.\n\nBatch cheap discovery before reading files.\n\nUse view only when the agent knows which file or line range it needs.\n\nBatch focused reads instead of alternating between one search and one read.\n\nIn oversimplified form, this was the behavior we encoded:\n\nGeneric posture: Use the available tools to inspect repository context that may be relevant.\n\nReview-shaped guidance: Start from the diff. Narrow first with grep and glob; read exact evidence with view. If grep fails to find relevant context, retry with a simpler escaped search. If a path is wrong, pivot to glob instead of guessing nearby paths.\n\nFor example, imagine the diff changes an authorization helper that decides whether an operation is allowed. A relevant review question is not “show me the full contents of every file that calls this helper.” It could instead be the narrower: “are any request-handling callers relying on the old behavior?”\n\nThe intended path is short:\n\n```\nstart from the helper changed in the diff \ngrep for callers of that helper \nglob for likely route, handler, or controller files \nview the most relevant caller ranges \ndecide whether any caller changes the risk\n```\n\nThe guidance also changed how the agent recovered from failed searches. If an input made grep fail, the better next step was one simpler, corrected search. If a path was wrong, the better next step was glob, not guessing neighboring paths and reading whatever happened to exist. That nudged the agent away from letting a small tool failure turn into a larger exploration loop.\n\nThe change was small in wording and large in effect. It changed the rhythm of the agent from “browse, read, search again” to “ask, narrow, read, decide.”\n\nBenchmarks let us debug behavior, not just scores\n\nThe shared harness gave us the tools. The internal Copilot code review benchmarks gave us the feedback loop.\n\nWe could run the same review examples, compare tool traces, update the instructions, and run again. That let us ask concrete questions:\n\nDid the agent narrow first, or read broadly first?\n\nDid it batch independent searches?\n\nDid it call view only when it had a reason?\n\nDid a tool-instruction change reduce tool errors, or just move them somewhere else?\n\nDid the trace stay focused on evidence from the diff?\n\nDid the review still preserve the quality metrics we cared about?\n\nThe most useful signal was not “the instructions are better.” It was more concrete. The agent was making a similar number of tool calls, but spending more of them on relevant evidence instead of repeatedly expanding the search.\n\nThat connected product-level outcomes to understandable engineering behavior. Instead of guessing why a score moved, we could inspect the workflow that produced it.\n\nThe result: roughly 20% lower average review cost\n\nIn production, the tuned behavior showed roughly 20% lower average review cost compared with the control. Importantly, it did not show a quality signal that could block shipping.\n\nThe reduction did not come from the tools by themselves, it came from the workflow around them. Shared code exploration tools, Copilot code review custom tool instructions, and internal benchmarks made the agent’s behavior visible enough to tune.\n\nThat framing matters when building with agents. It can be tempting to treat tools as implementation details by swapping one tool for another, then comparing the final answer. But for an agent, the tool surface is part of the product experience. It changes what the agent notices, how it searches, how much context it carries forward, and when it decides it has enough evidence.\n\nTool descriptions and system instructions are closer to API documentation. Unclear API docs can leave a developer confused and lead to inefficient or wrong decisions. Unclear tool prompting can do the same for an LLM; a small wording change can affect cost, quality, and the shape of the investigation because it changes how the agent spends its attention.\n\nSame tools, different job\n\nWe also tried to apply the same kind of focused tool instructions in the CLI, where it did not produce the same kind of win. That is a useful counterexample, and an important guardrail for the lesson.\n\nCopilot code review is anchored to a diff and a review question. Copilot CLI handles broader, interactive coding tasks where exploration can be part of the job. There may be no single diff anchor, the user may change direction over multiple turns, and the right context may not be obvious at the start. The same grep, glob, and view tools can support both products, but the workflow around those tools has to match the product.\n\nThe takeaway is that shared tools scale when the instructions and benchmarks match the job.\n\nNapalys Klicius is a Software Engineer at GitHub building agentic systems. His career has taken him from model checking to low-level C++ drone systems and static analysis, and more recently to teaching agents how to inspect code without getting lost.\n\nExplore how the GitHub Copilot agentic harness delivers strong results across multiple benchmarks and leading token efficiency, while maintaining flexibility to choose among more than 20 models.\n\nWe do newsletters, too\n\nDiscover tips, technical guides, and best practices in our biweekly newsletter just for devs.", "url": "https://wpnews.pro/news/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it", "canonical_source": "https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/", "published_at": "2026-07-10 15:57:47+00:00", "updated_at": "2026-07-10 16:07:09.350647+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "large-language-models", "ai-agents"], "entities": ["GitHub", "Copilot", "Copilot CLI", "Copilot code review", "SWE-agent", "GitHub Copilot Autofix"], "alternates": {"html": "https://wpnews.pro/news/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it", "markdown": "https://wpnews.pro/news/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it.md", "text": "https://wpnews.pro/news/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it.txt", "jsonld": "https://wpnews.pro/news/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it.jsonld"}}