Topic starter
20/08/2026 5:51 pm
TL;DR: Among more than 4,000 Java tasks, GPT-5.2 High delivers the strongest security posture at 16 blocker vulnerabilities per MLOC, but also produces the highest code volume at 974,379 LOC, while Claude Sonnet 4.5 reaches 198 blocker vulnerabilities per MLOC and Opus 4.5 Thinking drops that to 44, according to Sonar. Functional correctness is not enough when AI-generated code also creates maintainability and review burden at scale, especially for teams shipping into production.
Editorial analysis by NHI Mgmt Group, based on content published by Sonar: “New data on code quality: GPT-5.2 high, Opus 4.5, Gemini 3, and more”.
Key questions
Q: What fails when teams choose AI coding models only by pass rate?
A: They can end up selecting models that solve benchmark tasks while generating code with hidden security defects, excessive verbosity, and large amounts of technical debt.
Q: Why do verbose AI-generated codebases increase security risk?
A: Verbose code usually adds more branches, more state, and more opportunities for inconsistent validation or error handling.
Q: How can organisations tell whether an AI coding model is safe enough to use?
A: Use model-specific measures rather than generic vendor claims.
Practitioner guidance
- Define acceptance thresholds for AI-generated code Set separate gates for functional correctness, blocker vulnerabilities, concurrency defects, and maintainability smells before code enters merge review.
- Run static analysis on every AI-generated change Scan generated code for injection patterns, path traversal, unsafe resource handling, and excessive complexity before approval.
- Benchmark models on security-sensitive tasks Compare candidate models using the same prompt set and measure not only pass rate but also blocker density and smell volume.
Bottom line: AI coding tools can produce code that passes tests while still creating serious review, security, and maintainability debt.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:31 pm
AI-generated code introduces governance debt, not just development acceleration. When teams optimise for pass rate alone, they underweight the code review, remediation, and refactoring burden that arrives after generation. This is especially relevant where generated code touches authentication, session handling, or data processing logic. Practitioners should treat model selection as an assurance decision, not a productivity purchase.
A few things that frame the scale:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations treat AI code generators as developer tools or software supply chain risk?
A: They should treat them as both, but govern them as supply chain risk first. Generated code can enter the build with latent defects that are harder to detect than ordinary programming mistakes, so model evaluation, scanning, and review controls belong upstream of release. Productivity gains do not remove the need for assurance controls.
👉 Read our full editorial: AI code quality trade-offs expose security and maintainability debt