Code quality in the age of AI needs verification, not hope

At a glance

What this is: This is an analysis of how code quality changes in AI-assisted development, with the key finding that verification and static analysis become the control layer when humans can no longer review every line reliably.

Why it matters: It matters to IAM practitioners because AI-generated code increasingly touches authentication, secrets, and access logic, so weak code quality can quickly become an identity and privilege exposure issue.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Sonar's analysis of code quality in the age of AI

Context

Code quality is no longer just a software engineering discipline. In AI-assisted development, it becomes a governance problem because generated code can introduce hidden security flaws, poor architectural decisions, and identity control mistakes faster than manual review can reliably catch them.

The identity angle is real even in a coding article: insecure code frequently becomes insecure access logic, leaked secrets, or over-privileged service accounts. That is why AI-generated code needs to be treated as part of the trust boundary for IAM, PAM, and NHI governance, not as a purely developer workflow issue.

When teams rely on static analysis, testing, and code review as control points, they are really building assurance around the software supply chain. In practice, the starting position described here is increasingly typical for teams using AI coding assistants at scale.

Key questions

Q: What breaks when AI-generated code is only checked after commit?

A: Post-commit controls miss the moment when risky code is created, so secrets, insecure patterns, and policy violations can enter the repository before security ever sees them. That makes audit evidence incomplete and weakens defensibility. The practical failure is timing, because detection after commit cannot prove that policy was enforced at generation time.

Q: Why does AI-assisted development increase application identity risk?

A: Because many applications implement identity controls in code, and AI tools can reproduce insecure login, token, and access patterns at scale. That means the risk is not limited to software defects. It extends to the trust boundaries that govern users, service accounts, and any downstream system that accepts those credentials as valid.

Q: How do you know if data quality controls are actually working?

A: Look for fewer manual remediation cycles, faster detection of inconsistencies, and higher confidence in shared datasets across teams. Effective controls should reduce debate about whether data can be used and increase the speed at which defects are corrected. If people still hesitate to act on the data, the control environment is not yet working.

Q: Should organisations require manual review for every AI-written code change?

A: Not necessarily for every minor change, but they should require human accountability for every AI-generated contribution that reaches merge or production. The right model is selective human review plus mandatory automated testing, ownership assignment, and policy gates for code that affects secrets, access control, or external exposure.

Technical breakdown

Why AI-generated code creates code quality debt

AI-generated code changes the failure model because large volumes of output can be syntactically correct yet architecturally brittle. The problem is not just bugs. It is hidden assumptions, hallucinated dependencies, weak error handling, and inconsistent patterns that accumulate into code quality debt. In security-sensitive systems, that debt often lands in authentication flows, token handling, and access checks, which means a code issue can become an identity issue. Static analysis and policy-based guardrails matter because they inspect structure, not just intent.

Practical implication: treat AI-generated code as untrusted until it passes deterministic validation.

Static analysis, cognitive complexity, and security controls

Static analysis is effective because it detects patterns humans miss at scale, including code smells, unsafe API use, and control-flow complexity. Cyclomatic complexity measures the number of execution paths, while cognitive complexity reflects how hard code is for a human to reason about. High scores in either often correlate with fragile logic and harder security review. For identity-related code, that fragility can hide broken authorisation checks or improper secret handling. The value is not just bug reduction. It is shrinking the space where policy, identity, and security logic can drift out of sync.

Practical implication: set quality thresholds for complexity and security findings before code can merge.

How verification fits into the AI coding workflow

Verification has to move into both the inner loop and the outer loop of development. Inner-loop checks give the agent immediate feedback while it is generating code, while outer-loop scans validate the final output before merge or deployment. That division matters because AI systems can generate large asynchronous payloads that make human line-by-line review unrealistic. In practice, code quality becomes a trust problem: the system that writes the code must also be constrained by the system that verifies it. That model is especially important where code controls access, secrets, or service identities.

Practical implication: add automated verification gates before merge and before release.

NHI Mgmt Group analysis

AI code quality debt is now a governance issue, not a style issue. The article correctly frames code quality as a control problem because AI-written code can scale defects, not just accelerate delivery. In identity-heavy systems, poor-quality code often creates weak authentication paths, mis-scoped permissions, and secret exposure. Practitioners should treat generated code as part of the privileged attack surface.

Verification must replace trust in human review alone. Human peer review still matters for intent, but it cannot absorb the volume and speed of AI-generated output. That creates a structural gap between what teams assume they can inspect and what the pipeline actually produces. The implication is clear: automated verification becomes the primary assurance mechanism for code that touches access control or workload identity.

Code quality is the hidden dependency behind secure identity logic. Identity and access controls only work when the surrounding code implements them consistently. If engineering teams allow complex, noisy, or hallucination-prone output to reach production, they are also allowing control drift into IAM-adjacent logic. That means code quality tooling now sits upstream of both application security and identity governance.

Dynamic guardrails are more relevant than post-hoc remediation. The article points toward a named concept we can call AI code quality debt, meaning the backlog of structural risk created when machine-written code is accepted faster than it can be verified. Once that debt accumulates, security teams inherit the cost through rework, exposure, and brittle controls. Practitioners should push quality enforcement left, before insecure patterns are normalised.

For AI-assisted development, the real standard is audit-ready code. Readability and maintainability still matter, but regulated and security-sensitive environments now need traceability, deterministic checks, and repeatable assurance. That aligns with broader governance expectations for software supply chains and controlled change. Practitioners should treat audit readiness as a code-quality outcome, not a compliance add-on.

What this signals

AI-assisted development is pushing security teams toward evidence-based verification rather than trust-based review. The programme implication is that code quality tooling now needs to sit alongside application security, secrets management, and identity controls, not below them in the build chain.

A useful operating model is to treat AI-generated code as a governed supply chain artefact. That means linking static analysis, test coverage, and dependency validation to the same control expectations that already apply to privileged access and release approvals.

The next maturity step is not more review meetings. It is better machine-enforced assurance, especially for code that touches authentication, token exchange, and workload identities.

For practitioners

• Define merge gates for AI-generated code Require static analysis, unit tests, and security checks to pass before any AI-generated change can merge into the main branch.
• Set complexity thresholds for identity-related code Flag high cyclomatic complexity and high cognitive complexity in authentication, authorisation, and secrets-handling paths because those are the places where logic drift becomes security drift.
• Separate intent review from structural verification Use manual peer review for business intent and automated tools for syntax, control flow, dependency issues, and security findings so each review type does what it does best.
• Treat generated code as untrusted until verified Assume AI-generated pull requests may include hallucinated packages, unsafe defaults, or hidden access-control flaws, and block release until the final scan is clean.

Key takeaways

• AI-generated code changes code quality from a developer preference into a security control problem.
• Identity, secrets, and access logic are the most dangerous places to let unverified machine-written code slip through.
• Automated verification, not human goodwill, is the only scalable way to keep AI-assisted code audit-ready.

Key terms

• Code Quality Check: A code quality check evaluates how maintainable and readable code is over time. It focuses on structural issues such as complexity, duplication, dead code, and naming, helping teams identify where future changes are likely to become slower, riskier, and more expensive.
• Cyclomatic Complexity: Cyclomatic complexity measures how many independent paths exist through a piece of code. Higher values usually mean the logic is harder to test, review, and secure because there are more branches where defects or control failures can hide.
• Cognitive Complexity: A metric that estimates how hard a function or code path is to understand, based on nesting, branching, and flow changes. Higher scores usually mean more mental effort for reviewers and a greater chance of maintenance errors.
• Technical Debt Ratio: Technical debt ratio is the estimated cost of fixing existing code problems compared with the cost of building the system. It is useful because it turns maintainability into a measurable signal, helping teams decide when the cost of delay or rework is becoming operationally significant.

What's in the full article

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

• Specific code-quality dimensions and metric definitions, including cyclomatic complexity, cognitive complexity, code coverage, and technical debt ratio.
• Examples of how static analysis and automated review fit into CI/CD workflows for large, AI-assisted codebases.
• More detail on SonarQube's inner-loop and outer-loop verification model for agent-generated code.
• The article's explanation of how quality profiles and guided remediation are meant to reduce noise and speed correction.

👉 The full Sonar article covers metric definitions, CI/CD integration, and AI code verification details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, IAM, and workload identity. It is designed for practitioners who need identity controls that hold up under modern development and operational pressure.