An AI coding agent working in your repository has never seen your architecture. It has not read your intended module boundaries, your team's conventions, the incident that made you ban a certain pattern, or the reason one service is intended to call another and a third is not. It writes from the statistical average of everything it was trained on, which is a vast amount of other people's code and almost none of yours. So it produces code that compiles, passes a quick read, and quietly drifts away from how your system is actually built.
That gap between "compiles" and "belongs" is not a matter of taste. It is a measurable cost, it compounds, and the way most teams try to close it (better prompts, more review) treats the symptom rather than the cause. The cause is that the agent is guessing about your codebase because nobody told it the truth. Sonar frames the fix as a phase called Guide, and the order matters: you have to guide before you verify before you solve.
What "operating in a vacuum" actually produces
Two independent bodies of evidence show what happens when agents generate without your context.
Sonar's study The Coding Personalities of Leading LLMs ran 4,444 identical Java programming tasks through leading LLMs and found, bluntly, that "all models have a fundamental lack of security awareness and a bias for messy code." The scale of the mess is the striking part: code smells are the maintainability problems that do not break the build but slowly make it harder to change and account for roughly 90% or more of every model's issues, ranging from 89.9% to 94.9%. Security is worse than the marketing suggests, and not monotonically improving. Claude Sonnet 4's bugs were 93% more likely to be rated BLOCKER, Sonar's highest severity level, than Claude 3.7 Sonnet's—13.71% versus 7.10%. And for Llama 3.2 90B, 70.73% of the vulnerabilities it introduced carried that same BLOCKER rating, the highest share of any model tested. Newer is not automatically safer. (This is Sonar's own research, scored against SonarQube's rule set on Java benchmarks.)
The second is about what happens to a codebase over time when this output accumulates. GitClear analyzed 211 million meaningful changed lines of code authored between January 2020 and December 2024. About two-thirds came from private companies that opted into anonymized data sharing; the rest from large open-source projects, mostly those run by Google, Microsoft, and Meta. Its February 2025 findings describe a codebase quietly eroding. The share of commits containing a duplicated block of five or more lines rose from 1.8% in 2023 to 6.7% in 2024—roughly a fourfold jump in a single year—and copy-pasted lines exceeded moved lines for the first time in the five years GitClear has measured, 12.3% against 9.5% of changed lines. Moved code, GitClear's proxy for developers reshaping and reusing what already exists, sank from 24.8% of changed lines in 2021 to 9.5% in 2024, a 40% drop in the final year alone. Code churn—lines that were committed and pushed, then reverted or substantially revised within two weeks—rose from 3.3% to 5.7% over the same period. The interpretation writes itself: agents are good at generating new code and poor at reusing and reshaping your existing code, so they clone instead of refactor. Duplication is architectural drift in slow motion, and GitClear's report links that duplication to defects, citing a 2023 study of deep-learning projects in which co-changed clones were involved in bugs 57% of the time on average, though the median was 48% and the per-project range ran from 2% to 100%.
Put the two together and the picture is consistent. An AI agent with no model of your system optimizes for the local goal in front of it: make this compile, make this test pass, produce something plausible. It does not optimize for "fit the design," because it cannot see the design. Compiling was never the hard part.
How does messy AI-generated code increase the cost of running coding agents over time?
Architectural drift is easy to wave away as something senior engineers will catch in review. That framing hides where the money goes.
Drift caught late is the most expensive kind. When a violation of your architecture or a reintroduced anti-pattern surfaces in pull request review or, worse, in production, you pay for it in reviewer hours, in rework, and in the back-and-forth of re-prompting an agent that never had the context to get it right the first time. Sonar's own product framing is blunt about the mechanism: linters and reviews "verify code in a later stage after the code has already been created," and "when issues are found only at this stage, reprompting is required to generate the desired results, increasing cost."
Then there is the token bill, which is the part that turns this into a board-level FinOps conversation. In a controlled study of about 540 runs using Claude Code, Sonar found that the cleaner side of every repository pair was measurably cheaper to operate on: 7.2% fewer input tokens consumed and 8.5% fewer output tokens generated, with no meaningful change in whether the task got done (a difference of negative 0.9 percentage points on pass rate). Those are dataset-wide averages over a wide per-task spread where some tasks saved 40% on input tokens, a handful cost slightly more on the clean side, but the direction held for every pair. The explanation is the sentence engineering leaders should tape to the wall: "what drives the cost isn't how much the agent writes, it's how much code the agent has to look at in order to write it." This is why drift compounds. Every messy, duplicated, hard-to-follow change an agent makes today raises the price of every agent run that has to read that code tomorrow. You are not paying once for bad output. You are paying interest on it.
And underneath the cost sits the risk: duplication and churn become tomorrow's maintenance burden, and the security-blindness above becomes tomorrow's incident.
Why do better prompts and code reviews not fix problems caused by AI coding agents?
The two most common responses both fall short, for the same reason: they arrive at the wrong moment.
Prompt files, CLAUDE.md, and rules documents are the first instinct, and they help. But they are static. As Sonar puts it, they "are static and must be maintained as the codebase changes," and in practice they drift out of date the moment your architecture moves. A hand-written instructions file also cannot carry the things that actually prevent drift: your live architecture graph and its intended constraints, the specific rules your history says you break most often, the exact call flow around the function the agent is about to touch. You cannot paste your codebase's structure into a prompt and keep it current by hand.
Verification is the second instinct, and it is necessary, but on its own it only tells you about drift after the agent has already written it. A linter, a CI gate, even AI code review on the pull request all operate downstream of generation. They detect the problem, then trigger the expensive reprompt-and-fix loop. You cannot verify your way out of a context problem. You can only find out about it later.
The missing move is the obvious one once you name it: give the agent your real context and constraints before it writes, so there is less drift to detect in the first place.
Guide is the stage teams skip, and it is first for a reason. It means injecting project-specific context into the agent before code generation, so, in Sonar's words, "the resulting code isn't generic and adheres to your repository's unique standards." Concretely, Sonar Vortex's context augmentation supplies four things a prompt file cannot keep current:
Coding guidelines drawn from your project's own history of issues, filtered to what the agent is about to do, rather than a generic style guide.
Architecture, exposing both the current architecture graph and your user-defined intended constraints, so the agent can "build the right thing" and "build the thing right" and avoid rework.
Semantic navigation that finds the right place to change by meaning, using ASTs and control flow rather than text search, and surfaces "every relevant location that needs updating so nothing is missed."
Third-party dependency guidance that checks a package's health and safety before it is introduced, not after it ships.
With that context in place, the agent writes. Verify then analyzes the result with full CI-level precision inside the agent's loop, before a pull request exists, so issues surface before review rather than after; pull-request review is handled separately by SonarQube and Gitar. Solve closes remaining issues in the loop and at scale.
Verify and Solve are essential, but they are downstream. If Guide is the only stage you skip, you have built a workflow whose entire job is to detect and repair drift you could have prevented, and you pay for that detection in tokens and time on every run. Guide first is not a slogan. It is where the leverage is, because it is the only point in the loop where a mistake can be stopped before it is written and before it starts accruing interest.
What does this mean for platform teams?
The practical shift for engineering leaders is to stop treating codebase context as per-developer prompt hygiene and start treating it as a platform capability. Your architecture, your rules, your dependency policy, and your history should reach every agent, in every IDE, for every developer, automatically, and stay current as the code changes without anyone maintaining a document. That is the difference between hoping each engineer wrote a good CLAUDE.md and governing that every agent starts from the same accurate picture of your system.
Sonar reports that in its own testing with a leading coding agent, Vortex reduced the issues an agent produced by 92%. A separate benchmark of Vortex's semantic navigation across six open-source refactoring tasks found up to 36% lower cost per run on work where locating the code is the bulk of the job with results ranging from that down to roughly flat, depending on the task. Sonar also cites a 3.2% false-positive rate as what makes automated remediation trustworthy. Treat those as vendor figures and prove them on your own repositories, which the tooling lets you do. But the strategic point does not depend on any single number. It depends on the ordering. An agent that starts with your context writes less drift; less drift means less to verify, less to fix, fewer tokens burned, re-reading messy code, and fewer late surprises in review and production.
The bottom line
Your agent is going to keep producing code that compiles. The open question, the one that shows up in your reviewer hours, your token bill, and your incident channel, is whether it produces code that belongs in your system. That is a context problem, and context is not something you can bolt on after the fact with a linter or a stale instructions file. It has to come first: guide the agent before it generates, verify before it merges, and solve what remains. In that order.