Start with the code paths agents touch most often. Smaller functions, clearer naming, and reduced nesting lower the amount of context the model must reconstruct, which cuts token burn and rework. Then measure input tokens, output tokens, and file revisits per task so you can prove whether refactoring is reducing runtime cost without harming delivery.
Why This Matters for Security Teams
AI coding agents can accelerate delivery, but they also create a new cost model that is easy to misunderstand. Token spend is only part of it. Poorly structured code forces the agent to re-read files, reconstruct intent, and retry edits, which increases runtime cost and can introduce brittle changes. Governance also matters: teams using autonomous coding workflows need guardrails around tool access, review thresholds, and output validation, consistent with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10.
The practical mistake is treating cost as a procurement problem rather than a software design and operating model problem. If the agent repeatedly touches the same sprawling modules, delivery slows even when the model is fast, because the system has to spend more context to achieve the same outcome. In practice, many security and engineering teams discover the cost problem only after agent retries, code review churn, and unplanned refactoring have already increased release friction.
How It Works in Practice
The most effective approach is to reduce the amount of code the agent must reason over for each task, then measure whether that change improves both cost and throughput. Start by identifying the highest-frequency paths where agents make edits. These are usually utility functions, service wrappers, test fixtures, and integration glue. Refactor for local readability: smaller functions, clearer names, fewer nested branches, and narrower file scope. That does not mean rewriting everything. It means making the agent’s working set smaller and more deterministic.
Teams should pair code shape changes with operational telemetry. Track input tokens, output tokens, file revisits, retry counts, and human override rates by task type. That gives a clearer view of whether a refactor is lowering runtime cost or simply moving work elsewhere. It also helps separate model inefficiency from repository complexity. For AI governance, this fits the control logic of the NIST AI Risk Management Framework, because the organisation is managing measurable AI impact rather than assuming the workflow is efficient.
- Target the files agents edit most often before broad architectural changes.
- Prefer small, composable functions that expose intent without extra context.
- Use branch-level metrics to compare cost per completed task, not just token totals.
- Require human review for higher-risk changes, especially where tool use or secrets handling is involved.
- Validate outputs with tests and linting so the agent does not compensate for ambiguity through repeated edits.
When agents have broad write access across large monolithic repositories, these controls tend to break down because every small change requires large-context reconstruction and repeated cross-file edits.
Common Variations and Edge Cases
Tighter code structure often increases short-term engineering effort, requiring teams to balance delivery speed gains against refactoring overhead. That tradeoff is real, especially in legacy systems where breaking up modules may temporarily slow work before the benefits appear. Best practice is evolving, but current guidance suggests limiting optimisation work to the parts of the codebase where agent activity is frequent and repeatable, rather than refactoring everything at once.
There are also situations where cost reduction is not mainly a code-structure problem. If the agent is making tool calls across poorly documented dependencies, the bottleneck may be repository hygiene, not function size. If prompts are vague, the model may still over-explain or revisit files even in a clean codebase. In those cases, prompt templates, task scoping, and approval rules can matter as much as refactoring. The Anthropic report on AI-orchestrated cyber activity is a reminder that autonomy without boundaries increases both operational and security risk, so delivery teams should pair cost optimisation with access controls and auditability.
For regulated or high-risk environments, align the workflow with agent-specific security guidance such as the CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix so cost reduction does not weaken oversight.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack surface, NIST AI RMF and NIST AI 600-1 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Manages measurable AI risk, governance, and monitoring for coding agents. | |
| OWASP Agentic AI Top 10 | Addresses agent autonomy, tool use, and prompt-driven failure modes. | |
| MITRE ATLAS | Useful for mapping adversarial AI abuse of coding agents and tooling. | |
| NIST AI 600-1 | Profiles GenAI operational risks relevant to coding-agent deployment. | |
| EU AI Act | Relevant where coding agents are used in regulated AI systems and workflows. |
Document risk, oversight, and accountability for AI-assisted development processes.
Related resources from NHI Mgmt Group
- How do security teams reduce AI agent data leakage without slowing work?
- How can teams reduce software supply chain risk without slowing delivery?
- How should security teams control AI-assisted coding without slowing developers down?
- How should teams govern AI-assisted internal app building without slowing delivery?