TL;DR: Agentic coding can speed delivery by parallelising tasks, but Ory argues that unsupervised use in production code increases duplication, dead code, and long-term maintenance cost because code agents lack durable codebase memory and reuse discipline. The security implication is broader than productivity: when AI systems make local changes without stable context, governance must shift toward controlled reuse, review, and change cost management.
At a glance
What this is: Ory says agentic coding improves throughput, but weak codebase memory and shallow discovery cause agents to create duplicate or dead code that becomes hidden tech debt.
Why it matters: This matters because IAM and security teams increasingly rely on AI-assisted development, and unchecked code sprawl increases review burden, change risk, and long-term control drift.
Context
Agentic coding is the use of AI coding agents to draft, refactor, test, and document software with partial independence. The problem is not the tooling itself, but the way limited context, weak discovery, and local optimisation can produce new code instead of reusing existing implementations.
For IAM-heavy systems, that matters because identity flows, access logic, and API controls depend on consistent reuse and predictable change paths. When agents create parallel implementations, teams inherit control drift, duplicated logic, and harder-to-audit behaviour across the software estate.
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 are the warning signs that agent-generated code is becoming tech debt?
A: Look for parallel implementations of the same function, unused code paths, tests that repeat the production logic, and repeated changes in the same area after agent-assisted commits. Those symptoms show the repository is accumulating local fixes instead of coherent reuse, which usually means future refactoring cost is rising.
Q: Should teams trust repository memory files to govern agentic coding?
A: No. Memory files and repo rules can help agents stay oriented, but they are static summaries, not a durable understanding of the system. They work best as guardrails for review and search behaviour, while humans remain accountable for architecture choices, control consistency, and high-risk code paths.
Technical breakdown
Why code agents duplicate logic in large codebases
Code agents operate inside a limited context window, which means they only see a slice of the repository, related docs, and recent conversation history. When the correct implementation lives in another package, behind an abstraction, or in a file the agent never opened, the model often cannot reliably infer reuse. The result is a rational but costly behaviour: it writes new code rather than locating and extending what already exists. In large systems, that produces parallel implementations that look correct locally but diverge over time.
Practical implication: require agents to show where they searched before accepting new implementation paths.
How dead code and test drift accumulate
Dead code appears when an agent creates functions, wrappers, or tests that are not actually used in production paths. That risk is especially high when the agent avoids touching complex existing code and instead adds something adjacent that passes tests in isolation. The same pattern can produce misleading tests that reimplement the logic they are meant to validate, creating false confidence. Over time, this widens the gap between what the repository contains and what production actually executes.
Practical implication: treat unused code and suspiciously self-contained tests as delivery defects, not harmless by-products.
Why context files help but do not solve agent memory gaps
Repository rules and memory files can improve consistency, but they remain static summaries rather than a live mental model of the system. They still compete for limited context space and cannot capture every dependency, exception, or historical decision that matters in real architecture. That means they reduce but do not eliminate the risk of agents making local changes that conflict with broader design intent. Human reviewers still have to own the architecture-level judgment about where reuse is required and where new code is justified.
Practical implication: use memory files as guardrails, not as a substitute for architectural review and change governance.
NHI Mgmt Group analysis
Hidden tech debt is the real governance issue in agentic coding: the risk is not simply that AI writes code, but that it writes the wrong kind of code at scale. When agents cannot reliably find the existing implementation, they create parallel logic that is harder to secure, test, and retire later. For IAM and security-sensitive software, that turns reuse discipline into a control objective, not a style preference.
Codebase memory is becoming a software governance control. Human engineers accumulate context across releases, defects, and architecture decisions in ways agents cannot yet match. That means the organisation needs explicit controls around discovery, reuse, and review so that context loss does not become uncontrolled complexity growth. Practitioners should treat repository navigation quality as a security and maintainability dependency.
Agentic coding shifts the cost of change forward and sideways: short-term delivery can look faster while long-term maintenance becomes more expensive. That is especially true when teams count output volume instead of change quality, because duplicated code inflates testing, review, and incident response effort. The practitioner conclusion is simple: measure cost of change, not just lines shipped.
AI-assisted development and IAM intersect through control consistency: identity logic, authentication flows, permissions checks, and API keys are exactly the areas where duplicated paths create hidden drift. If agents introduce slightly different versions of those controls, teams can end up with inconsistent enforcement across the codebase. The practical answer is to centralise high-risk identity logic and make reuse the default path.
Named concept: code reuse debt: repeated failure to reuse existing implementation becomes a compounding governance problem because every new branch increases maintenance cost and weakens architectural certainty. The longer teams allow agents to optimise for local task completion, the more expensive future refactoring becomes. Practitioners should manage agent output as change risk, not only as productivity output.
From our research library:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: Top 10 NHI Issues
What this signals
Code reuse debt: agentic coding creates a new governance problem when task-level speed hides architecture-level fragmentation. Teams that do not force reuse checks will eventually pay for it in security review effort, regression risk, and slower change control.
For identity-heavy systems, the highest-risk pattern is not raw code volume but inconsistent implementation of authentication, authorisation, and key-handling logic. That is where agent outputs need the strongest review discipline and the narrowest permission to invent new paths.
For practitioners
- Enforce reuse-before-write review Require the agent to identify the existing implementation, explain why it is not sufficient, and cite the files or modules it inspected before generating new code.
- Centralise identity and access logic Keep authentication, authorisation, permissions, and API key handling in shared modules so agents have a clear source of truth instead of inventing parallel flows.
- Flag dead code and duplicate tests in delivery gates Add review checks for unused functions, duplicate paths, and tests that mirror implementation logic instead of validating behaviour.
- Measure cost of change alongside velocity Track how many modifications require cross-file edits, follow-on fixes, or refactoring after agent-assisted commits, then use that trend to decide where agentic coding is appropriate.
- Treat memory files as guardrails, not memory Use repository rules and summary files to guide agents, but keep human review responsible for architecture, reuse decisions, and high-risk production paths.
Key takeaways
- Agentic coding can improve throughput, but unmanaged reuse decisions turn that speed into hidden technical debt.
- The main failure mode is local code generation that bypasses existing architecture, creating duplicate logic, dead code, and misleading tests.
- Teams reduce risk by making reuse explicit, centralising identity logic, and measuring cost of change instead of velocity alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Agentic coding tools can misuse available code surfaces by generating new logic instead of reusing existing implementations. |
| ASI03 — Identity & Privilege Abuse | Production code changes are a privilege problem when AI agents can alter identity and access logic without durable context. | |
| Recommendation — Constrain agent tool use so code search and edit actions must prove reuse before new implementation is accepted. Limit agent permissions around authentication and authorisation code paths and require human approval for privileged edits. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance of AI-assisted development behaviour and accountability for resulting risk. |
| Recommendation — Define clear accountability for AI-assisted code changes and tie agent use to governance controls. | ||
| NIST CSF 2.0 | PR.PS-05 — Secure Development Life Cycle | The article is about development practices that affect software integrity and maintainability. |
| Recommendation — Apply secure development lifecycle controls to review, test, and manage agent-generated code. | ||
| NIST SP 800-53 Rev 5 | CM-9 — Configuration Management Plan | Agentic coding changes repository state in ways that need controlled traceability and review. |
| Recommendation — Use configuration management to track agent-assisted changes and prevent uncontrolled divergence. | ||
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.
- Code Reuse Debt: Code reuse debt is the accumulated cost created when teams repeatedly add new implementations instead of extending existing ones. It increases maintenance burden, makes refactoring riskier, and weakens confidence that a codebase still has one clear source of truth.
- Dead Code: Dead code is code that remains in a repository or deployed system but is not used by any real production path. It creates security and operational risk because it can hide stale logic, outdated dependencies, and forgotten access points, while also making testing, auditing, and incident response more difficult.
- Context Window: The context window is the text a model receives at one time, including prompts, retrieved documents, and conversation history. Security teams care about it because it becomes the practical boundary between trusted instructions and untrusted content, especially when the application assembles that text automatically.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control discipline to the broader software and security programmes they run.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org