By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: SonarPublished October 15, 2025

TL;DR: AI coding assistants can increase developer productivity by up to 55%, but Sonar argues that the same velocity also drives more duplication, review bottlenecks, and technical debt unless automated verification keeps pace. The core issue is not AI quality alone, but unmanaged change volume, which turns speed gains into long-term delivery and security drag.


At a glance

What this is: This is an analysis of how AI-assisted coding increases code volume faster than manual review can absorb, creating more duplication, complexity, and technical debt.

Why it matters: It matters because security and identity teams increasingly depend on software delivery pipelines, and uncontrolled code drift can weaken access logic, policy enforcement, and trust boundaries across the stack.

By the numbers:

  • 55%, -assisted coding can raise developer productivity by up to 55%, according to Sonar, but that same speed can overload review capacity and accumulate quality liabilities.
  • 60%, assisted pull requests reduced median resolution time by more than 60%, yet the faster throughput also increased the burden of review and verification.
  • 2025 DORA analysis found that 90% more AI, % more AI adoption correlated with a 9% rise in bug rates, a 91% increase in code review time, and a 154% increase in pull request size.

👉 Read Sonar's analysis of AI coding velocity, quality drift, and automated verification


Context

AI-assisted development changes the economics of software delivery, but it does not remove the need for verification. When code generation accelerates faster than review and testing can scale, teams accumulate duplicated logic, brittle architecture, and hidden defects that later become operational and security debt. For identity and security-sensitive systems, that drift matters because access control, secrets handling, and trust decisions are only as strong as the code that implements them.

Sonar's argument is that the problem is not AI output in isolation, but the organisation's ability to govern it at the same speed. That makes the issue relevant to IAM, PAM, and NHI programmes whenever engineering teams embed access logic, authentication flows, or secret management into rapidly changing code paths.

This starting position is increasingly common in AI-enabled engineering environments, especially where delivery pressure has outpaced governance maturity.


Key questions

Q: What breaks when AI coding tools are trusted without strong verification?

A: What breaks first is consistency. Without strong verification, teams inherit hidden defects, uneven quality, and release decisions based on confidence rather than evidence. Over time, that creates verification debt, where more code is generated faster than the organisation can responsibly assess and approve it.

Q: Why does AI-generated code create more technical debt so quickly?

A: AI increases output volume and repetition, so insecure patterns can spread before teams notice them. When review capacity stays static, cleanup lags behind creation and debt compounds across repositories. The problem is not only bad code, but the speed at which weak patterns become organisational defaults.

Q: How can security teams tell whether code verification is keeping pace with AI output?

A: Look for smaller pull requests, stable review times, lower duplication rates, and declining defect escape rates. If review time rises while AI adoption increases, the control model is already lagging. For identity-heavy code, also watch for repeated changes to authentication, token logic, and privilege enforcement.

Q: Should organisations use AI-generated code in security-sensitive workflows?

A: Yes, but only with strict controls around review, testing, and ownership. For security-sensitive workflows, the key question is not whether AI can generate code, but whether the organisation can prove its behaviour, maintainability, and failure modes. Without that proof, the delivery gain is offset by hidden risk.


Technical breakdown

Why AI-generated code increases duplication and complexity

Large language models are optimised to produce locally plausible code quickly, not to preserve architectural consistency across a repository. That makes duplication, inconsistent abstractions, and shallow refactoring more likely when teams accept generated output without strong review gates. Metrics such as cyclomatic complexity and duplicated line frequency rise because the system rewards immediate functionality over maintainability. The result is not simply more code, but more code that is harder to reason about, test, and secure at scale.

Practical implication: treat AI-generated code as untrusted until automated analysis has checked for duplication, complexity, and architectural drift.

Where manual review becomes the bottleneck

Manual review does not scale linearly with AI-generated throughput. As pull requests get larger and arrive more frequently, reviewers spend more time detecting regressions, tracing dependencies, and validating security-relevant changes. The bottleneck shifts from writing code to proving that the code is safe, coherent, and maintainable. That is why velocity gains can reverse if quality controls remain manual. In high-change environments, the review process itself becomes a production constraint.

Practical implication: reduce dependency on human-only review by inserting automated verification at branch and merge boundaries.

How automated verification acts as a trust layer

Automated code analysis platforms function as a last-mile trust control between generation and production. They detect patterns that generic AI assistants often miss, including duplicate blocks, outdated constructs, and inconsistent implementation patterns that degrade maintainability. In security terms, this is a governance layer for code integrity: it does not replace developer judgment, but it standardises what must be checked before code can proceed. That makes policy enforcement repeatable even when AI output volume rises sharply.

Practical implication: make automated quality and security checks mandatory in every pull request and merge path.


NHI Mgmt Group analysis

AI coding assistants create governance debt faster than they create productivity gains. The article's central claim is that velocity without verification shifts risk downstream rather than eliminating it. For security and identity teams, that matters because access logic, token handling, and permission checks are often buried inside rapidly changing application code. Organisations should treat AI-assisted development as a control problem, not just an engineering efficiency story.

Automated verification is becoming the control plane for software trust. Manual review cannot keep pace when code output scales faster than reviewer capacity. That is why code quality gates, repository-wide analysis, and merge-time enforcement are now part of secure software governance, not optional optimisation. In framework terms, this aligns with NIST-CSF and NIST SP 800-53 expectations for change control, integrity monitoring, and secure development.

Identity-sensitive code deserves stricter analysis than ordinary application code. If AI-generated changes touch authentication, secrets management, or privilege boundaries, the cost of accepting structural defects rises sharply. The more the code path governs who can do what, the more quality drift becomes an IAM and NHI issue as well as a software issue. Practitioners should classify identity logic as high-risk code and gate it accordingly.

Managed acceleration is the right operating model for AI-enabled engineering. The question is no longer whether to adopt AI coding tools, but whether the organisation can absorb their output without degrading reliability. Strong teams will pair generation with automated verification, while weaker teams will mistake faster commits for faster delivery. The practical conclusion is clear: speed only becomes value when quality controls scale with it.

Code integrity is now a security control, not just a developer preference. Once AI increases the rate of change, poor structure, duplicated logic, and review fatigue become enterprise risks. This is especially relevant where software controls identity, because weak code can undermine authentication, authorisation, and auditability. Teams that ignore this shift will see more defects, slower remediation, and less trustworthy release pipelines.

What this signals

AI-assisted development is shifting the governance burden from code creation to code validation. For security teams, that means the decisive question is no longer whether developers can ship faster, but whether release controls can still prove that identity logic, secrets usage, and authorisation flows remain trustworthy at machine speed.

Verification debt: the gap between change velocity and review capacity becomes a measurable risk in any programme that embeds access control in application code. Where that gap widens, defects are more likely to reach production before anyone can reason about their impact. That is why teams should connect software quality telemetry to identity and access risk reviews, not leave them in separate operating silos.

Where AI-generated changes affect authentication or privileged workflows, control design should borrow from least privilege thinking in the application layer. The relevant standard is not more developer enthusiasm, but stronger trust boundaries, better change evidence, and faster rollback capability.


For practitioners

  • Embed automated quality gates in every merge path Require static analysis, duplication checks, and complexity thresholds to pass before code can merge into protected branches. Use branch protection to make the gate mandatory rather than advisory.
  • Classify identity and secrets code as high-risk Tag authentication, authorisation, token handling, and secrets management code for enhanced review because defects in these paths can weaken access control across the whole platform.
  • Shrink pull requests to reduce reviewer overload Set practical size limits and encourage smaller changes so reviewers can validate logic, security impact, and regression risk without missing defects hidden in large AI-generated diffs.
  • Track duplication and complexity as release signals Monitor duplicated line frequency, cyclomatic complexity, and review turnaround as indicators that AI output is outpacing control capacity.

Key takeaways

  • AI-assisted coding increases the volume of change faster than manual review can safely absorb.
  • When review capacity lags, duplication, complexity, and latent defects accumulate into delivery and security debt.
  • The practical answer is automated verification at branch and merge boundaries, especially for identity-sensitive code.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.IP-2The article centres on change control and secure SDLC discipline.
NIST SP 800-53 Rev 5CM-3Controlled change management is central to keeping AI-generated code trustworthy.
CIS Controls v8CIS-16 , Application Software SecurityThe article is about secure software governance under accelerated development.
ISO/IEC 27001:2022A.8.25Secure development lifecycle controls apply directly to this quality and governance issue.

Align development rules, testing, and release approval with A.8.25 for controlled software change.


Key terms

  • Technical debt: Legacy shortcuts or weak design choices that create future cost, risk, or operational friction. In identity programmes, technical debt often shows up as brittle trust relationships, inconsistent revocation, poor traceability, or controls that only work in one environment and fail in another.
  • Cyclomatic Complexity: Cyclomatic complexity measures how many paths exist through a piece of code. Higher complexity usually means harder testing, slower review, and greater maintenance risk. In security-sensitive systems, complexity also makes it easier for defects in authentication, access control, or validation logic to remain hidden.
  • Code Verification Layer: A code verification layer is the set of automated checks that confirms software changes meet quality and security requirements before release. It typically includes static analysis, policy gates, and repository controls. In fast-moving AI-assisted pipelines, it becomes the main mechanism for preserving trust in the codebase.

What's in the full article

Sonar's full analysis covers the operational detail this post intentionally leaves for the source:

  • Benchmark data on AI-assisted pull request size, review time, and defect trends across engineering teams
  • Guidance on integrating SonarQube into branch, pull request, and merge workflows
  • Practical examples of duplication and complexity findings that automated verification can surface
  • The vendor's explanation of how context-aware analysis fits into high-velocity SDLC governance

👉 Sonar's full article details the code quality metrics, review bottlenecks, and governance model behind managed acceleration.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps security and identity practitioners connect software change to access risk across modern delivery pipelines.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org