Considering how many AI tools and features have launched in the past three years, we've all gotten into the habit of using them all the same way: sending a prompt and hoping for the best. For a lot of AI products, especially conversational chatbots that are meant to generate an answer and nothing more, that's basically fine. The worst case is a reply you don't like, and you try again.

However, for some tools, spending a few minutes configuring settings before you start makes a bigger difference than you'd imagine. That's especially true for coding agents like Claude Code, and as someone who has spent the better part of a year using it (and writing about it), I've settled on a handful of settings I always change first.

I always start with a CLAUDE.md file

The fifteen-minute conversation you only have once

Put coding aside for a bit. When you begin a project with a new teammate in real life, you sit them down and walk them through what you're building instead of throwing them at the work and hoping they figure it out as they go. You explain the quirks of the project, what to do and what not to do, what you're working towards, etc. It's a short, fifteen-minute conversation that saves you from a hundred small misunderstandings later. Claude Code, and basically any other AI tool, is no different. If you drop it into a fresh project and give it no context, it'll just make guesses (likely educated guesses if you're starting with some code), but guesses all the same.

A CLAUDE.md file is how you skip that entirely. It's a plain and simple markdown file you drop into your project's root directory, and Claude Code reads it at the start of every session before it does anything else. You write down exactly what it needs to know once, like the tech stack you're using, your folder structure, the conventions you've already settled on, the things you don't want it touching, etc. Claude Code then carries that context into every prompt from then on, and saves you the hassle of correcting it every few messages or starting from scratch every session.

At the start of a project, you can simply run the /init command inside your project's directory, and Claude Code will scan everything, figure out your stack, and generate a starter CLAUDE.md for you. The version it generates won't be perfect and obviously won't be mapped to your preferences, but it's often a good starting point. Whenever Claude Code makes a mistake I wouldn't want it to repeat next time, I also make sure to open the file and add a quick line about it.

Set up permissions before the first prompt

Stop hitting Enter on the same prompts a hundred times a day

If you've used Claude Code for a project, you've likely spent a good amount of time hitting the Enter key to grant Claude Code permission to do something basic. By default, the tool stops and asks you every time it wants to run a bash command, make a file edit, search the web, etc. The intent is to keep you in the loop, but in practice, what actually happens is one of two things. Either you spend half the session clicking "yes" on the same npm install and git status prompts you'd approve a hundred times in a row, or you get fed up, flip on --dangerously-skip-permissions, and hand Claude the keys to your entire machine.

Fortunately, there's a middle path, which is configuring permissions upfront. Claude Code runs on a system of allow, ask, and deny rules that live in a separate .claude/settings.json file. You can manage them through the /permissions command inside Claude Code, or edit the JSON directly if you prefer. So, before I begin a project, I always take a few minutes out to configure the permissions depending on the type of project I'm working on.

Always start in plan mode

Look before you let it leap

Before I let Claude write a single line of code in a new project, I flip it into plan mode. It's one of Claude Code's permission modes, and you can toggle into it (and out of it) by hitting Shift+Tab inside the terminal. In plan mode, Claude can read your files and run read-only shell commands to look around, but it can't edit your code. This is the single best habit I've picked up for starting a project on the right foot, and it's saved me from more bad ideas than I'd like to admit.

Once I've reviewed the plan and I'm happy with it, I Shift+Tab back into a different mode depending on what I'm doing. The default mode is what most people are familiar with, where Claude prompts you the first time it wants to use each tool and then remembers your answer. If I'm deep into a long task and I know I'll be approving every edit anyway, I'll bump it up to acceptEdits, which auto-accepts file edits and common filesystem commands (mkdir, touch, mv, cp) inside my working directory.

There are two other modes worth knowing about, though I use them less. auto mode is a newer one, currently labeled a research preview, that auto-approves tool calls after running background safety checks to verify the actions actually match what you asked for. Then there's bypassPermissions, which, like the name suggests, runs everything without asking you. Anthropic itself recommends running this within isolated containers and VMs only. I don't personally use it on anything that lives on my main machine, and I'd recommend the same. While these aren't settings you configure once, I did want to mention them as part of my pre-project setup because picking the right starting mode shapes the whole session.

I pick the model based on what I'm doing

The right model is whichever one fits the task

Claude Code lets you pick between three models: Opus, Sonnet, and Haiku. Most people set this once during setup and never think about it again. That's fine, but it leaves a lot on the table: you're paying Sonnet time for things Haiku could finish in half the time, and you're missing out on Opus-level reasoning on the projects that actually need it.

Before I start a project, I just take a second to decide which one fits. Technical work that involves reasoning or anything I expect to debug a lot gets Opus, simple scripts and reorganization tasks get Haiku, and everything in between stays on Sonnet. The clever option, and the one I use most often, is opusplan. Run /model opusplan and Claude Code will use Opus during plan mode (when you actually need the deep thinking) and automatically switch to Sonnet once you start implementing it.

There's also a /effort command that sets the effort level for the whole session, which controls how much "thinking budget" Claude gets before responding. I leave it on the default for most work and bump it up to high or max when I'm tackling something I know is going to need real reasoning!

These are the settings I'd never skip

One of the reasons why Claude Code is a great tool is because of how customizable it is. While I could keep writing about all the little settings and tweaks I've picked up over time, the four above are the ones I'd genuinely never skip on a new project. They take five minutes to set up and pay off every session after, which is about the best return you'll get from any settings menu.