AI-generated fixes can save time, but a fix that looks correct in a pull request still needs the same engineering review as code written by a developer.
GitHub Code Quality can identify maintainability, reliability, and style problems in pull requests and provide Copilot-powered fixes. Its newer agentic autofix capability goes further by allowing Copilot to investigate the codebase, make changes, validate the result, and open a pull request for review. The pull request still requires a developer to review and merge the changes.
That last part matters.
An automated validation result does not mean the generated change is automatically correct for your application. Developers still need to verify the behavior, scope, dependencies, tests, and design decisions before merging.
What Agentic Autofix Actually Does
Traditional autofix gives you a suggested code change for a finding.
Agentic autofix works more like a development task.
The general flow is:
Code Quality finding
|
v
Assign to Copilot
|
v
Explore relevant code
|
v
Generate a fix
|
v
Run validation
|
v
Iterate if required
|
v
Open pull request
|
v
Developer review
|
v
Merge or modify
For code scanning alerts, agentic autofix can inspect relevant files beyond the location of the original finding, generate a change, rerun analysis to validate the fix, and open a pull request. The current implementation is in public preview and uses the Copilot cloud agent.
GitHub Code Quality also provides agentic remediation for standard quality findings. Developers can select multiple findings and assign them to Copilot for remediation in a pull request. The current bulk workflow supports up to 25 selected standard findings at a time.
Why Developers Still Need to Review the Fix
An automated agent works from the information available to it.
It can understand the finding, inspect related code, and run validation, but it does not automatically know every business rule behind the application.
Consider this C# example:
public decimal CalculateDiscount(
Customer customer,
decimal orderTotal)
{
if (customer.IsPremium)
{
return orderTotal * 0.20m;
}
return 0;
}
Suppose a quality finding suggests simplifying or changing part of the method.
The generated change may be syntactically correct and pass the available tests.
That still does not prove that the discount rules are correct.
A developer reviewing the pull request should ask:
Does the change preserve the business rule?
Does it affect other customer types?
Are there boundary conditions?
Does it change rounding behavior?
Does it affect downstream calculations?
The key question is not simply "Does the fix remove the finding?"
It is "Does the fix solve the finding without changing behavior that the application depends on?"
1. Read the Original Finding First
Do not start by reviewing the generated code.
Start with the original finding.
GitHub Code Quality findings on pull requests include severity information. The current categories are:
Severity | Meaning |
|---|
Error | A high-severity issue that can cause bugs, failures, or significant maintainability problems |
Warning | A moderate issue that can affect quality or reliability |
Note | A lower-severity issue or recommendation |
Understand why the finding was raised before looking at the proposed solution.
For example, if the finding says that a method contains duplicated logic, determine whether the duplication is accidental or intentional.
Sometimes two similar blocks exist because they represent different business rules.
Removing the duplication without understanding that distinction can make the code shorter while making the behavior harder to maintain.
2. Review the Complete Diff
Never review an agentic fix only from the finding's original line.
Open the complete pull request diff.
Look for:
This is particularly important because agentic autofix can explore the repository and modify related code rather than limiting itself to the original line.
A small quality finding can therefore result in a larger change.
The larger the diff, the more carefully it should be reviewed.
3. Check Whether the Fix Is Actually Necessary
Not every finding needs to be fixed.
A quality finding may apply to production code, test code, generated code, or an intentional implementation pattern.
For example:
if (value == null)
{
return;
}
A tool may identify an opportunity to simplify the code.
That does not automatically mean the existing code should be changed.
Ask:
Is the finding valid?
Does the current code create a real problem?
Is the proposed change easier to understand?
Does the change improve maintainability?
Does it introduce additional abstraction for a trivial case?
A smaller codebase is not automatically a better codebase.
4. Verify That the Fix Preserves Behavior
This is the most important review step.
Suppose an agent changes:
if (items != null && items.Count > 0)
{
Process(items);
}
to:
if (items?.Count > 0)
{
Process(items);
}
The change may be perfectly valid.
But when the fix is more substantial, compare the behavior before and after.
Pay particular attention to:
Null handling
Exception behavior
Ordering
Concurrency
State changes
Validation
Authorization
Transactions
Serialization
Numeric calculations
Date and time handling
A quality improvement should not silently become a functional change.
5. Review Tests Before Accepting the Fix
A generated fix should ideally come with tests when the change affects behavior.
If the pull request modifies application logic, check whether the existing tests actually cover the changed path.
For example:
[TestMethod]
public void CalculateTotal_WithDiscount_ReturnsExpectedValue()
{
var result = CalculateTotal(
orderTotal: 100m,
discount: 20m);
Assert.AreEqual(80m, result);
}
The test should verify the behavior that matters, not merely execute the changed line.
Also check edge cases:
Zero
Negative values
Null values
Empty collections
Maximum values
Invalid input
Unexpected state
Passing tests are useful evidence, but test coverage is not proof that the change is correct.
6. Run the Full CI Pipeline
Do not rely only on the validation performed by the agent.
After accepting or modifying the generated change, run the repository's normal CI checks.
For a .NET application, that commonly includes:
dotnet restore
dotnet build --configuration Release
dotnet test --configuration Release
For applications with integration tests:
dotnet test \
--configuration Release \
--filter Category=Integration
Use the commands appropriate for your repository.
GitHub specifically recommends verifying that CI continues to pass after applying an autofix and confirming that the finding is resolved before merging.
7. Check Dependency Changes Carefully
AI-generated changes can sometimes modify project dependencies.
Review any changes to:
<ItemGroup>
<PackageReference
Include="Some.Package"
Version="1.2.3" />
</ItemGroup>
Do not approve a dependency change simply because it makes the finding disappear.
Check:
Why the dependency was added
Whether it is already available in the project
Whether the version is supported
Whether it introduces a transitive dependency
Whether it changes licensing considerations
Whether the package is actively maintained
Whether the dependency is actually necessary
Dependency changes deserve the same scrutiny as changes to application code. GitHub also recommends using dependency review when evaluating changes introduced by autofix.
8. Look for Unnecessary Refactoring
An agent may find a quality issue in one method and change several related methods.
That can be useful, but it also increases review complexity.
Consider this example:
public string FormatCustomer(Customer customer)
{
return $"{customer.FirstName} {customer.LastName}";
}
If the finding concerns string handling, there may be no reason to introduce a new formatting service, interface, abstraction, and dependency injection registration.
A good fix should be proportional to the problem.
When reviewing an agent-generated pull request, ask:
What is the smallest change that correctly resolves this finding?
If the generated solution is much larger than necessary, simplify it.
9. Check Application-Specific Rules
Static analysis works from general rules.
Your application may have rules that are not visible to the analyzer.
For example, an organization might require:
All database access through repository classes
No direct HTTP calls from controllers
Specific logging conventions
Specific exception types
No synchronous database operations
All external calls to use retry policies
A generated fix can satisfy a quality rule while violating one of these internal conventions.
Check the repository's:
Contribution guidelines
Coding standards
Architecture rules
Custom instructions
Security requirements
Review policies
Agentic autofix can follow repository or organization instructions configured for Copilot, but reviewers should still confirm that the resulting code follows the team's actual architecture and standards.
10. Check Security-Sensitive Changes Manually
Be especially careful when an autofix touches:
Authentication
Authorization
Cryptography
SQL queries
File access
Deserialization
Input validation
HTTP requests
Secrets
Permissions
For example, replacing a query implementation might remove one static-analysis warning but introduce a different security problem.
A security-sensitive fix deserves manual review even when automated analysis reports that the original finding has been resolved.
11. Review the Generated Explanation
Agentic autofix pull requests include information about what was changed and how the fix was validated.
Use that explanation as a starting point, not as proof.
For example:
Changed:
- Updated validation logic
- Added a null check
- Added unit tests
Validation:
- CodeQL analysis passed
- Unit tests passed
That tells you what the agent claims to have done.
You still need to compare the explanation with the actual diff.
A useful review technique is:
Agent explanation
|
v
Actual diff
|
v
Tests
|
v
Application behavior
If these four do not agree, stop and investigate.
12. Be Careful With False Positives
Some findings do not represent problems in the context of your application.
For example:
// Intentionally ignored result because this operation is best-effort.
_ = cache.Remove(key);
A quality rule might flag the pattern, but changing it may make the intent less obvious.
If a finding does not apply, dismiss it using the appropriate reason rather than applying a meaningless code change.
GitHub's Code Quality workflow explicitly supports reviewing a finding and either applying the fix, delegating remediation, or dismissing a finding that does not apply.
Agentic Autofix vs Developer-Written Fix
Area | Agentic autofix | Developer-written fix |
|---|
Initial implementation | Generated by Copilot | Written manually |
Repository exploration | Agent can inspect related code | Developer controls investigation |
Validation | Can run configured validation | Developer chooses validation |
Pull request | Can create a draft PR | Developer creates or updates PR |
Business context | Limited to available context | Developer has direct domain knowledge |
Final decision | Developer | Developer |
The important difference is not whether AI or a developer typed the code.
The important difference is who is responsible for deciding that the change belongs in the application.
That responsibility remains with the development team.
A Practical Review Checklist
Before merging an agentic autofix pull request, check:
[ ] I understand the original finding.
[ ] The finding actually applies to this code.
[ ] I reviewed the complete diff.
[ ] The change is limited to the required scope.
[ ] Existing application behavior is preserved.
[ ] Tests cover the changed behavior.
[ ] New tests are meaningful, not just coverage fillers.
[ ] The full CI pipeline passes.
[ ] Dependency changes were reviewed.
[ ] Security-sensitive code was reviewed manually.
[ ] The change follows project architecture and coding standards.
[ ] No unrelated refactoring was introduced.
[ ] The original finding is actually resolved.
[ ] I understand why the proposed fix is correct.
If several boxes remain unchecked, the pull request is not ready to merge.
Common Mistakes
Merging Because CodeQL Passed
CodeQL validation answers a specific question. It does not prove that the application's business behavior is correct.
Reviewing Only the Changed Line
Agentic fixes can affect multiple files. Review the entire pull request.
Trusting the AI Explanation More Than the Diff
The diff is the source of truth for what changed.
Ignoring Tests Because the Agent Ran Validation
Automated validation is useful, but your application's CI pipeline remains the final engineering check.
Accepting Large Refactoring for a Small Finding
A quality issue should not become an excuse for unnecessary architecture changes.
Forgetting Dependencies
A seemingly small fix can introduce or update a package. Review it separately.
Final Takeaway
Agentic autofix can reduce the time developers spend fixing repetitive code quality problems. GitHub Code Quality can detect issues through CodeQL-based rules, provide autofix suggestions, and use Copilot to handle more involved remediation work.
That does not remove the need for code review.
The safest workflow is simple: understand the finding, inspect the complete diff, verify the behavior, review tests and dependencies, run CI, and then decide whether the change belongs in the codebase.
Treat an agent-generated pull request like any other pull request. The fact that an AI agent created and validated the fix changes how the code was produced, not who is responsible for merging it.
Join the conversation! Your thoughts help the community grow.