Rerunning CodeQL and closing a target alert is useful evidence for an agentic fix, but it does not replace functional regression testing or human review. A patch can remove an alert while changing application behavior. An absent alert also requires a completed analysis, comparable scope and a result belonging to the current revision.

GitHub announced agentic autofix general availability on October 15, 2026. For “How should an AI-generated security-fix PR be accepted?”, this article combines finding changes, revision identity and functional contracts rather than treating an agent’s completed checks as a merge decision. 中文版.

The workflow delivers a patch for review

The October 15 announcement describes code exploration, proposed edits, CodeQL reruns and iteration before a draft PR. Its stated scope was Enterprise Cloud customers with Code Security or Advanced Security, default-branch alerts, and up to 25 alerts in one PR, consuming AI Credits and Actions minutes.

The engineering change extends beyond one suggested edit into an investigate-modify-validate loop. A more complete delivery process does not remove review responsibility. A draft PR is an inspectable candidate; preserving interfaces, error handling and deployment behavior still requires standards supplied by the project.

This is a dated release analysis, not a claim that the feature launched today. The evidence model below is an original acceptance design, not GitHub’s built-in merge policy. No repository was changed and no real code scan was triggered.

Compare finding identities, not just totals

Let B be baseline findings, C post-patch findings and T the target set. Target disappearance means T∩C is empty, but also inspect new findings C−B and removed findings B−C. These set comparisons require comparable identities and analysis conditions. A fall from two findings to one does not identify which problem changed; an unchanged total can hide both a repaired old problem and a new problem.

For example, B={A,B}, T={A}, and C={B,C}. The count remains two, yet A disappeared and C appeared. A dashboard showing only “two findings” hides opposing changes. These letters stand for fictional stable identities; they do not claim a rule ID alone uniquely identifies a real alert.

A real integration needs tool-appropriate identity and matching rules, controlling repository, branch, analysis category and query configuration. Renames, moved locations and rule changes can affect matching. If continuity is uncertain, retain a needs-review state instead of counting an identity change as a repair.

Absence first requires usable evidence

An empty result can mean completed analysis found nothing, or that no usable result arrived. Build, extraction, analysis and upload are separate stages. A missing stage cannot automatically become “target closed”. Establish completeness and comparable coverage before interpreting disappearance.

The earlier AI Scan coverage analysis separates no finding from evidence of checking. Here the object is a before-and-after repair comparison, which additionally needs evidence that functionality survived the patch.

If a passing scan follows narrower queries, excluded files or a changed build path, changed measurement conditions may explain the result. Such adjustments can be legitimate, but need their own review and replacement evidence for affected code. Subtracting incomparable finding sets cannot establish a security improvement.

Bind results to the current revision

Suppose regression tests pass on PR revision H1 and the agent then produces H2. H1’s result describes H1, not automatically H2. Even a small later change needs an explicit decision about which evidence remains applicable and which should run again. An old green check can otherwise become mismatched with current code.

The model requires scan and regression evidence for the current head, with expected scan scope and test contract. Real systems can use commit identities, working-tree digests, build inputs and environment versions. These are not equivalent strengths of evidence; choose according to the project’s reproducibility needs and risk.

A string saying complete does not prove complete coverage. The program assumes complete and scope were populated by a trustworthy process. It checks how evidence is combined, not whether its input records are truthful. Fabricated or incorrect records invalidate higher-level reasoning regardless of the checker.

Nine offline checks still stop at human review

The checker first requires targets from the baseline, then checks revision, scan scope, completion and regressions before examining remaining targets and new findings. Its successful output is deliberately called ready for human review, rather than automatic merge or a safety certification.

# Fictional evidence contract, not a GitHub merge rule or a CodeQL runner.
from copy import deepcopy

base={'A','B'}
target={'A'}
head='head-b'
scan={'head':head,'scope':'suite-v1','complete':True,'findings':{'B'}}
tests={'head':head,'contract':'regression-v1','complete':True,'passed':True}

def review_state(base,target,head,scan,tests):
    if not target or not target <= base:
        return 'hold: target baseline'
    if scan['head'] != head or tests['head'] != head:
        return 'hold: stale revision'
    if scan['scope'] != 'suite-v1' or not scan['complete']:
        return 'hold: scan evidence'
    if tests['contract'] != 'regression-v1' or not tests['complete'] or not tests['passed']:
        return 'hold: regression evidence'
    if target & scan['findings']:
        return 'hold: target remains'
    if scan['findings'] - base:
        return 'hold: new finding'
    return 'ready for human review'

assert review_state(base,target,head,scan,tests)=='ready for human review'
s=deepcopy(scan);s['head']='head-a'
assert review_state(base,target,head,s,tests)=='hold: stale revision'
s=deepcopy(scan);s['complete']=False;s['findings']=set()
assert review_state(base,target,head,s,tests)=='hold: scan evidence'
s=deepcopy(scan);s['scope']='reduced-suite'
assert review_state(base,target,head,s,tests)=='hold: scan evidence'
s=deepcopy(scan);s['findings']={'A','B'}
assert review_state(base,target,head,s,tests)=='hold: target remains'
s=deepcopy(scan);s['findings']={'B','C'}
assert len(s['findings'])==len(base) and review_state(base,target,head,s,tests)=='hold: new finding'
t=deepcopy(tests);t['passed']=False
assert review_state(base,target,head,scan,t)=='hold: regression evidence'
t=deepcopy(tests);t['complete']=False
assert review_state(base,target,head,scan,t)=='hold: regression evidence'
assert review_state(base,{'Z'},head,scan,tests)=='hold: target baseline'
print('9 evidence-contract checks passed; no scan or merge executed')

Nine executed checks cover stale revisions, incomplete empty results, reduced scope, remaining targets, new findings hidden by equal counts, failed and incomplete regressions, and an invalid target baseline. All findings and revision names are fictional. No CodeQL analysis, agent session or PR merge ran.

The simplified rule pauses for any new finding. A real project can distinguish severity, accepted baselines and risk decisions, but should retain its rationale. Likewise, passing tests describe the tests that ran; the status alone does not imply every functional path was exercised.

Test behavior the patch could change

Human review can start with three concrete questions: can callers use the same interface, do ordinary inputs retain intended results, and do inputs meant to fail do so correctly? Add project-specific assertions for error types, cleanup, idempotence or concurrency according to the change. Every patch need not run an identical oversized suite, but the selection should have a reason connected to the edit.

Distinguish repairing a path from eliminating its functionality. Deleting a feature, swallowing every exception or returning an empty result can change what a scanner observes without meeting the application contract. No exploit sample is needed to make that point: review whether the required behavior still exists rather than merely whether a warning vanished.

With several alerts in one PR, inspect coupling among edits too. One cross-module refactor and several unrelated local fixes have different regression and rollback costs. A product’s batch limit is a capability boundary, not a target to fill. Establish explainable evidence for a patch before expanding the batch.

Make the repair conclusion traceable

A handoff record can contain target identities, baseline and current revisions, analysis configuration, removed and new findings, executed regressions and behavior awaiting human confirmation. It should let the next reviewer examine the conclusion, rather than providing only an “AI fixed it” narrative.

If evidence is insufficient, name the missing part before rerunning the agent: a completing build, a functional assertion, or an assessment of a new finding? Filling that gap is more useful than counting another attempt as another success. If only part of a target batch has usable revalidation evidence, retain the original task scope in reporting. Selecting only passing targets creates a misleading repair-rate denominator. No unmeasured repair rate, time saving or security benefit is claimed here.

If the set comparison and evidence contract help turn an AI repair PR into reviewable engineering work, voluntary support through the section below is welcome. The reusable result is knowing which evidence supports the fix and which decisions still need a person.

Sources and article date

October 15 announcement

Discovered through Google News and checked against the original announcement, published before the planned slot. Examples and diagrams are original teaching material, not a product benchmark or real account operation. The planned article date is 2026-10-20 at 11:30 Beijing time. Scheduling or actual public release is verified separately; a backfilled date does not imply earlier publication.