An AI-code critique still needs the original survey question
Favorability, trust and observed defects measure different things. Trace the question and population before using a statistic to justify an engineering policy.
Sixty percent favorable towards AI tools is not the same claim as sixty percent trusting their accuracy.
The 2025 Stack Overflow Developer Survey reports 60% positive sentiment towards AI tools and 33% trust in their accuracy. They come from different questions. Relabelling the first as trust does more than round a number: it changes what respondents were asked.
This matters whether the surrounding argument celebrates AI coding or attacks it. I want the same sourcing standard for the critique that I expect from the generated work being criticised.
Preserve the question with the percentage
A developer can find a tool useful while distrusting a particular answer. The two survey results can coexist without contradiction. Neither result is a direct measurement of defect rates in that developer's repository.
As an illustration, I would take one hypothetical AI-policy slide containing a dramatic percentage and trace it backwards. The desired endpoint is the original question, the respondent group, the year and the method—not another article repeating the same number.
If the slide says code quality declined, but the source asks how developers feel about a tool, I would change the claim or remove the number. If a study measures changes in one set of repositories, I would keep that population attached rather than expanding it to all software development.
This is also why a missing primary source is not proof that a statistic is false. It is a limit on what I can responsibly assert. The useful response is to leave the claim unverified until the evidence is found, rather than turning the failure to find it into a new accusation.
A maintainer's account is stronger than a generic backlash story
Daniel Stenberg's January 26 account provides a concrete case. curl ended its bug-bounty rewards at the end of January while keeping private vulnerability reporting available. Stenberg describes the burden of low-quality reports and also says curl's experience differed from other open-source bounty programmes in its comparison cohort.
That last detail improves the argument. It prevents one project's serious problem from becoming an unsupported claim that every programme experienced the same increase. The case is useful precisely because its operator describes the mechanism and the boundary.
For an engineering team, I would translate it into a local question about review burden. Which submissions consume time without producing accepted fixes? Can the team identify recurring defects in the evidence supplied? What can be checked before scarce maintainer attention is spent?
Those questions can guide a test without pretending that a survey percentage proves the answer. In a hypothetical internal review, I would record submission volume, review time and accepted outcomes under the current process, then compare a clearly defined change. The result would describe our workflow under those conditions.
A critique built this way may contain fewer impressive numbers. It will contain more information a peer can use: the task, the failure, the evidence and the proposed intervention.
Before reusing a statistic in the next AI discussion, copy the original question into your working notes. If that wording changes the point you intended to make, you have found the edit that matters. Keep the narrower claim; it is more likely to survive contact with the source.
The original question is part of the statistic, especially when the statistic is being used to criticise unreliable AI.
