How to steer coding agents amid rising token costs

For the past few years, throwing an agent into an iterative loop until it produced useful results was a defensible engineering strategy.

In December 2025, Uber gave its engineers access to AI coding agents. In just four months, the entire annual AI budget was gone. The engineers were just running agents the way the industry had trained them to: prompt, debug, ship, prompt…

This sort of agentic prompt treadmill stops working when 73% of enterprises are now overshooting their AI budgets and finance is starting to watch the invoice line by line.

So how should engineering teams get more out of every agent run? Through two jobs: reading the trace of agent activity, and knowing the organization’s specific business logic well enough to minimize agent prompt loops.

Every major agent observability platform, LangSmith, Langfuse, Braintrust, MLflow, is built around making the agent's execution inspectable. Trace reading gets attention, and rightly, but are we avoiding asking how well the engineer orchestrating AI agents understands the business?

What is an agent trace?

An agent trace is a structured record of the steps an agent took to answer a request: model calls, tool calls, and retrievals, shown in order. Each span can include its inputs, outputs, latency, and, where applicable, token usage. Observability platforms like LangSmith often render these spans as a nested tree, making the agent’s execution path easier to inspect.

For a single LLM call, the trace is one span with a prompt and a completion. Whereas a coding agent can read a file, search for a symbol, write code, run tests, and so on before returning. Each of those steps is a span in the trace, and each span carries the context the agent was working from at that moment.

Every step can also complete successfully while the agent loops on the same tool with slightly different arguments, or drifts away from the task. The problem only becomes clear when you examine the path the agent took, locate the failure, address its cause, and make the next run more accurate and less expensive.

Reading the trace improves the next run

At the Montreal data developer meetup, panelist Mathieu DiMercurio talked about the emergence of two kinds of engineers:

“Some people just throw an agent at a task, let it run in loops, and hope for the best. It’s not doing good work. But someone who can read an agent’s trace, either while it’s executing or after the fact, understand where its thought process went wrong, and rewrite the same request more efficiently will have deep knowledge that is always going to be relevant.”

Letting an agent run unchecked can look productive right up until the token costs get tallied. Engineers who read the trace, however, see which unfamiliar library the agent reached for, which search path it took to find a source, and where its context filled up with junk and pulled accuracy down with it.

Reading a trace is the modern version of long-standing code review best practices. Approving the output is easy. Looking at how the agent arrives at the output is where the best engineering happens.

The agent trace only shows where things went wrong

As important as it is, trace reading is diagnostic. It shows where the agent got lost but rarely answers why, because that answer lives in the request itself.

When a data engineer asks an agent to "pull revenue by segment for last quarter", a coding agent has to make assumptions about the gaps in that sentence. And in any data request at enterprise scale, those gaps can be huge: GAAP or management revenue definition? Which segment taxonomy? What does "last quarter" mean when the fiscal calendar does not line up with the calendar year?

Every assumption an agent makes will lead to wrong turns, when preempting the gaps could have circumvented them. The engineers who steer well stay close to the business. Their knowledge makes a request precise enough that the agent does not have to loop.

High token bills emerge, on the other hand, from reading a data schema and hoping the agent figures out the rest.

Every wrong turn now costs more

Geoffrey Bernard, CMD & CDO at La Presse, and another speaker at the Montreal data developer meetup, framed the stakes:

"The party we’ve been enjoying for the past two and a half years is coming to an end. The average price per token has increased, and compute bills have risen significantly. The idea that we can stay at this all-you-can-eat buffet for a very long time and continue doing lazy engineering is going to become more and more expensive."

Engineers who can explain what an agent did and adjust the next request will keep the work moving without blowing through the budget. Those who cannot will burn through their limits and still end up rewriting the code by hand.

Context length matters for the same reason. The more irrelevant material an agent has to work through, the slower and less reliable it becomes. If a bad assumption enters the context early, the model keeps building on it. Keeping the context focused and giving the agent the right business definitions up front leads to shorter traces and better output.

Good steering starts before the agent runs

Specific tools will keep changing, and AI model costs will keep moving. What will last is the ability to understand what an agent did, spot where it went wrong, and use that knowledge to improve the next run.

This ability requires knowledge of more than merely reading a trace; engineers also need enough business fluency to know whether the agent’s decisions make sense. A trace can show where the agent made an assumption, but business fluency tells you the assumption was wrong.

The earlier those definitions and rules are made clear, the less time the agent spends searching, looping, or correcting itself, resulting in shorter traces, better output, and lower costs.

Engineering’s job is no longer just to review what a coding agent produced, but to steer it in the right direction, understand the path it took, and make the very first run as closely aligned to the organization’s business rules as possible.