GitHub now lets Copilot fix up to 25 quality findings at once

Se você usa GitHub Code Quality no trabalho, provavelmente já olhou pra lista de achados acumulados e adiou.

If you use GitHub Code Quality at work, you've probably already looked at the pile of accumulated findings and put it off. It's that quality backlog nobody prioritizes because each individual fix is tedious. The September 9, 2026 GitHub changelog changes the flow: now you can select up to 25 findings on a page and send the whole batch to Copilot to fix at once.

The mechanics are what matter here, so let's get into what changes in your day-to-day inside the platform.

What exactly the agent does

According to the announcement, the flow is agentic end-to-end:

1. You select the findings on the Code Quality page (up to 25 standard findings at a time).
2. You trigger Assign to Copilot for the entire set in a single action.
3. Copilot creates a branch and starts fixing each finding autonomously.
4. It validates its own changes before proposing anything.
5. It opens a pull request for you to review and merge.

The point GitHub makes a point of highlighting: Assign to Copilot replaces the old Generate fix that existed for individual findings. In other words, there are no longer two different paths. Whether it's one finding or 25, the flow is the same: you delegate, it works on a branch, you review the PR. That's good from a consistency standpoint, you don't have to learn two different behaviors.

The detail most people will ignore: validation

The phrase "validates its own changes" deserves attention because it's what separates a useful autofix from a noisy PR generator. In automatic fix tools, the classic problem isn't the AI proposing a fix, it's proposing a fix that doesn't compile, breaks a test, or changes behavior without warning. An agent that runs its own validation before opening the PR reduces the volume of "noise" that reaches human review.

But the changelog doesn't detail what that validation actually runs (a build? the test suite? just the Code Quality query re-checked?). And here's where the pragmatic reading matters: don't confuse "the agent validated it" with "it's ready to merge." Its validation is a first barrier, not your review. The PR is still yours to approve. Treat each fix the way you'd treat a PR from a competent junior colleague: usually right, occasionally subtly wrong in an edge case that only someone who knows the domain would catch.

Where it works and what it costs

Before you start clicking, here's the availability and cost picture:

| Item | Detail | |---|---| | Where it runs | Repositories with GitHub Code Quality enabled | | Plans | GitHub Team and GitHub Enterprise Cloud (including the data residency option) | | Limit per action | Up to 25 standard findings selected per page | | Policy | Follows your enterprise's existing Code Quality policy, no separate policy | | Cost | Consumes AI credits when assigning findings to Copilot |

The policy point is convenient for admins: if the enterprise already enables GitHub Code Quality, bulk autofix comes along with it, without a new governance toggle to configure. Less internal approval friction.

The cost point is where pragmatism kicks in. Each assignment burns AI credits. Sending 25 findings at once is convenient, but it's 25 units of AI work. Before you "burn down" the entire backlog in one afternoon, do the credit math for your account, because the gesture of selecting everything and delegating it is exactly what consumes credits fastest.

The path I'd follow

In a real repo, I wouldn't start by sending 25 at once. The approach that makes sense:

• Start with a small, homogeneous batch. Select 3 to 5 findings of the same type (for example, all of the same code smell pattern). Fixes of the same type tend to have similar corrections, so you can assess the agent's quality with low risk before trusting it with volume.
• Read the whole PR, not just the summarized diff. Especially for findings that touch business logic, not just formatting. The agent validates its own changes, but it doesn't know your code's implicit contract.
• Let CI be the second judge. Since it opens a regular PR, your CI checks run on top of it. If your suite is weak, agent validation + weak CI = a false sense of security. Agentic autofix is worth more in a repo with good test coverage.

When I would NOT use it

As with every agentic tool, what's interesting is where it doesn't serve:

• Repos with a poor or nonexistent test suite. Without a safety net, you're blindly trusting the agent's validation, and the changelog doesn't promise it runs your tests.
• Findings that require an architecture decision. If the finding points to a problem whose "fix" depends on choosing between two design approaches, the agent will pick one. It may not be the one your team wants to live with years later.
• When the AI credits cost doesn't justify it. A trivial finding you can fix manually in 30 seconds might not be worth the credit. Autofix shines in the volume of repetitive findings, not in one-off fixes.

What remains open

The changelog is short and leaves questions that only usage will answer: what exactly the agent's internal validation covers, how it behaves when one finding in the batch is fixable and another isn't (does it open a partial PR? report what failed?), and how traceability works for which credit was spent on which fix. GitHub opened a feedback discussion in the Code Quality announcement, and the details are in the GitHub Code Quality documentation.

The takeaway for builders is direct: this is one more delegation of tedious work to an agent, and like any delegation, its value is proportional to the quality of your review and your CI. A stalled quality backlog is debt, and now there's a way to attack it that's cheap in effort (not in credits). But "the agent validated it" never becomes "I don't need to review it."