AI coding speeds up output but not delivery without security checks

At a glance

What this is: This is an analysis of why AI-assisted coding increases output faster than it improves delivery, with Kusari arguing that earlier security checks can remove the rework that slows pipelines.

Why it matters: It matters to IAM and security practitioners because faster code generation still leaves identity, secrets, and review controls as the real delivery bottlenecks in modern software pipelines.

By the numbers:

• Google sees only about a 10% increase in velocity despite roughly 30% of code getting an assist from AI in some form.
• Kusari says it dropped mean time to remediation for vulnerabilities from 110 days to 1 day in one month.

👉 Read Kusari's analysis of why AI coding does not automatically speed delivery

Context

AI coding tools can increase code production without removing the security and review work that still governs delivery. In practice, teams often discover that faster generation simply pushes more changes into an already constrained pipeline, where vulnerabilities, dependencies, and approval cycles become the limiting factors. The same pattern appears in IAM-heavy software environments, where code speed does not eliminate the need to govern secrets, access, and release risk.

The article's central point is that delivery velocity depends on the slowest control point, not the fastest developer assist. For IAM and NHI programmes, that means secret exposure, unreviewed dependencies, and weak pre-merge controls can turn AI-assisted development into a governance problem rather than a productivity gain.

Key questions

Q: How should security teams reduce rework when AI accelerates code changes?

A: They should move security checks closer to authoring time, because the cost of fixing issues rises sharply after merge. Inline remediation in the IDE reduces context switching, rebuilds, and review churn. Teams should still keep downstream scanning, but the primary control should prevent avoidable defects from entering the pipeline in the first place.

Q: Why do AI coding tools often fail to produce proportional delivery gains?

A: Because code generation is only one step in delivery. If security review, dependency approval, and remediation remain manual, the pipeline still moves at the pace of its slowest control point. AI can increase output, but it does not automatically remove the queueing and governance work that determines what actually ships.

Q: What do teams get wrong about measuring AI coding productivity?

A: They often measure lines of code or developer output instead of end-to-end delivery time. That misses the cost of rework, re-review, and remediation. A useful metric set includes pull-request cycle time, vulnerability fix time, and the number of changes blocked by security checks before merge.

Q: How should organisations handle identity and secrets risk in AI-assisted pipelines?

A: Treat AI-generated code as a higher-volume source of identity and secrets exposure. That means continuous secret scanning, tighter approval for code touching access logic, and faster remediation of risky dependencies. The goal is to keep credentials, service identities, and access assumptions from scaling faster than the controls around them.

Technical breakdown

Why AI-assisted coding does not automatically increase delivery velocity

Code generation is only one stage in software delivery. If pull requests, security scanning, dependency review, and remediation remain manual, the pipeline still absorbs the same governance overhead, just with more code flowing through it. That creates a queueing effect: AI reduces one task's duration but leaves the rest unchanged, so end-to-end throughput barely moves. In security terms, the control plane did not scale with the production plane. The result is more work entering review, not more value reaching production.

Practical implication: measure delivery bottlenecks across the full release path, not just developer output.

How pre-merge security checks reduce rework

Pre-merge controls shift security left by catching vulnerabilities, unmaintained libraries, and risky patterns before code lands. That matters because rework is multiplicative: every defect found after merge creates extra review, retesting, and release delay. Automated checks in pull requests can reduce the number of times a change cycles through engineering and security teams. In identity-heavy applications, this also helps surface hardcoded secrets, overbroad access patterns, and configuration drift before they become production incidents.

Practical implication: enforce security gating in pull requests for high-risk code paths and dependency changes.

Why AI speed exposes governance debt in secrets and access control

When AI increases code volume, it also increases the chance that insecure patterns are copied, merged, or deployed faster than humans can review them. That is particularly relevant to secrets management and identity governance, because machine-generated code may embed credentials, reference stale permissions, or expand the number of services that need controlled access. The article points to a broader truth: governance debt accumulates when delivery systems scale faster than controls. AI then amplifies existing weaknesses instead of fixing them.

Practical implication: pair AI coding adoption with stricter secrets scanning, access review, and dependency governance.

NHI Mgmt Group analysis

AI coding creates a throughput illusion when security review remains serial. The article shows that faster code generation does not equal faster delivery when the review, remediation, and approval layers stay unchanged. That is a process design problem, not a developer productivity problem. For identity-heavy environments, the same logic applies to secrets, privileges, and release approvals. Practitioners should treat AI-assisted development as a queue-management issue, not just an engineering efficiency story.

Pre-merge control is now a delivery control, not just a security control. When vulnerabilities are found late, they consume the same scarce resource that teams need for feature delivery: engineering time. Security scanning in pull requests therefore becomes part of release economics. If the organisation cannot stop insecure code before merge, it will pay for it repeatedly in rework. The practical conclusion is to design controls that reduce downstream friction, not add another review layer.

AI-driven development intensifies governance debt in code, dependencies, and secrets. Generated code can spread insecure patterns faster than teams can inspect them, which makes dependency hygiene and secret detection more important, not less. This is where the intersection with identity governance becomes real: application code increasingly carries credentials, service-to-service trust, and access assumptions. Teams should assume AI will increase the volume of control points that need policy enforcement.

Runtime speed gains will remain capped until organisations remove the slowest trust decisions from the path. The article's core lesson is that value delivery is limited by the last manual gate, not the first automated task. In practice, that means release velocity will stay constrained until teams automate risk triage, tighten policy on code paths that touch credentials, and reduce avoidable re-review. The field should now treat governance automation as a throughput enabler.

Secrets discipline belongs inside modern software delivery economics. Once AI accelerates code production, secret hygiene can no longer be treated as a separate security programme. It becomes a direct determinant of how quickly code can safely move. Practitioners should connect application security, IAM, and developer workflow design so that security work shrinks instead of accumulating.

What this signals

Secrets governance will increasingly determine whether AI-assisted development improves throughput or simply increases exposure. Teams that cannot detect and remediate secret leaks quickly will see AI amplify their weakest operational links. The practical signal is to connect application security telemetry with IAM and secret lifecycle management, rather than treating them as separate programmes.

Delivery leadership should expect pressure to justify AI adoption with pipeline metrics that include remediation time, review duration, and blocked-change volume. If those numbers do not improve, the organisation has accelerated production without fixing the control plane that governs release risk.

For practitioners

• Implement pull-request security gates for high-risk changes Scan every merge request for vulnerabilities, unmaintained libraries, and embedded credentials before code can advance to review or release. This reduces rework and stops AI-generated mistakes from reaching later pipeline stages.
• Measure delivery friction beyond developer output Track time spent in security review, re-review, retesting, and remediation alongside code generation metrics. That shows whether AI is improving throughput or simply increasing queue depth.
• Tighten secret scanning around AI-assisted code paths Prioritise repositories, prompts, and build outputs where AI is used most heavily, because those paths are more likely to spread credential material or insecure access patterns quickly.
• Shorten the remediation loop for vulnerable dependencies Create an explicit owner and SLA for fixing dependency findings so they do not accumulate in the backlog. The goal is to remove the backlog effect that turns faster code creation into slower delivery.

Key takeaways

• AI coding increases production faster than it improves end-to-end delivery when security and review controls stay serial.
• The strongest evidence in the article is that faster remediation and pre-merge scanning can collapse rework, not just reduce risk.
• For practitioners, the priority is to make security gating, secret scanning, and dependency hygiene part of delivery economics.

Key terms

• Delivery Velocity: Delivery velocity is the rate at which work moves from development into production value. In secure software programmes, it depends on more than code creation. Security review, dependency checks, remediation, and release approvals all shape whether output becomes usable change.
• Pre-merge Security Gating: Pre-merge security gating is the practice of blocking risky code before it enters the main branch or release path. It reduces downstream rework by catching vulnerabilities, secrets, and dependency issues while changes are still cheap to fix.
• Governance Debt: The accumulation of unresolved identity control weaknesses created when teams prioritise speed over lifecycle design. In NHI environments, it shows up as accounts with unclear ownership, undocumented purpose, stale credentials, and no reliable retirement path, all of which make later security work harder.
• Secrets Scanning: Automated tooling that scans source code repositories, CI/CD pipelines, and cloud environments to detect exposed secrets such as API keys, tokens, and passwords before they are exploited.

What's in the full article

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

• The specific workflow changes Kusari used to cut remediation time from 110 days to 1 day
• How Kusari Inspector evaluates pull requests for vulnerabilities and unmaintained libraries
• The case study details behind the reported 8x velocity increase
• The webinar context and deployment discussion behind the delivery workflow

👉 The full Kusari post explains the remediation workflow, pull-request checks, and case study context in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners connect access controls to modern delivery workflows.