AI coding agents need codebase context before they write

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonar's blog post: AI coding agents need live codebase context before generation, or they will write plausible code that fits syntax but not system design.

Why it matters: For IAM and security teams, the lesson is that governance has to start before code is generated, because context gaps create drift, rework, and downstream control risk.

By the numbers:

• Cleaner repositories reduced input tokens by 7.2% and output tokens by 8.5% in Sonar's Claude Code study.
• Code smells accounted for roughly 90% or more of every model's issues in Sonar's Java benchmark, ranging from 89.9% to 94.9%.
• Claude Sonnet 4's bugs were 93% more likely to be rated BLOCKER than Claude 3.7 Sonnet's, at 13.71% versus 7.10%.
• GitClear analyzed 211 million meaningful changed lines of code across private companies and large open-source projects.

Context

AI coding agents are not inherently aware of a repository's architecture, conventions, or hidden constraints, so they tend to produce code that is syntactically valid but misaligned with how the system is actually governed. In practice, that creates architectural drift, which is a code quality problem with direct implications for maintainability, security review, and the reliability of downstream controls.

Sonar's core claim is that teams should treat codebase context as a first-class governance input rather than as prompt hygiene. That matters to identity and security practitioners because the same pattern appears in agentic AI security: if the system generating changes does not start from the right context, review happens too late and control failures become more expensive to correct.

The article's evidence is consistent with a broader platform concern, not a single tool issue. When code generation happens in a vacuum, organisations pay twice, first in rework and then in the cumulative burden of drift across future changes.

Key questions

Q: What is the first thing teams should do when AI coding agents are producing drift?

A: Start by giving the agent live repository context, including architecture, module boundaries, and local constraints, before it generates any code. If the model is guessing about how your system is built, later review will only find drift after the work and token cost have already been incurred.

Q: Why do AI coding agents get slower and more expensive as codebases grow?

A: They usually rely on exact-match tools such as grep, glob, and find, then iterate through many files to build a working model of the codebase. As repositories expand, that guessing loop increases tool calls, token usage, and runtime. Semantic retrieval helps because it returns likely relevant functions, types, and modules by meaning, not filename alone.

Q: What are the signs that an AI coding agent is failing to understand a repository?

A: Look for duplicated logic, reintroduced anti-patterns, changes that ignore intended boundaries, and repeated reprompting after review. Those are strong indicators that the agent is optimising for plausible output instead of repository fit, which means context is missing or stale.

Q: How should engineering teams govern AI agents when code generation becomes autonomous?

A: Engineering teams should treat AI agents as active participants in the software delivery process, not as passive tools. That means defining clear human accountability, enforcing deterministic verification, and making code integrity the common language between people and agents. The goal is to scale review at machine speed without losing control over what reaches production.

Technical breakdown

Why context-free generation produces architectural drift

An AI coding agent generates from statistical patterns unless it is given repository-specific constraints, so it will often choose the most likely implementation rather than the one that matches local architecture. That means it can create duplicate logic, break intended module boundaries, or reintroduce patterns the team has already banned. The problem is not that the code is always wrong in isolation. The problem is that it is right in the abstract and wrong in the system. Context injection changes the agent's search space before generation, which is fundamentally different from review after generation.

Practical implication: provide live architectural context before code is written, not just rules after the fact.

Why review and linting cannot repair missing codebase context

Review, linting, and CI are verification controls. They are useful, but they operate after the model has already created the change, which means they detect drift instead of preventing it. If the underlying issue is that the agent could not see the intended design, post-hoc checks only turn a context gap into a rework cycle. The article's point is that teams confuse control detection with control prevention. In agentic development, the most expensive defects are the ones that pass first generation and are only discovered when a human has to unwind them.

Practical implication: use verification to catch residual errors, but do not rely on it as the primary control.

How context augmentation reduces token waste and change churn

Context augmentation gives the agent the information it needs to reuse existing code, follow intended constraints, and navigate to the right places in the repository. That reduces the amount of surrounding code it has to inspect and the amount of output it has to generate before arriving at a valid change. The result is lower token consumption, less churn, and fewer follow-up iterations. The mechanism matters because cost is not driven only by what the agent writes, but by how much of the repository it must consume to write it well. Cleaner inputs produce cleaner outputs and less governance overhead.

Practical implication: measure agent efficiency as a governance outcome, not just a cost metric.

Threat narrative

Attacker objective: The objective is not hostile compromise but control failure by omission, where the agent quietly introduces code that undermines the intended system design.

1. Entry occurs when an AI coding agent is allowed to generate changes inside a repository without live architectural context or repository-specific constraints.
2. Credential access is not the issue here; the failure is contextual blind generation that lets the agent produce plausible but misaligned code paths, duplicate logic, and banned patterns.
3. Impact arrives as architectural drift, higher token usage, more review and rework, and a steadily harder-to-govern codebase.

Breaches seen in the wild

• PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Codebase context is now a governance control, not an engineering convenience. When an AI coding agent cannot see intended boundaries, rules, and historical exceptions, it will optimise for plausibility rather than fit. That makes generation a control problem, not just a productivity problem. For teams running agent-assisted development, the real question is whether the agent starts from governed context or from guesswork.

Architectural drift is the named failure mode of agentic coding. The article shows a specific control gap: static prompts and late review cannot preserve system design as the repository evolves. Once that drift becomes normalised, every subsequent change inherits more complexity and more review burden. Practitioners should treat drift as an operating condition to eliminate, not a style issue to tolerate.

AI coding agents expose the limits of verify-only development. Verification still matters, but it cannot compensate for a generation step that never had the right context. That is the same governance pattern seen in other identity and agentic AI domains: if the system making the change lacks authoritative context, downstream checks only document the failure. The practitioner conclusion is to move trust left, into issuance of context and constraints.

Context-aware agenting is becoming the difference between scalable and unscalable software governance. Repositories that supply architecture graphs, dependency guidance, and targeted coding rules will force less rework and consume fewer tokens per change. Repositories that depend on human memory and prompt files will keep paying interest on drift. Teams should therefore manage codebase context as a durable platform capability.

Agentic development creates a new class of technical debt that looks like efficiency on day one. Fast code generation can hide duplicate patterns, reintroduced anti-patterns, and security blind spots until they accumulate into expensive maintenance. That is why the governance conversation should move from output volume to output fit. The practitioner conclusion is to measure whether agents preserve the system you already have, not just whether they write code quickly.

From our research library:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• Read next: AI Coding Agents Security Guide

What this signals

Architectural drift is now a measurable AI governance problem. Teams should stop treating prompt quality as the main variable and start treating codebase context as part of the control plane for agentic development. When the repository itself provides the rules, boundaries, and intent, agents are less likely to create rework that later review must unwind.

Context before generation is the control pattern to watch. That pattern aligns with broader identity and agent governance thinking: the safest decision is made before action, not after output. For practitioners, the implication is clear: if an agent can write into production workflows, its context should be governed with the same seriousness as its credentials.

Guide before verify becomes the operating model for coding agents. Verification remains necessary, but it should confirm a change that already had the right context, not compensate for missing system knowledge. The more complex the repository, the more likely this ordering determines whether agent use scales safely.

For practitioners

• Implement live repository context injection Feed agents current architecture graphs, module boundaries, and intended constraints before generation so they can work from governed system knowledge.
• Move review controls upstream Keep linting and human review, but use them as verification after context-aware generation rather than as the primary defence against drift.
• Track architectural drift as an operational metric Measure duplication, reintroduced anti-patterns, and repeated follow-up edits to see whether agents are creating hidden maintenance burden.
• Govern agent prompts as a platform asset Replace per-developer prompt files with centrally managed guidance that updates as the codebase changes and remains consistent across IDEs.

Key takeaways

• AI coding agents can produce code that compiles while still drifting from the repository's architecture and conventions.
• Sonar's evidence links cleaner codebases to lower token use, less churn, and fewer costly follow-up corrections.
• The control point is context delivery before generation, because review-only workflows detect drift after the cost has already accumulated.

Key terms

• Architectural Drift: The gradual divergence between the system structure a team intends and the structure that the codebase actually expresses. It usually emerges through shortcuts, duplicated logic, and boundary violations that accumulate over time until the code becomes harder to understand and change safely.
• Context Augmentation: A pattern for injecting only the most relevant information into an AI agent’s working context before it acts. In security workflows, it is used to reduce noise, constrain tool use, and make the agent’s next step more efficient and more predictable.
• Verification Controls: Verification controls are checks that confirm an identity action actually took effect in downstream systems. In practice, they close the gap between a governance decision and the real access state, which is essential when certification, offboarding, or revocation can otherwise remain only on paper.
• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps security and platform teams apply identity-first governance to emerging agent workflows and related access decisions.