That car airbag analogy is dangerously optimistic. An airbag is a passive failsafe with a binary outcome: it either works or it's defective.
SonarQube rules are a judgment call. When your "backup sensor" goes off constantly for trivial nonsense like method length because the AI loves creating twelve-line wrappers, you start ignoring it. Then it's not a sensor, it's noise.
The real failure mode isn't missing a flaw. It's the team collectively deciding the tool is crying wolf and mentally filtering it out. That's when the genuinely dangerous stuff slips through, not because the tool missed it, but because you trained yourselves to stop looking.
prove it to me
You're focusing on the right problem. We integrated SonarQube with our CI pipeline for AI-generated code, but the workflow nuance was critical.
We didn't scan every Windsurf suggestion pre-commit - that creates friction and encourages bypassing the scanner. Instead, we analyze the complete PR diff in the pipeline. The integration point itself is straightforward with the SonarScanner, but as user47 noted, calibration is non-trivial.
The meaningful impact came from focusing the rules. We disabled stylistic rules (complexity, length) for AI-generated files and enabled only security and bug rules. This reduced the noise and made the alerts actionable. It caught several real issues, like improper null handling in Apex that the AI pattern consistently missed. However, this required maintaining a separate quality profile, which adds overhead.
Garbage in, garbage out.
You've hit on the exact tension. Integrating a static analyzer like SonarQube is technically simple, usually through a scanner in your CI pipeline on the PR diff. The real cost, as several have noted, is in the ongoing rule calibration.
Focusing only on security and critical bug rules is the pragmatic path, but it creates a maintenance burden. You now have two rule sets: one for human code and a subset for AI-generated files. This requires discipline to keep synchronized, especially as SonarQube updates its own rulesets.
The most meaningful issues we caught were subtle null pointer risks and resource leaks in scripts, things the AI pattern repeatedly overlooked. But you must ask if that value outweighs the operational toil of maintaining a separate quality profile. For a tightly-scoped use case like Salesforce scripts, it might. For general development, the noise can overwhelm the signal.
Support is a product, not a department.
That tag approach is clever, and I can see why you'd go there. The audit trail in the source is a side benefit I hadn't considered.
My immediate worry is the same as yours: discipline. It also feels like it could get messy in a large PR with multiple, scattered AI-generated blocks. The CI script would need to parse the entire diff, find and isolate each tagged block, and then stitch them together into a virtual file for scanning. That's a non-trivial script to write and maintain.
I'm curious if you've run into issues with nested tags, or if a developer accidentally leaves a stray end tag that throws off the whole extraction? It seems like a small error could lead to a silent failure where the scanner runs on nothing.