You upgraded to the newest, strongest reasoning model, and the answer that came back was still flat. Not wrong, just mediocre, the kind of thing you have to rewrite before anyone else sees it. Most people respond by reaching for an even bigger model. That is almost never the fix. When the work is mediocre, the lever is usually how you briefed the model, not the model itself.
Below are four habits that get better work out of any modern reasoning model. I use Claude as my reference, but none of them are tricks tied to one release. They are the difference between an assistant that guesses at what you meant and one that does what you actually needed.
1. Give it the "why", not just the "what"
The fastest way to get a generic answer is to give a generic instruction. Ask for "write me an email to a client about the delay" and you will get a generic email about a delay, because that is all the model has to work with. It fills the gaps with the most average version of the request it can imagine.
A capable model does noticeably better work when it understands your intent: what you are trying to achieve, who the output is for, and how it fits the larger thing you are doing. The context lets it connect your request to the right details instead of guessing at them.
So instead of the bare command, brief it the way you would brief a colleague:
"I'm managing a project for a client who's anxious about timelines. We slipped by a few days because of a supplier issue that's now resolved. I need to tell them about the delay without losing their confidence. With that in mind, help me write the email."
Same task, completely different raw material. The second version gives the model a reason to make specific choices, a reassuring tone and the recovered timeline instead of a template that could belong to anyone. And if your notes and files are set up well, that extra context also points it at the right background to pull from before it writes a word.
I've written more about why context, not the model, is the real differentiator in Everyone has the same model — your context wins.
2. Tell it what not to do
Modern models are eager. Give one a task and it will often do more than you asked: add a feature, rewrite something next to the part you pointed at, send the thing you only wanted drafted. Sometimes that initiative helps. Often it creates work you now have to undo.
The fix is to name the boundaries out loud. Think about how you'd hand a task to a new hire in their first week. You don't only describe the job; you also tell them what to leave alone until you say so, because they don't yet know which parts are load-bearing.
Two boundaries earn their place in almost every brief. The first protects your decisions:
"When I describe a problem or ask a question, your job is the assessment. Report what you find and stop. Don't fix, send, edit, or delete anything until I say go."
The second protects the scope:
"Do the simplest thing that works. Don't add features I didn't ask for."
Naming what to avoid used to feel like wasted words. On today's models it works, because they follow clear direction well enough that a spoken "don't" actually lands. A short list of boundaries at the top of a task saves far more cleanup than it costs you to write.
3. Let it act once it has enough, and match the effort to the task
There's a habit that feels responsible but quietly wastes time: forcing the model to research everything and lay out a full plan before it's allowed to touch anything. For a genuinely hard, high-stakes task, planning first is right. For most work it just bolts a slow step onto the front of a job the model could already start.
A better instruction gives it permission to move: "When you have enough information to act, act." It still gathers what it needs; it just stops stalling for a plan the task doesn't require.
The same right-sizing applies to how hard the model thinks. Claude lets you set an effort level, from low through medium and high up to very high, and the real skill is matching that dial to the job in front of you.
A sensible default is high. Save very high for the genuinely hard, capability-sensitive work, the tasks where a better answer is worth the extra time and cost. Drop to low or medium for routine work that doesn't need deep reasoning. The same logic governs which model you reach for at all: the most powerful and most expensive option should be a rare choice, pulled out only for the hardest problems. Using it for everything is overkill, and you end up paying for reasoning the task never needed.
I've gone deeper on both sides of that decision: how to actually use Claude Opus 4.8 for the top of the range, and cheap executor, expensive advisor — matching the model to the task for deciding where each job belongs.
4. Say less, not more
This one sounds like it contradicts the first habit, so let me be precise. Giving the model the "why" is not the same as burying it in rules. Once your environment is set up well, with the context, the files, and the tools it can reach, a short instruction that leads with the outcome steers just as well as a long list of numbered do's and don'ts.
So instead of "rule one: be concise; rule two: don't over-explain; rule three: ask before making large changes", you can often collapse the whole thing to one line:
"Lead with the outcome, keep it simple, and pause only when the work genuinely needs me."
The trick is where you put it. Standing instructions like that belong in your persistent setup, a memory or instructions file the model reads every time you work, such as a CLAUDE.md. They don't belong pasted onto the end of every single prompt. Define your defaults once, in the environment, and each individual request gets shorter and clearer because of it.
One habit I'm not covering here: make it prove it
There's a fifth habit I rate above all four of these: never take "it's done" at face value. Make the model show you the result that proves the work holds up, and say so plainly when something isn't verified. It matters enough that I've given it its own place, so I won't compress it here. See Don't ask if it's done — make the agent prove it works.
What these habits share
Notice what none of them are about: finding a cleverer model. They're about being a clearer principal. You state the intent, mark the boundaries, right-size the effort, and keep the standing rules in one place where the model always sees them. The model itself is the same one everyone else can open. How you brief it is the part only you control.
Pick the next task where the output disappointed you, and rewrite the brief before you rewrite the answer.