Summary: On October 13, 2026, GitHub added AI Scan metrics to security overview, letting organization and enterprise administrators see findings, remediation rates, and autofix adoption without opening individual pull requests. It’s a public preview on github.com for Code Security or Advanced Security customers, with GitHub Enterprise Server not supported. For anyone deciding whether AI-assisted code review is worth rolling out, this is the measurement layer that was missing.
What the new metrics actually cover
The security overview now shows how many AI Scan findings were generated and resolved, the overall remediation rate, which repositories produced findings, trends over your selected reporting period, and how often developers applied autofix suggestions. Those numbers come straight from GitHub’s changelog announcement, which also notes the metrics are designed to help teams evaluate AI Scan’s effectiveness across an org without manually reviewing PRs.
That last point matters. Rollout decisions for AI security tooling usually stall because nobody can answer a simple question: is it actually working? Now there’s a dashboard answer.
The page rename is a small signal
The “CodeQL pull requests” page is now called “Code scanning on pull requests,” with separate CodeQL and AI Scan tabs. Existing CodeQL metrics live under the CodeQL tab; the AI Scan tab shows total findings plus how many include an autofix suggestion and how many don’t.
It’s a naming change, but it tells you GitHub is treating AI Scan as a peer to CodeQL rather than a bolt-on experiment. If you’re configuring dashboards or writing internal docs, the old page name will break your references.
Why builders should care about remediation rate
Finding count alone is a vanity metric — a scanner that flags everything looks productive while drowning developers in noise. The useful numbers here are the remediation rate and autofix adoption. If devs resolve 80% of AI Scan findings and accept most autofixes, that’s a tool earning its keep. If findings pile up unresolved, you’ve added friction, not security.
This connects to a broader shift: teams shipping AI-generated code need instrumentation on the review side too, not just generation. We’ve covered adjacent ground before — like when admins gained control over default models in Copilot for JetBrains — and the pattern is the same: enterprise AI features get useful once admins can observe and govern them.
Practical limits before you plan around it
A few things to keep in mind. This is a public preview, so expect the metrics surface to change. GitHub Enterprise Server users can’t access it — you need github.com or GitHub Enterprise Cloud with Code Security or Advanced Security. And the changelog describes aggregate metrics, not per-finding workflow changes; if you wanted deeper triage tooling, the supplied announcement doesn’t promise that.
The practical next step: if you run AI Scan on PRs today, spend ten minutes in the new AI Scan tab and check your autofix adoption rate. It’s the fastest read on whether the feature is paying for itself in your repos — and if the number is low, that’s a conversation to have before renewal, not after.
Sources
View the original post on X