Installing Claude Code takes a few minutes with the official documentation. But whether a project still works months later depends on what surrounds it: how the repo is organised, how it is saved, and how keys and spending are kept under control. These are the foundations I started with.
Start simple, and keep a repo to learn in
The quickest way to understand what Claude Code does is to try it on something small. A first project should do one thing well, and it should only grow once that first version works and you can explain why it works. Along the way, you will break things and learn from your mistakes.
A learning repo helps with that. It is a throwaway project, kept apart from anything that matters, where you can watch what an action actually does: what a commit records, what changes when Claude is given a permission, how a deleted file still shows up in the history.
The repo structure
A repo is the project folder, tracked by Git so that every change is recorded. Here is a starting point that holds up over months:
my-project/
CLAUDE.md project brain, read at the start of every session
README.md what the project is, for your future self
CHANGELOG.md what changed and when, in plain English
.claude/
settings.json permissions and behaviour, committed
settings.local.json personal permissions, kept out of Git
skills/ written procedures for repeatable tasks
src/ scripts and code
data/ inputs and outputs
docs/ decisions, references, notes
.env keys and secrets, never committed
.gitignore files Git should not trackCLAUDE.md is the file that matters most. Claude Code reads it at the start of every session, so it holds the rules, the context and the constraints of the project. Write it before the first session, as if you were briefing a capable colleague who knows nothing about the project, and update it whenever an important decision changes. Starting without one is the most common mistake: Claude still works, but it starts each session from nothing, guesses at constraints, repeats decisions already made and sometimes undoes earlier work.
CHANGELOG.md answers the question “what happened to this project last week?” without going through individual commits. Asking Claude to update it at the end of each session takes a few seconds.
You can edit any file yourself in an IDE, an editor such as VS Code. When you do, you can tell Claude what you changed so its picture of the project stays accurate, and ask it what the change affects.
Settings and the system prompt
Learning Claude Code’s settings early saves a lot of time. The permissions set what Claude can do without asking you first: which commands it can run, which files it can read, which tools it can call. Auto mode, where a classifier reviews each action instead of asking you, now covers a lot of this. The permissions still live in .claude/settings.json, and knowing that tells you what to change when Claude keeps asking for something it should already have.
The other thing worth understanding is what Claude Code loads at the start of a session. Before you type anything, the model has already received a system prompt with instructions for every feature that is switched on, plus your CLAUDE.md files and the index of its memory, the notes Claude keeps about you and the project from one session to the next. All of it takes up room in the context and shapes the answers.
In my settings, I switched off the features I do not use, which made that system prompt much lighter. I also deleted most of my memory files and asked Claude to use direct language. The context window is cleaner as a result, and the answers stay relevant for longer within a session.
GitHub
As many business functions move towards more technical work with the help of AI, tools such as GitHub become central. GitHub sits outside Claude Code, but the two can work closely together. GitHub keeps a copy of a repo online, so the project survives a lost laptop and can be shared. A few concepts are enough to work with it:
- Commit: a saved step in the history, with a message that says what changed and why. Claude writes these when you ask.
- Push: sends your commits to GitHub. Until you push, the work only exists on your machine, which makes it the habit to build first.
- Pull: brings down changes made elsewhere, from another computer or a colleague.
- Clone: creates a local copy of a repo that already exists on GitHub.
- Private or public: a private repo is visible to you and the people you invite, a public one to anyone. Keep a project private unless you mean to share it.
- History: everything ever committed stays in the history, including a file deleted later.
Several editors show all of this, and VS Code is a good and widely used option. Its Source Control panel lists the files changed since the last commit, shows each change line by line, and lets you commit and push in a click. It is the easiest place to check what Claude has just done before it goes any further.
API keys
Any service you call from a script, whether an AI model or a data source, gives you a key that grants access to your account. A key committed by mistake and removed in the next commit is still in the history, and automated tools scan public repos for exactly that. There are several options to avoid writing keys directly into your code, something that is a huge no-no. One of them is the .env file, which holds your keys on your machine. A .gitignore file lists what Git must never track, and .env belongs in it from the first commit. Ask Claude how to set up both at the start of a project if you are new to these concepts.
Create a dedicated key for each project. Most providers let you create several keys on the same account and name them, so if one leaks, you revoke it without touching anything else.
A virtual card with a spending cap
API usage is billed as you go, so a leaked key or a script stuck in a loop can run up a bill quickly. I pay for each API provider with its own virtual card, a card number my bank generates in seconds and that I can delete at any time. I sometimes set up a separate card for a specific project. Each card has a cap I would accept losing on a test, sometimes as low as €10 or €20. When a charge goes beyond what I expect, I see it straight away.
Tools worth installing
A short list is enough to start:
- VS Code, to see the files Claude creates and modifies, and to follow the history of the repo.
- Python, the language most of my automation scripts are written in.
- uv, which installs Python and the packages a project needs, and keeps each project’s packages separate from the others.
The list is short on purpose, because new tools come out every week and it is tempting to try each one. There are hundreds of concepts to learn, and the ones in this article are only a few examples among many. What matters is to learn and understand them as you go, and a system that works and holds up as it grows matters more than the latest tool. I wrote more about not getting carried away by the hype, and about where to find a first project, in where to start building with AI.