Sonar: Why token optimisation is the next imperative in AI development

Token spend, deconstructed

Most organisations treat token spend as a usage problem, something to be capped with a stern policy and a dashboard. What they routinely miss is that the codebase the agent is working in drives far more of that spend than any quota ever could.

“Larger context windows have a habit of masquerading as progress. In practice, they often mean the code is simply harder for an agent to understand. Bloated, debt-laden code takes more tokens to read, to debug and to change safely and that cost doesn’t just go away, it repeats on every single interaction,” said Sonar, in a press statement.

Token optimisation, then, is not merely a prompting discipline to be handed to whoever writes the cleverest system prompt. It is, at heart, a software quality discipline, and pretending otherwise is how the bills creep up unnoticed,

Technical debt payback

Technical debt has always been the thing that quietly slows engineering teams down. Add agents into the loop and it raises the price of every single action taken against it. Teams can be left facing a duplicated pattern, a confusing abstraction, or a workflow that nobody left on the team can actually follow. These are all forces that drive an agent to load more context before it can do anything useful whatsoever. 

According to Gautam Korlam, principal engineer at Sonar, software engineering teams should treat technical debt as both an engineering and an operating-cost issue.

Sonar’s Korlam: Developers need to think beyond the prompt – the quality of the environment an agent works in increasingly matters as much as the model selected…. a well-structured codebase gives an agent clearer paths through work.

“The priority should be debt that makes the codebase harder for an agent to navigate: overly complex functions, unclear boundaries, duplication, and ambiguous naming. Those issues force agents to load more context, revisit files, and spend more tokens reasoning through a change, in addition to slowing down developers,” explained Korlam. 

He says that the “practical shift” here is to connect backlog priorities to the AI workflows that touch that code most often. He advises software engineers to start with high-churn services and repositories where agents are already generating retries, long review cycles, or costly remediation. The goal is to reduce the structural friction that repeatedly taxes every future agent task.

All well and good, but what does he think the shift toward codebase-driven cost efficiency mean for developers currently relying on AI coding assistants day to day?

“Developers need to think beyond the prompt,” asserts Korlam. “The quality of the environment an agent works in increasingly matters as much as the model selected. A well-structured codebase gives an agent clearer paths through the work: smaller, focused components, understandable control flow, meaningful names, and explicit boundaries. This means agents spend less time trying to work out what’s going on and more time solving the problem they were actually asked to solve. That’s a much better use of both developer time and compute.”

Cleaner codebases

Sonar’s research suggests that codebases with stronger quality characteristics used roughly 7% fewer input tokens and around 8% fewer output tokens. Agents working within those cleaner codebases also re-read files they had already edited about 34% less often. Tidier structure means the agent needs less context and repeats itself less. Quality, in other words, shows up directly on the invoice — which ought to focus a few minds in finance as much as engineering.

Korlam thinks that the important point here is not that the number goes down, but why it goes down. 

“Agents go back to files when they’re uncertain,” he said. “They’re resolving ambiguity, rebuilding context or tracing how one change affects another. Cleaner code gives them fewer reasons to do that because responsibilities are clearer, dependencies are easier to follow and there are fewer competing patterns to reconcile. It reinforces something we’ve believed for a long time: context isn’t just about how many tokens a model can process. It’s about how much useful signal the code gives the model to work with.”

The result is less rediscovery, less backtracking and a lower token burden over the course of a task.

The company says that usage caps and throttling can contain a bill in the short term, but they only ever treat the symptom, not the disease. The durable fix is to improve the code itself and build verification properly into the agentic loop, so that teams aren’t paying once to generate output and then paying again to clean up results they never really trusted in the first place.

As agents get embedded across generation, review, testing, verification and remediation, small inefficiencies stop being small. They compound, at every single stage, quietly and relentlessly.

Directly embedded verification 

The Sonar view is that the key is to make verification a live feedback mechanism for the agent. 

Before generation, give the agent the relevant coding standards, architectural constraints, and security policies. As it edits, run checks on the changed code against quality, security, dependencies, tests, and architectural rules, and return specific findings to the agent in a form it can act on. 

That turns verification into a closed loop: guide the agent, check each change, provide precise feedback, remediate the issue, and verify the fix before the work progresses. 

“Teams should apply the same verification standard across every model and coding assistant, then retain the results in CI as an auditable record before merge. This reduces broad regeneration and gives developers confidence that agents are working within consistent engineering and security boundaries, rather than asking humans to catch every problem after the fact,” said Korlam.

If you’re wondering whether outcome-based pricing for AI development tools is on the horizon (given current gaps in measuring per-change agent cost attribution), then the Sonar team agree that this could indeed be where the industry is heading, but we’re not quite there yet. A single code change can involve multiple models, tools, retries, human review, CI runs, and remediation steps, so attributing every token to one accepted change is not straightforward. 

“The right near-term approach is to use practical outcome metrics rather than waiting for perfect attribution, such as cost per accepted pull request, tokens per accepted change, retry rate, verification pass rate, review burden, time from first draft to merge, and the durability of the code after release. As instrumentation improves, those measures can become more granular. But it’s already clear that teams should judge AI development tools by the secure, maintainable software they help produce versus looking at token volume or generated lines of code alone. It’s about the outcome, not the output,” explained Korlam.

Risky business?

What risks arise when teams swap to cheaper models without evaluating codebase quality, security requirements and context alongside cost? For Korlam, cheaper is not automatically worse. 

“For a simple task, a lower-cost model may be all you need. The trouble starts when teams use it for work it is not suited to – say, a security-sensitive change or a complicated part of the codebase – without giving it enough context or checking the result properly. That can mean more back-and-forth, more cleanup, and problems that only show up later,” he concluded.

The key is to choose the model for the job, not just the price. We know from looking at LLM leaderboards produced by companies like Sonar that models can perform very differently on security, reliability, and code quality, even when they look similar on basic benchmarks. 

The mantra here is straightforward: match the model to the task, give it the context it needs, and ensure verification in place.