Blog · September 17, 2026 · 12 min read

Using Claude Well: Six Habits

Open dot-grid notebook next to a white keyboard and a pencil on a bright desk
Photo: PNW Production / Pexels

To use Claude effectively you don't need to know more features. You need six habits that stay the same across every task: give the assignment and let it ask you questions, decide up front what may happen without your approval, insist on evidence instead of a claim, have the work checked by someone other than whoever produced it, say each correction exactly once and write it down permanently, and move the work to where your files already live. In my work, those six points separate someone who operates Claude from someone who works with it.

I have used Claude daily since Claude Code came out, and I run my business with an AI workforce whose roles live as folders and files on my own machine. Every habit below comes out of that work, not out of a listicle. The rest of my setup is on the Claude overview page.

What this article deliberately does not cover: prompt templates, a guide to Projects, and memory settings. Those have their own articles, and I link to them exactly where they help. This one is about the behaviour before and after.

Six habits that help you use Claude effectively

Habit How you notice it's missing When the effort falls Matters most for
1. Assign, then let it ask You sharpen the same request three times in a row once per role unfamiliar kinds of work
2. Set the boundaries up front You are startled by something that already happened write it down once anything that changes a state
3. Evidence, not assertion You take the word "done" at face value per result numbers, lists, anything published
4. Whoever made it doesn't check it Mistakes surface outside your house per pass anything that leaves your desk
5. Say each correction once You repeat yourself for weeks per correction recurring work
6. Work where your files are You paste context into a chat window set up once ongoing projects

The order is not a ranking, it is the shape of an assignment. Habits 1 and 2 sit at the start, 3 and 4 at the end, 5 comes after that, and 6 decides where the whole thing happens in the first place.

Habit 1: Give the assignment, then let it ask you questions

The most common beginner mistake is polishing the request instead of allowing questions. I do it the other way round. On 2 September I sent my SEO role, Sebastian, a voice note, translated from German: "could you please do the SEO and GEO analysis for my website?" That was all. Forty-one seconds later came the question "Which website do you mean?", and after that the work ran through to a finished report.

The same pattern shows up mid-task. When my bookkeeping role, Peter, went through 63 receipts, two questions came back before any output: one receipt had a truncated line, and two different currencies appeared, followed by the sentence "I don't invent exchange rates". My answer was half a sentence: "All in euros, daily rate." A question before the result costs seconds. A wrong result costs the whole run.

When I set up a new role, I do this once, thoroughly, as an onboarding conversation: the role asks what it needs to know about the business, and the answers go into its file permanently instead of reappearing in every assignment. How an assignment is built in detail, and why I keep no prompt library, is in Claude Prompts: Templates. This article is only about the habit behind it: let it ask first, then let it work.

Habit 2: Decide up front what may happen without your approval

The moment Claude stops writing text and starts changing files, running commands or publishing things, you need an answer to one question: what is allowed to happen without you? In my model that sits in each role's file in three tiers: free, only after approval, never. Sign-ins and payments I always handle myself; no AI role of mine enters credentials.

What that looks like in practice comes from a session on 6 September. I had given my website role, Ralf, four lines of assignment and typed as the fifth: "put the website live directly, the way we always do it." The reply was "Kevin, approval noted, I'll finish, verify and deploy right after", later "Done and live", and in the same breath "I haven't committed anything yet, let me know". That second sentence is the interesting one: approval existed for the deployment, not for the commit, so the commit waited.

You don't have to invent the mechanics yourself. Claude Code has rules and modes that define exactly what is allowed, what asks first and what stays forbidden; the official documentation covers them under Configure permissions (retrieved 18 September 2026). If you want such rules to be binding rather than repeated, the next step is Claude Code Hooks: Rules That Always Apply.

Habit 3: Insist on evidence, not on the assertion

"Done" is an assertion, not a check. The habit is to ask, for every result, what makes it verifiable: how do you know it is right? With those 63 receipts the answer was a control calculation, net plus tax equals gross, for all 63, plus the dry report "Ran 12 commands (2 failed)". That second number is what makes the first one worth anything.

My content editor role, Conny, mirrored 23 reels onto two new channels in September. The sequence was: one single test post first, then the remaining 22, and every one of them verified afterwards by reading it back from the platform, 23 out of 23. Reading it back compares the result against the platform.

Evidence also means making absences visible. When Ralf could not find anything about one person on a website, he wrote visible placeholders instead of inventing something. That is exactly what I would watch for while training a role. A visible gap you can check. A plausibly filled one you may never notice. Anthropic describes the same stance in its own learning material as one of four behaviours, Discernment, in the free AI Fluency course on Claude Academy (retrieved 18 September 2026; the course I checked is in English).

Habit 4: Whoever produced it does not check it

This is the house rule everything that leaves my desk depends on: the role that wrote something does not review it. Review happens in a second, separate pass, often by a subagent with its own context, sometimes by a different tool altogether. For correction loops I regularly use Codex, simply because it is not the same session.

One clarification so nobody gets the wrong idea: for me this is a role rule, not a technical lock. My reviewing subagents have no restricted tool permissions, they are just another pass with a different assignment. The separation works anyway, and it works visibly: during the editing pass on a batch of blog posts on 7 September, the separate reviewing role corrected factual errors in a good half of the Kubernetes articles and removed unsupported pricing and feature claims from the Claude ones.

Research points the same way. Huang and colleagues showed at ICLR 2024 that language models do not reliably correct their own reasoning errors without external feedback, and that performance sometimes degrades after an attempt at self-correction (Large Language Models Cannot Self-Correct Reasoning Yet). If you want to see what a second pass looks like technically, Claude Subagents, Skills, Agents goes into it.

Habit 5: Say each correction exactly once

The most expensive habit is repeating the same correction every week. In my setup each correction goes into a learnings file belonging to that role, in a fixed shape: the rule, why it applies, how to apply it, and how confident it is. Newest entries sit at the top, and anything later disproved gets struck through rather than deleted, so it stays visible what once applied.

Two examples from my own work. On 5 September I flagged a phrasing that appeared in almost every draft, a clipped two-sentence contrast formula. Since then it sits in the file as a banned construction. On 24 August I gave feedback on a split-screen video; that turned into five mandatory points that appear in every video brief since. Conny's learnings file has grown past 1,300 lines, and that is not dead weight, it is the reason I only had to say most of those things once.

Where exactly a rule belongs depends on the tool, and the differences matter more than they look: what the built-in memory picks up on its own and what you deliberately write into a file are two things I keep strictly apart. I took that apart in Claude Memory: Check It and Use It, and for Claude Code it is in CLAUDE.md: Claude Code's Memory. The habit itself is independent of both: if you catch yourself repeating a correction, that correction does not belong in the chat.

Habit 6: Work where your files already are

The sixth habit changes the most and gets mentioned the least. As long as you work in a chat window, you spend your time pasting context in and copying results out. Once the tool works directly in your folder, both disappear. Two of my roles run regularly in long, continuous sessions rather than in a chain of short chats.

I want to be clear that this is my decision, not a general truth. I have used Claude Projects and they work; what bothers me is that everything lives inside Claude and I cannot move, neither to another tool nor to an open model. That is a control argument, not a quality judgement. If you are staying inside Claude anyway, the Projects route is perfectly fine, and what a clean version of it looks like is in How to Use Claude Projects Right.

People who don't build software tend to end up in the desktop app rather than the terminal. I mostly use the terminal myself, because that is what I am used to. The way in is described in Claude Code: A Guide for Beginners.

Frequently asked questions

How do I use Claude effectively when I am just starting out?

Don't start with all six habits. Start with one recurring task and habit 1: give the assignment, allow the questions. The full path from the first conversation to your own role is in Learn Claude: The Path in Five Stages, and the technical entry point is Claude Guide: Getting Started.

Do these habits apply to other AI tools as well?

Yes, in my experience. None of these six points is about features, they are about how you handle results, which is why they carry over to other tools. They are my habits, not a rule book. I mainly work with Claude, but I also use Codex regularly, among other things for exactly the correction loops from habit 4.

How can I learn to use AI properly without buying a course?

By doing your next real task with it and checking the results, instead of looking for a course first. The habits above cost nothing but attention. I compare the available course options in Claude Courses: What Exists, What's Worth It.

What changes when I want to start using AI agents properly instead of just chatting?

Habits 2 and 3 matter more. An agent can change state: write files, run commands, publish something. It can also just read and plan, but as soon as it is allowed to change anything I give it a clear boundary beforehand and ask for evidence afterwards, whereas with a plain text draft the worst case is a paragraph in the bin.

Which single change pays off fastest?

Habit 5. If you want to get better results from Claude and can only change one thing, write the next correction you find yourself saying for the second time into a fixed place instead of into the chat. It is the habit with the smallest effort and the longest effect.

Do I need the terminal for this?

Not for habits 1 to 5, those work in any interface. Only habit 6 asks that Claude reach your files, and there are two ways to allow that: the terminal or the desktop app with Cowork. I have walked clients through the installation on Windows; people who don't build software tend to stay in the desktop app anyway.

What do I do when Claude makes something up?

Don't argue, tighten the rule. When Ralf could not find anything about one person while building a website, he wrote visible placeholders into the text instead of inventing something. That is how I want it: a gap stays visible as a gap. Habit 3 belongs to it: ask for the evidence before you accept a result.

How to continue

Take a task you were going to do this week anyway and apply two habits to it: let it ask you questions at the start, and write down the first correction in a fixed place at the end. That is enough to begin with, and on the second run you will see whether it made a difference.

If you then want to know where you stand and what comes next, follow the path in Learn Claude: The Path in Five Stages. And when you reach the point where single roles turn into a workforce: the eight ready-made AI employee packages are in my community, together with live calls where exactly those questions get discussed that become specific to your situation. The current terms are on the community page itself.

Kevin Welter

Kevin Welter

Developer, IT architect, author of technical books (Kubernetes, cloud infrastructures) and speaker. Runs his business with an AI workforce of eight AI employees and shows solo business owners in his community how to hire their first AI employee.

More about AI employees

Your first AI employee up and running within an hour

Join the community