How do organisations decide whether code quality work is worth it for AI agents?

Why This Matters for Security Teams

For AI agents, code quality is not just a software-engineering preference. Poor structure can increase tool calls, duplicate reads, brittle retries, and the chance that an agent follows the wrong path through a repository. That matters because agent behaviour is shaped by what it can reliably parse, modify, and validate. The OWASP Agentic AI Top 10 is useful here because it frames agentic risk as a mix of architecture, tool access, and failure containment, not just model prompt quality.

Security teams often underestimate the cost of weak code quality because the first visible symptom is usually latency or developer annoyance, not an obvious incident. In practice, fragmented codebases can also widen the attack surface for prompt injection into developer workflows, insecure tool chaining, and accidental overreach by agents operating with execution authority. Current guidance suggests treating maintainability as part of operational risk when agents are part of the delivery loop, especially where code changes can trigger downstream deployments or secrets handling. In practice, many security teams encounter agent inefficiency only after repeated runtime waste has already become a production habit, rather than through intentional engineering measurement.

How It Works in Practice

The decision usually comes down to whether refactoring produces measurable runtime savings or risk reduction for a specific agent workflow. A high-friction repository can force an agent to reread files, retry edits, or ask for more context, which increases token usage, execution time, and the chance of partial or incorrect changes. That is why the question should be framed as a control decision: does cleanup reduce repeated cost enough to justify the work, and does it also reduce agent failure modes?

Practitioners generally evaluate three signals together:

• Repeated agent reads of the same modules or long context windows needed to understand basic flows
• Frequent edit-retry loops caused by tangled dependencies, unclear boundaries, or inconsistent naming
• Risk concentration in files that touch credentials, deployment logic, or privileged automation paths

The NIST AI Risk Management Framework is helpful because it encourages organisations to connect AI use to governance, measurement, and monitoring rather than treating model output as self-justifying. For agentic systems, that means measuring runtime cost, output quality, and error recovery together. It also helps to compare the cost of refactoring against the cost avoided per workflow, not against a vague idea of code elegance. Where agent actions interact with repositories that hold secrets, release logic, or infrastructure-as-code, structural cleanup can reduce the blast radius of mistakes by making validation and review more deterministic. These controls tend to break down when the codebase is highly dynamic, because the agent is constantly learning moving targets and the savings from cleanup are erased by rapid churn.

Common Variations and Edge Cases

Tighter code quality often increases short-term engineering effort, requiring organisations to balance immediate refactoring cost against lower agent runtime and safer automation. That tradeoff is especially visible in fast-moving products, where teams may prefer targeted cleanup over broad rewrites.

There is no universal standard for this yet, but current guidance suggests prioritising the parts of the codebase that the agent touches most often and that have the highest security consequence if modified incorrectly. A repository used for documentation generation may not justify the same investment as one that drives build pipelines, access checks, or deployment steps. Similarly, if an agent mainly performs read-only analysis, the return on structural cleanup may be lower than in an environment where it can open pull requests or execute code.

Edge cases appear when the system mixes human and agent contributions, when tests are weak, or when prompt and code changes happen together. In those environments, better code quality can improve agent behaviour, but the real value often comes from clearer interfaces, stronger test coverage, and tighter change approval rather than from style cleanup alone. For deeper threat modelling of agent failure patterns, teams can cross-check against the CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix when the concern is not just efficiency but manipulation, misuse, or agentic abuse.

Related resources from NHI Mgmt Group

• How do organisations decide whether AI governance is strong enough for autonomous agents?
• How can organisations decide whether adaptive AI agents are suitable for critical workflows?
• How can organisations decide whether an SSO design is suitable for AI agents?
• How should organisations decide whether an AI use case is worth deploying?