Stack Overflow's 2025 Developer Survey put a hard number on something security teams had already started to feel in their pull request queues: trust in AI tool accuracy fell to 29%, down from roughly 40% the year before, with 46% of developers now actively distrusting AI output versus only 33% who trust it. Just 3% say they "highly trust" the results. Yet 84% of developers still use or plan to use AI tools — the adoption curve keeps climbing while the trust curve falls, and that gap is exactly where AI-generated vulnerability fixes live or die. The same survey found 66% of developers cite "AI solutions that are almost right, but not quite" as their top frustration, and 45% say debugging AI-generated code actually costs them more time than writing it themselves. For a security team piping thousands of CVEs through an auto-fix engine, this isn't an abstract UX concern — it's the difference between a tool developers merge on sight and one they route to a folder of unread notifications. This post looks at why fix suggestions specifically trigger this distrust faster than other AI output, what GitHub's own Copilot Autofix data shows about partial coverage, and what a fix-acceptance UX that actually earns trust looks like in practice.
Why do AI fix suggestions erode trust faster than AI code completion?
A fix suggestion carries an implicit claim that code completion doesn't: "this is safe to apply to a security problem." When a completion suggestion is wrong, a developer edits it mid-keystroke and moves on — the cost of a miss is seconds. When a fix suggestion is wrong, the cost is a merged PR that either breaks a build or, worse, leaves the vulnerability present under a false sense of closure. Stack Overflow's 2025 data shows 87% of developers are concerned about the accuracy of AI-generated output in general; that concern compounds specifically for security fixes because the failure mode is asymmetric — a bad autocomplete is caught by the compiler, but a bad security patch can pass every existing test and still leave a CWE-89 injection path open. Every fix a developer has to unwind after merging spends down trust faster than it was built, and unlike a suggestion rejected at write-time, a bad fix PR often isn't discovered until the next scan cycle.
What does GitHub's own Autofix data reveal about partial coverage?
GitHub's Copilot Autofix documentation is explicit that the tool "won't be able to generate a fix for every alert" and requires human review before any change is accepted — an admission baked directly into the product, not a caveat added after complaints. GitHub's engineering team reported that expanding Autofix coverage to a single CodeQL alert group (one representing 29% of all CodeQL alerts) produced only an 8% overall increase in alerts with an available fix, even though autofixes for that specific group grew 270%. That's a useful data point for anyone evaluating an auto-fix vendor: a large relative improvement in one alert category can still translate into a small absolute increase in overall coverage. The lesson for UX design is that presenting fix availability honestly — showing coverage percentage per finding category rather than implying blanket automation — sets expectations a developer can calibrate trust against, instead of discovering the gaps alert by alert.
Does trust in AI suggestions build the same way trust in a colleague does?
Largely yes, and the data on general Copilot usage supports it: suggestion acceptance rates start around 27–30% for new users and climb to roughly 34% by the sixth month of continuous use, tracking a slow accumulation of track record rather than an instant judgment. Developers don't extend blanket trust to a fix engine on day one any more than they'd merge a first-time contributor's security patch without review — trust is built incrementally, fix by fix, as a developer confirms the tool got easy cases right before they'll stop double-checking harder ones. This has a direct design implication: a fix-suggestion system that front-loads its riskiest, most invasive changes (large dependency major-version bumps, rewritten authentication logic) before a developer has any track record with the tool is optimizing for the wrong sequence. Confidence should be built the way a new hire's is — start narrow, prove out low-risk changes, and let the scope of autonomy expand only after a demonstrated pattern of correct fixes.
What does alert-fatigue research from the SOC world teach fix-suggestion design?
Security operations centers have run this experiment for a decade longer than AI fix tools have existed, and the results are a warning. Multiple 2023–2025 industry studies on SOC alert volume, including analyses cited in AI SOC market research, put the false-positive rate of security alerts at roughly 83%, with estimates of alerts that go uninvestigated ranging from 40% to 63%; in practitioner surveys, roughly 32% say they've started ignoring alerts from sources they no longer trust. The mechanism is volume times low precision: once an analyst's mental model of a source shifts from "usually right" to "often wrong," they stop reading it carefully at all, which is worse than not sending the alert. Auto-generated fix PRs are subject to the identical mechanism — a repository that accumulates a stream of fix PRs with a mediocre hit rate trains its maintainers to stop reviewing them carefully, which defeats the entire purpose of automating the fix in the first place. The fix isn't more PRs; it's fewer, better-targeted ones with a visible, honest accuracy signal attached.
What does a trust-preserving fix-suggestion UX actually look like?
The pattern that survives contact with real developer skepticism has a few concrete features, not just good intentions. First, classify blast radius before generating the fix, not after: a change to a version pin is a different risk class than a change to authentication logic, and the UI should say so in plain terms — GitHub's own Autofix and comparable tools in the market use a tiered breaking-change label (safe, minor, major, critical) so a developer can triage review effort by risk rather than treating every fix PR identically. Second, gate on tests: a fix PR that already ran the existing test suite and reports the result up front removes a step a skeptical developer would otherwise do manually before trusting it. Third, default risky changes to require approval and only auto-create PRs for the safe tier — start with safe fixes and let confidence in the pipeline build gradually before expanding scope to major or critical changes, rather than asking for blanket trust immediately. Fourth, be honest about volume: deduplicating overlapping findings across scanners into a single fix, with a stated reduction percentage, keeps the PR queue small enough to actually review — but only if the categories that must never be softened, like malware and secrets, are always surfaced in full regardless of dedup logic. None of these features make the underlying model more accurate. They make its accuracy legible, which is what determines whether a developer clicks merge or lets the PR rot.
How Safeguard approaches this
Safeguard's AI Remediate capability, powered by Griffin AI, applies several of these principles directly rather than treating fix generation as an all-or-nothing automation switch. Every fix carries a breaking-change classification — Safe, Minor, Major, or Critical — so reviewers can allocate scrutiny by actual risk instead of reading every diff line by line. Teams configure whether safe fixes auto-create pull requests or require explicit approval, and test integration runs before a PR is opened so the result is visible up front rather than discovered after merge. Safeguard's own guidance mirrors the pattern the data supports: start with safe fixes to build confidence gradually, and require manual review on major or critical changes rather than auto-merging them. On the noise side, AutoTriage deduplicates overlapping findings across scanning engines and reports a measured reduction percentage, so the volume of fix suggestions a team sees stays proportional to real distinct risk — with a hard guarantee that malware and secrets findings are never suppressed by that process, no matter how aggressive the deduplication. The goal isn't to claim higher accuracy than the underlying models can support; it's to make the fix pipeline's actual accuracy and risk visible enough that developers can extend trust at the pace the data says trust is actually built.