Spend Fewer Reasoning Tokens: Why Lower Effort Beats Max Effort for Coding Agents

Most developers can get a better result from their coding agent by dialing the effort level down, not up. In this short clip, Matt Pocock argues that the default instinct to crank effort to maximum wastes reasoning tokens on exploration the agent does not need. Pocock is a TypeScript educator who now teaches AI engineering through AIhero.dev, and he frames this as a practical cost-and-quality tradeoff most people get backwards. The video is a talking-head recording with on-screen text panels labeling the two options: "Lower Effort: Fewer tokens on exploration" and "Higher Effort: More tokens per work done."

What Effort Level Actually Controls

Pocock defines effort in concrete terms. A lower effort level means fewer tokens spent on exploration, so the agent moves through your codebase more efficiently. Exploration, he argues, is not a task that needs much effort in the first place. It is reading and locating, not deep reasoning.

Higher effort does the opposite. As you crank it up, the agent spends more thinking and reasoning tokens to do the same work. The frames reinforce this split with two stacked labels on a dark panel: lower effort tied to fewer exploration tokens, higher effort tied to more tokens per unit of work done. His point is that the extra tokens do not always buy extra value.

The Downside of Pushing Too Hard

The specific failure mode Pocock names is that a high-effort agent "pushes harder on things you don't need to push on." Extra reasoning capacity gets applied to parts of the task that were already simple, so you pay for thinking that changes nothing about the output. The effort is real, but it lands in the wrong places.

This is the core of his contrarian take. More reasoning is not free, and it is not automatically better. It is only better when the task genuinely requires it.

Why Benchmark Charts Mislead You

Pocock's sharpest argument is about the benchmark charts people use to justify max effort. Those charts show that cranking effort to maximum produces higher-quality outputs, which looks like a clear case for always going high. He says the charts hide the crucial detail: the tasks stay static.

In a benchmark, the prompt is fixed and the only variable is the model's effort. In real work, you are not stuck with a fixed task. You are the developer, and you can change how you specify the task. That freedom is exactly what the charts leave out, which is why they push people toward a conclusion that does not hold in practice.

Better Specs Replace Brute-Force Effort

The alternative Pocock offers is to invest in the prompt instead of the effort dial. The more high-quality information you give the agent, the less effort it needs to finish the task. A well-specified task with good context does not require the model to reason its way to what you already know.

His recommendation is to start low and climb only if needed. If you are using Opus or Fable, begin with the lowest effort level you have access to, then crank it up from there. He adds one caveat: you still want a little thinking, because chain of thought is a genuinely useful way to get good results out of agents. The advice is not zero effort, it is minimal effort plus a strong spec.

Key Takeaways

Lower effort means fewer tokens spent on exploration, which makes the agent move through your codebase more efficiently.
Higher effort spends more reasoning tokens and tends to push hard on parts of the task that did not need it.
Benchmark charts favor max effort because they hold the task fixed, which hides the fact that you can rewrite the task instead.
Giving the agent higher-quality information in the spec lowers the effort level it needs to complete the work.
Start at the lowest effort level available (for example on Opus or Fable) and increase only if the output falls short.
Keep some thinking enabled because chain of thought still improves agent output, so aim for minimal effort rather than none.