The most expensive way to use AI coding tools is the one that looks fastest: you type one sentence, the model starts building right away, and a moment later you get something that's "almost" what you asked for. Then the revisions begin — round two, three, four — and suddenly a seemingly cheap request eats more time and more tokens than if you'd forced the model to think from the start. I'll show you a process that flips this around: five stages worth walking every larger task through, plus a ready-made way to make the model hold to them on its own.
Why a single prompt fails on a hard task
Two terms first, because the whole piece revolves around them. Claude Code is a tool where Claude works on engineering and operational tasks — it runs in the terminal (a window where you type commands instead of clicking buttons), reads files and executes steps. A token is a fragment of text the model operates on — roughly a chunk of a word; you pay for tokens, and they're the unit a session's usage is measured in.
The default behavior of a tool like this is simple: you ask it to build something, and it starts building. For a trifle, that's fine. For a task that's even a little complex — a report, an automation, a small system — it ends in a familiar friction. The model delivers something that looks sensible at first glance, and you look at it and think: "that's not what I meant at all." Then the rounds of revisions begin, and each one costs more tokens and another exasperated moment.
The core of the problem is that the model guessed what you wanted instead of establishing it. It didn't ask about the gaps in your request, didn't show how it understood the task, didn't break it into parts. It just set off. In my view, that's the most common and most expensive mistake in working with agentic tools (the kind that carry out tasks step by step on their own) — and it doesn't stem from the model being weak. It stems from your letting it skip a stage no experienced contractor would skip.
The five stages of a good contractor
Think of the difference between two contractors you hand the same job. One takes your request and starts building right away. The other does proper reconnaissance first: asks questions, sketches a plan, agrees it with you, and only then reaches for the tools. The first is sometimes faster off the line and slower at the finish, because half the work has to be redone. The second works methodically and finishes once.
The discipline worth enforcing on Claude Code is exactly that second mode, broken into five stages:
- Ask. Before anything gets built, the model asks you a few specific questions to pull out of your head what you didn't write down explicitly. A well-run stage isn't one question but several — aimed at the spots where your request had gaps.
- Design. The model proposes how it wants to do it — sometimes several options with the pros and cons of each. This is the moment you see the direction before it sets into code.
- Plan. A detailed plan is produced: the task broken into small steps, each doable in a few minutes, with a precise note of where and what will change. The plan is saved, so you can come back to it.
- Code. Only now does the model build — step by step, following the plan, stopping at once when it hits an obstacle instead of guessing and plowing on.
- Check. At the end comes verification: the model checks whether what it produced actually does what it was meant to do, before it declares the task finished.
The whole value of this order lies in one thing: most expensive mistakes are made at the start but only surface at the end. If the model misunderstood the task in the first minute, you'll only find out after an hour of work — and only then will you start paying for the revisions. The "ask" and "design" stages move that moment of truth to the very beginning, when a correction is cheap.
The "ask" and "design" stages make the biggest difference
The first two stages are the easiest to dismiss, because they look as though they only delay the "real" work. In practice they're what decides the result.
Let me start with asking. Done well, it isn't a single vague "what exactly do you mean?" It's a few pointed questions that draw out of your head the picture you carry in your imagination but never wrote down. You yourself then notice things you wouldn't have captured in the original request. It isn't wasted time — it's moving the misunderstanding from the end of the process to its start.
The design stage goes a step further. Instead of describing the plan in words, the model can show it to you in the browser: several solution options side by side, with the pros and cons of each, sometimes even with a rough look at what's to be built. You pick the option that best matches what you had in mind — and if none lands, you say so now. That's the difference between "no, that's not what I meant" spoken before the build and the same sentence spoken after it, when a correction means redoing everything. Note that this mode is a conversation by nature: the model asks, you answer, it shows, you correct. That's good as long as you're at the keyboard — it requires your presence in the loop and isn't suited to being run unsupervised.
A ready-made way to make the model hold to the process on its own
This discipline can be built into Claude Code permanently. A free, open add-on called Superpowers does the job — a set of "skills" (ready-made instructions for how to proceed) that make the model walk through the stages described above on a complex task, instead of diving straight into code.
It works thanks to one overarching skill that runs at the start of every conversation and acts as a dispatcher. First it surveys the available skills — there are a dozen or so — and decides which to use for your task. Some concern the design phase (brainstorming, a rough preview in the browser), some the execution phase (walking the plan step by step with safety stops, splitting independent parts across separate sub-agents), and some quality control (writing tests before code, an orderly hunt for the cause of a bug, verification before closing the task). The most important thing in practice is that you don't have to know or remember these skills — you install the add-on once and it works in the background. If you want to be sure, you can add one sentence at the end of a request: "use the appropriate skills if they fit here."
One installation detail is worth knowing. An add-on like this is best enabled globally, at the user level, rather than separately in each project — then you don't have to remember to add it every time; it's simply present in every Claude Code session.
The myth of the expensive process
The most common worry runs: since the model takes so many extra steps, it must burn far more tokens. It sounds logical, but it misses where the tokens really leak away.
It's worth looking at this soberly. On genuinely simple tasks, the process does use more tokens — all that asking is needless there, because the request is unambiguous anyway. But on medium and complex tasks it's usually the reverse: runs with the process can come out cheaper than a one-shot prompt, despite the extra steps at the start. The point isn't a specific percentage — single measurements mean little — but the mechanism behind it.
The mechanism, though, is clear, and it's the lesson here, not any specific percentage. The value of the process doesn't come from the extra steps but from what those steps prevent: expensive repeats and backtracking. The tokens you "save" by skipping the questions, you later spend with interest on four rounds of revisions. The second, less obvious gain is predictability — runs without the process can be far less predictable, and their token use can swing widely, whereas the process keeps it tighter. Code quality also came out noticeably better where there was a process: correctness, structure, error handling. Worth noting honestly, the process doesn't fix what the model simply doesn't know about your domain — subject-matter knowledge stays on the model's side and yours.
What it comes down to
The simplest takeaway is this: for genuinely simple tasks, skip the process — a few percent of overhead gains you nothing and only slows down an obvious request. The whole benefit shows up on complex tasks, and it grows with their complexity.
The lasting principle, though, is broader than any add-on. With AI coding tools it pays to work the way a good contractor does: first establish exactly what's to be built, show the direction, break the thing into steps, and only then build and check the result. An add-on like Superpowers merely builds that discipline in permanently, so you don't have to police it by hand on every request. Next time you hand the model something more serious, try one thing before you hit enter: add that it should first ask you questions and show you a plan before it builds anything. That one sentence often saves a whole round of revisions.