What you miss when you skip the setup
I recently walked the developers at work through my Claude Code setup. They all use Claude every day. Most of what I showed them was new. It works so well out of the box that none of them had a reason to dig deeper.
Because it saves so much time, it takes a while to notice how much of that time goes back into correcting its work. I've found most of those corrections trace back to a gap in the setup, which I think of as four parts:
- Settings: what Claude is allowed to do.
- Instructions: what it needs to know, in CLAUDE.md files that nest.
- Capabilities: skills, subagents and tools, including a workflow that takes a ticket to a PR.
- Enforcement: hooks, for what must never happen and for mistakes not worth repeating.
Together they do two jobs, and a setup can do one well and the other badly.
The first is protection. Nothing in a default setup stops Claude from doing things my team would never allow, such as committing to a protected branch or running something against production. A careful developer avoids these out of habit. Claude has no habits unless I give it some.
The second is velocity. Without rules, instructions and hooks, Claude repeats its past failures. One of my hooks blocks a build command that silently breaks our data layer, and names the one to run instead. That message turns a string of retries into a single turn.
This series takes the four parts one at a time. All four are in Anthropic's docs; what the docs don't say is which to set up first. Each post starts from something that happened on a production .NET codebase in the past two years, including the parts I got wrong first.
Here's what skipping the setup looks like:
It asks permission for every git status. Part 2.
Each session it relearns the stack: Vue, a C# backend partly on .NET Framework 4.8, a gateway in front. Part 3.
It copies the nearest example, so an old Options API store becomes the template for new code. Also part 3.
I correct the same mistake twice, and telling it again doesn't stick. A hook does. Part 4.
I type the same ten-step routine every time I pick up a ticket. That's a skill. Also part 4.
It guesses at the ticket, the database or the build output rather than reading them. That's a job for a connector, a CLI or an MCP server. Part 5.
It starts writing code before it understands the problem. Part 6.
A long session degrades as it runs, and a single Claude can only do one thing at a time. Part 7.
It reviews its own work, and approves it. Part 8.
It worked last month and quietly doesn't now. Part 9.
None of this is advanced. Every remedy is a file in a folder: a CLAUDE.md, a rules file, a short script Claude Code runs.
Setting Up Claude, part 1 of 10. Next: What Claude is allowed to do.