An agent adds a new HTTP client inside an older service. Tests pass, but review catches that the company already has a maintained client for the same internal API, so the new code gets replaced. A few weeks later, another run does something similar in a neighbouring package.
Those two runs can look identical in the PR while having completely different causes. One search returned the old implementation, another found the maintained client but barely used it, and another agent may have seen both and still picked the local example because it was easier to adapt.
By the time somebody comments on the diff, you probably already looked past the interesting bit. Retrieval order, tool output and what the agent actually inspected can change the direction of the work before any code exists.
Architecture drift rarely arrives as one spectacularly bad PR either. A service takes on another responsibility, somebody adds a second abstraction, and an exception gets copied often enough that it no longer looks exceptional. The repository still works, but it moved further away from the structure the team meant to maintain.
Sometimes the correct patch is no patch
FixedBench used 200 repository issues where the reported problem had already been fixed and human reviewers had confirmed that production code didn’t need changing. Coding agents still proposed undesirable production changes in 35% to 65% of cases, depending on the model and harness.
Getting the agent to reproduce the issue first reduced some of that, but it also caused agents to stop early on tasks that were only partially fixed. A coding workflow often assumes progress means changing something. Easy enough to notice with a bug that no longer reproduces while being harder to spot in feature work.
“Make webhook delivery more reliable” could refer to retries, idempotency or failure reporting. The codebase can tell you what webhook delivery does now, but it can’t tell you which conversation led to the ticket or which behaviour the requester actually wanted changed.
The repository can teach the wrong lesson
The platform team has a maintained client for an internal service. Newer packages use it and there’s documentation for it yet the agent is changing an older package where none of that is nearby.
Search finds a hand-written HTTP integration instead. It calls the right service, has been running in production for years and is easy to follow, so copying it isn’t an obviously bad decision from inside the run.
Repositories are full of this kind of thing. A deprecated helper can still have hundreds of call sites, a service everyone wants to break apart can contain years of examples showing engineers adding more responsibilities to it, and migration code can sit around long enough that the temporary version becomes the easiest one to find.
Five old examples can also be more relevant to the current file than the implementation the platform team actually wants people to use. Even when search returns the maintained client, local code may still point elsewhere, the documentation may be vague, or the approved client may be awkward enough that engineers avoid it too.
Our view is that once a rule really matters, the answer shouldn’t always be better context. Some failures need to become checks the next run can’t simply overlook.
Not every architecture problem belongs in CI
Some rules are simple enough to enforce.
If the architecture says:
UI → Service → Repository → Database
and a controller imports a repository directly, fail the check. The same approach works for generated files, banned libraries, package boundaries, schemas and approved network clients.
None of this appeared because coding agents arrived. Agents simply make weakly enforced rules more visible because they don’t know that the code beside them is the one example everybody wishes wasn’t there.
We’ve tried broad evaluation questions around this at Orq. “Architecture quality” sounds useful until the evaluator fails and you still don’t know whether it saw duplication, a bad API choice, requirement mismatch or something else. Splitting those checks up has been easier to work with: duplication gets its own question, API usage gets another, and requirement alignment can be checked against the task.
There are still changes where none of that settles the decision. Authentication is an obvious example, and a destructive migration can pass every automated check you have while still deserving somebody’s attention.
Let agents repair the cheap failures
Checkout says Agent HAL generates 18% of pull requests opened across the company. It repairs failing CI, rebases its branch and reviews its own work before another review persona checks the change against the ticket, with human review coming later.
That makes sense for failures nobody really wants to review manually in the first place. A missing import, broken formatting or a unit test failing because one call site was missed already comes with useful feedback, so the agent can act on it.
A security failure is different because repeated retries can start changing the thing that’s supposed to judge the work. If an authentication change fails a security check, the agent edits the implementation, fails again and then starts changing the surrounding verification because that’s what stands between the run and a green build, the retry loop has stopped looking harmless.
Debug the run, not just the diff
A reviewer writes:
Use the existing abstraction.
The PR gets fixed, but nothing in that comment explains why the duplicate appeared.
Search may never have returned the maintained client, an old helper may have ranked higher, or the preferred version may live in another package with no local reference. The agent can also inspect the right client and still decide that its API is awkward for this change.
All of those paths end with the same review comment. With Orq.ai traces, we can go backwards through retrieval order, tool responses, context and where the eventual implementation first started to appear.
Sometimes the cause is obvious and other times the trace mainly reduces the number of explanations still on the table. That’s usually more useful than treating every bad diff as the same kind of failure, because the fix depends on where the run actually went off course.
That can lead to a change in search, documentation or the abstraction itself. In other cases there’s nothing to encode yet because the team is still arguing about what the rule should be.
That feedback loop is one of the things a Software Factory needs to make repeatable. A failed run shouldn’t only produce a fixed PR. When the cause is reusable, it should improve the context, evaluation or control the next run starts with.
A security boundary getting crossed once can justify a hard control, while ten comments about whether a service has too many responsibilities may simply mean the architecture discussion isn’t finished.
Drift appears across changes, not in one pull request
A 2026 longitudinal study of coding-agent adoption reported static-analysis warnings increasing by roughly 18% and cognitive complexity by around 39%. It also found much smaller or shorter-lived additional throughput gains in repositories with prior observable AI-IDE usage.
Those numbers are maintainability signals rather than direct proof of architecture drift, but drift is easier to understand when you stop looking for one PR that caused it.
A helper gets added to one service, another team creates an abstraction that partly overlaps with something elsewhere, and a dependency crosses a boundary because the case seems exceptional enough to justify it. None of those changes looks especially alarming on its own.
Months later, that boundary has several extra edges running through it. Search finds four implementations of something that was supposed to have one owner, and the exception from six months ago is now an example for the next agent.
Architecture tests and dependency graphs can catch parts of this, while static analysis and ordinary code search help with the rest. Coding agents mostly change how quickly these decisions can accumulate: the engineer reviewing five related changes remembers what looked suspicious in the first one, whereas the next agent run starts without that history.
Cleanup has the same problem when the task is vague. “Improve the architecture” leaves too many decisions open while the agent is already changing code. If the team has already decided that three clients should become one and which interfaces need to stay unchanged, that’s a much easier piece of work to hand off.
Preventing agent mistakes gets easier when you can see why a run made a decision, evaluate the result and turn recurring failures into controls the next run inherits. Book a demo to see how Orq.ai supports governed coding-agent workflows.
