Agentic coding adds hidden tech debt to production software

At a glance

What this is: Ory argues that agentic coding boosts speed but creates hidden technical debt when code agents write new code instead of reusing existing implementations.

Why it matters: This matters to IAM practitioners because the same pattern appears in identity programmes when automated systems create duplicate logic, inconsistent controls, and harder-to-audit change paths.

👉 Read Ory's analysis of the hidden cost of agentic coding

Context

Agentic coding is the use of AI code agents to draft, refactor, and test software with limited human oversight. The governance problem is not only whether the code compiles, but whether the agent is reusing approved logic, preserving architectural intent, and avoiding duplicate paths that weaken long-term control. In identity and access programmes, the same failure mode appears when automation builds parallel workflows instead of respecting the source of truth.

Ory's article frames this as a code quality and delivery issue, but the underlying control question is broader: how do organisations prevent AI-assisted change from creating governance drift? The answer is not blanket prohibition. It is disciplined oversight, stronger discovery, and explicit human ownership at the points where reuse, privilege, and production impact intersect.

Key questions

Q: How should teams stop AI code agents from creating duplicate logic?

A: Teams should require agents to prove they searched for an existing implementation before writing new code. That means asking the agent to name the module, package, or library it considered and to explain why reuse was not possible. The control is not just technical search. It is a workflow gate that makes duplication visible before it becomes permanent.

Q: Why does agentic coding increase maintenance risk over time?

A: Agentic coding increases maintenance risk because local changes accumulate into parallel implementations, dead code, and inconsistent behaviour. Tests can pass in the short term while architectural drift grows underneath. The danger is not one bad commit. It is many small decisions that make the codebase harder to understand, harder to refactor, and more expensive to change safely.

Q: What do security and engineering teams get wrong about AI-assisted development?

A: They often confuse faster output with better control. AI assistants can generate code quickly, but they do not automatically preserve architecture, reuse patterns, or the source of truth. If teams only measure throughput, they may miss the fact that they are borrowing speed from the future and creating systems that are harder to govern.

Q: When should human review be mandatory in agentic development?

A: Human review should be mandatory whenever the change affects shared libraries, production paths, or any logic that many systems depend on. Those are the points where context matters most and where a mistaken local optimisation creates the largest long-term cost. Humans bring memory of prior failures that the agent does not have.

Technical breakdown

Why code agents duplicate logic in large codebases

Code agents usually search through file systems, text, or language-server abstractions, which works poorly when the right implementation lives in another package or behind an abstraction. Because the model has a limited context window, it cannot reliably maintain a durable mental model of a large repository. When discovery fails, the agent often writes new code rather than finding and adapting existing logic. That is rational in the moment, but it creates architectural duplication that tests may not catch immediately.

Practical implication: require agents to cite the existing implementation they searched before they are allowed to add new code.

How hidden tech debt accumulates in agentic development

Tech debt appears when near-duplicate paths diverge over time. One bug gets fixed in one branch but not the other, behaviour drifts, and engineers lose confidence in refactors because the system no longer has one clear source of truth. The problem compounds as the codebase grows, because every new addition increases the chance that future agents will miss the canonical module and create yet another variant. The result is not just more code, but lower change reliability.

Practical implication: treat code cleanup, de-duplication, and dead-code removal as delivery work, not optional maintenance.

Why human oversight remains a control, not a ritual

Human engineers retain the architectural memory that agents lack. They know where the source of truth lives, which libraries already exist, and which shortcuts have previously caused breakage. Agent memory files and repository rules help, but they are static fragments, not live understanding. That means humans must intervene where reuse, architecture, and production risk matter most. In identity programmes, this same principle applies when automation touches privileged workflows or lifecycle logic.

Practical implication: route production code changes and identity-control changes through explicit human review when architectural reuse is at stake.

NHI Mgmt Group analysis

Agentic coding debt is a governance problem, not just a productivity trade-off. Ory is describing a familiar failure mode: automation that optimises for immediate output while silently increasing long-term control complexity. The issue is not whether code agents can work, but whether they can preserve a stable architecture without human context. For IAM teams, the parallel is duplicate policy paths that are faster to create than to govern. The practitioner conclusion is simple: measure change quality, not just change volume.

Reuse-before-write is the right named control concept for agentic development. The article makes clear that agents default to creating new code when discovery fails, which means the organisation must force a reuse discipline into the workflow. That is a governance pattern, not a coding preference. It aligns with broader identity principles where teams should validate the source of truth before provisioning new access or logic. Practitioners should treat reuse verification as a required gate.

Context loss is the hidden dependency behind unsafe AI-assisted change. Code agents do not maintain a durable mental model of the system, so each session reset increases the chance of local optimisation and duplicate implementation. This mirrors a wider identity governance lesson: systems that forget their prior state are prone to drift, exception sprawl, and untracked variation. The practitioner takeaway is to strengthen discovery, logging, and review paths wherever AI modifies live systems.

Human involvement remains the control that prevents architectural fragmentation. Ory's core claim is not anti-agent, but pro-accountability. Engineers bring repository memory, pattern recognition, and knowledge of prior failures that the model does not possess. That makes human oversight most important at the exact points where tooling is most tempted to bypass it: production code, reuse decisions, and cleanup work. The field implication is that AI-assisted delivery needs governance, not just guardrails.

What this signals

Reuse-before-write is likely to become a governance pattern in AI-assisted software delivery, not just a development preference. As agents expand their footprint, organisations will need evidence that new code was necessary, not merely convenient. That shift echoes identity governance, where the real control is proving why a new entitlement or workflow exists before it is allowed to persist.

The practical signal for security and engineering leaders is that AI coding controls will increasingly look like change-control controls. Expect more emphasis on architectural approvals, repository discovery quality, and post-change cleanup, especially where code touches authentication, authorisation, or secrets handling. In those areas, duplicated logic becomes an access and assurance problem, not only a maintenance problem.

For practitioners

• Enforce a reuse-before-write gate Require code agents to identify the existing implementation, document where they searched, and explain why the canonical module was not reused before new code is accepted.
• Track the cost of change alongside velocity Add metrics for duplication rate, dead code, and refactor difficulty so delivery dashboards show whether speed is creating future maintenance burden.
• Make cleanup part of the release definition Treat de-duplication, dead-code removal, and test correction as release criteria, not separate technical debt projects that never get scheduled.
• Require human review for architectural changes Route any agent-generated change that touches shared libraries, production code paths, or privileged workflows through a named engineer who owns the design.

Key takeaways

• Agentic coding creates hidden debt when AI assistants write around missing context instead of reusing existing code.
• The operational risk is architectural drift, where duplicate paths, dead code, and inconsistent behaviour slowly erode change confidence.
• Teams should govern AI-assisted development with reuse gates, human review, and cleanup as part of delivery, not after it.

Key terms

• Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.
• 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.
• Source of truth: A source of truth is the authoritative store that holds the current, trusted version of project state or operational knowledge. For AI workflows, it should be a controlled system such as a repository, task platform, or note vault that agents can read and update through governed access paths.
• Reuse Before Write: Reuse before write is a governance pattern that requires teams and automated tools to look for an existing approved implementation before creating a new one. It reduces duplication, preserves architectural consistency, and makes AI-assisted change more auditable and controllable.

What's in the full article

Ory's full blog post covers the operational detail this post intentionally leaves for the source:

• Why limited context windows lead code agents to search poorly in large repositories
• The specific ways agents create duplicate code, dead code, and false test confidence
• Why human engineers still need to own architecture and reuse decisions
• Practical workflow changes for teams that want agentic coding without compounding tech debt

👉 Ory's full post covers the memory limits, reuse failures, and maintenance risks behind agentic coding

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, IAM, and machine identity security. It helps security practitioners build the control discipline needed for automated systems that touch access and production workflows.