More effort is not more care

You asked for five more minutes

You want a snooze button on an alarm screen. It matters, so you turn the agent's effort level to the maximum. It comes back with a scheduling engine, a new settings page and a refactor of your notification code. You asked for five more minutes and got a calendar app. And you paid extra for it.

I see some version of this in almost every team I train. The instinct sounds right: important job, so give it everything. The dial just doesn't do what its label suggests.

What the dial really sets

Effort controls how much the agent does before it answers: how many files it reads, how many tools it calls, how many changes it makes. It doesn't control how closely it follows your sentence.

On a low setting, a snooze button means the alarm screen and the code behind it. On the maximum, the agent reads the whole notifications folder. Everything it reads is something it might improve. And every question you left open is a place where it has to decide for you.

How long is a snooze? Nobody said. Every household has had that argument. At low effort the agent picks a number and moves on. At high effort it goes further, finds more forks, and settles each one alone: seven minutes, a user setting, a repeat limit, a new table in the database. Each choice is defensible. Together they are a change you now have to review line by line, and you asked for none of it.

There is some measurement behind this, which I'll put carefully. Some public benchmark runs have shown higher effort scoring lower on tasks where unrequested changes count against you, even good ones. A reviewer who asked for a snooze button doesn't want to merge a scheduling engine.

When the dial does pay

High effort isn't a mistake. It's the right tool for a different job. When the task is pinned down and the difficulty lies in hidden edge cases, more exploration pays. Think of a nasty bug that only appears when two requests land together, or a migration full of strange old data. The same evaluations show higher effort scoring better on hard, well-defined tasks. The target is fixed, so extra searching can only turn up what you wanted.

So the dial helps once the task is nailed down. Your snooze button never was.

The same trap without any code

You don't need a code editor to hit this. Ask Claude for a thorough report on a vague question, say why customers left last quarter, and you may get twelve pages: market trends, pricing history, a suggested reorganisation. What you needed was three likely reasons and which one to check first. Thorough, applied to an open question, means guessing in more places.

Put the effort into the definition

Before any plan, let the agent write a short design discussion: what it found, which patterns already in your project it intends to copy, and every question it can't answer on its own. Then it asks you those questions one at a time, and you decide.

For the snooze button the whole conversation might be two questions. How long is a snooze? Does it survive a restart? Plus one correction from you: the other alert in the app does it the right way, copy that one. Half a minute of your time, and two decisions that would otherwise have been made without you.

Agents often skip the asking, especially when that instruction is one line buried in a long prompt. The sentence that reliably gets it done:

Work back and forth with me, starting with your open questions and outline, before writing the plan.

Keep it somewhere you can paste it from. Once you've answered, the plan is something you can actually read and sign. I wrote about what that looks like in A plan you can answer.

Why long instruction files backfire

A model follows only a limited number of instructions reliably, and everything in its window draws from that budget: your instruction file, your tools, every skill you've loaded. Pile on rules and the one that matters, ask before you plan, drowns. Short, focused instructions beat a long manual.

Match the process to the task

None of this is for a typo in a button label. If the request fits in a sentence and has one right answer, ask it and take the answer. The design discussion is for work where a wrong guess costs you an afternoon. The rule I use is the shortest path that still gives you something worth reviewing.

What to do this week

Before your next bigger task, paste that sentence. Answer the questions it asks. Only then, if the job is hard and now clearly defined, raise the effort. Notice who made the decisions this time.