Why do autonomous coding agents struggle in large codebases with long project history?

Why This Matters for Security Teams

autonomous coding agent can be productive on bounded tasks, but large codebases with long project history expose a different problem: the agent may see files and recent conversation, yet still miss the reasons those files exist. That gap creates risk in dependency changes, hidden ownership boundaries, and behaviour that is enforced by convention rather than code. Guidance in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward the same operational reality: context, traceability, and governance matter as much as model capability.

The practical issue is not just code quality. An agent that lacks project history can introduce subtle regressions, bypass local patterns, or overwrite design decisions that were never captured in a spec. That becomes more dangerous when teams assume the system is “remembering” simply because the chat history is still available. Persistent memory can support continuity, but it does not create organisational knowledge, accountability, or architectural judgment.

In practice, many security teams encounter these failures only after a seemingly correct code change has already altered a dependency chain, broken an inherited convention, or exposed a production defect.

How It Works in Practice

Large codebases usually contain implicit knowledge spread across tickets, merge requests, release notes, runbooks, and old design decisions. A coding agent can retrieve fragments of that history, but retrieval is not the same as comprehension. If the agent is not grounded in repository structure, change ownership, and current system state, it may optimise for the local prompt rather than the broader software lifecycle. That is why agentic development needs more than an LLM and a vector index; it needs policy, provenance, and verification.

Security and engineering teams generally reduce the risk by constraining what the agent can change, what evidence it must consult, and when a human must approve. Current guidance suggests treating autonomous code actions as higher risk when they affect authentication, secrets, deployment logic, or shared libraries. A useful control pattern is to require the agent to justify why a change is safe, cite the code paths it inspected, and submit a test plan before merge. The CSA MAESTRO agentic AI threat modeling framework is relevant here because it emphasises tool access, workflow boundaries, and agent behaviour across multi-step tasks.

• Limit agent write access to the smallest viable scope.
• Require retrieval from canonical sources such as architecture docs, ownership files, and release history.
• Validate outputs against tests, linters, and policy checks before merge.
• Log which files, prompts, and tools influenced the final change.

For higher-risk environments, teams can also map the agent’s actions to NIST AI Risk Management Framework functions and use NIST SP 800-53 Rev 5 Security and Privacy Controls to anchor approval, logging, and change control expectations. These controls tend to break down when repository history is fragmented across multiple forks and undocumented hotfixes, because the agent cannot reliably reconstruct the system’s true dependency and ownership graph.

Common Variations and Edge Cases

Tighter agent controls often increase development overhead, requiring teams to balance speed against the risk of silent architectural drift. That tradeoff becomes sharper in monorepos, legacy platforms, and fast-moving product teams where history is rich but poorly structured. In those environments, an agent may appear competent on greenfield code while still being unreliable on older modules with hidden coupling.

There is no universal standard for how much history an agent must retain to be safe. Best practice is evolving toward layered memory: short-term task context, project-level retrieval, and explicit human review for changes that touch critical paths. The most common edge case is when a codebase has many “tribal knowledge” rules that are not documented anywhere. Another is when the agent is given broad tool access but limited observability into previous incidents or design tradeoffs.

Frameworks such as the OWASP Top 10 for Agentic Applications 2026 and the MITRE ATLAS adversarial AI threat matrix are useful for distinguishing simple productivity failures from security-relevant manipulation, such as prompt injection, poisoned context, or tool misuse. Where autonomous coding is extended into deployment or incident response workflows, teams should also consider the risk of AI-orchestrated abuse patterns described in Anthropic’s first AI-orchestrated cyber espionage campaign report. The guidance becomes weakest when legacy repositories lack clean commit history and no single source of truth exists for ownership, because the agent cannot separate valid patterns from accidental ones.

Related resources from NHI Mgmt Group

• Why do traditional IAM controls struggle with autonomous AI agents?
• Why do existing IAM controls struggle with autonomous AI agents?
• How should security teams govern autonomous coding agents in software delivery pipelines?
• Why do traditional IAM and PAM controls struggle with autonomous AI agents?