Getting Started with Claude Code

Audience

curious developers, beginner to intermediate

Time

15 to 25 min

Module

1/5

Skill goal

run your first real Claude Code session inside a project

In one picture

Think of a senior teammate who slides their chair up to your keyboard: they do not copy code out to a browser and paste it back — they open the project on your machine, read the actual file, and type the fix directly while you watch. Claude Code is that colleague, materialised in your terminal. It sees your real repository, proposes edits with a diff you can read, and only touches disk when you say so. The whole point is to skip the back-and-forth of a browser chat and work where the code actually lives.

How it works

The first session follows a very simple loop. You express intent in plain English, Claude Code reads the files that matter, it proposes a change, you approve or refine, and only then is anything saved.

Underneath, three technical realities matter for a developer:

• The session runs in a shell (or embedded in your IDE), inside a specific working directory — that directory scopes what Claude can see by default.
• Reads are cheap and usually safe. Writes and command executions go through a permission layer (covered in Module 2) so nothing risky happens silently.
• Every change lands as a real diff in your working tree, which means your existing tooling (Git, tests, linters) still works exactly as before.

A minimal first session looks like this:

1. Open a terminal in your project folder (Claude only sees what is under it).
2. Start Claude Code — the chat opens right there, not in a browser tab.
3. Type something concrete: "add a function that validates an email address in utils/validators.py".
4. Watch it locate the right file, propose an edit, and pause before touching anything sensitive.
5. Approve, then run your tests as usual.

Good starter habits: be specific ("fix the bug in login.py where passwords are not hashed" beats "fix my code"), point Claude at one file or folder while you build trust, and ask "why did you make that choice?" when a change surprises you — that single question is the fastest way to learn the codebase and to catch mistakes.

Try it now

1. cd into a real (non-critical) project on your machine and start claude in a terminal.
2. Ask a scoped question first: "read README.md and summarise the project in three bullets" — no writes, safe warm-up.
3. Request a tiny, specific edit: "add a docstring to the top of utils.py explaining the module's purpose".
4. Read the proposed diff carefully — do not approve blindly — then accept it.
5. Run git diff in another shell and check that the change matches what you approved.

Key takeaways

• Claude Code works where your code lives: real files, real terminal, real Git history.
• The default loop is read → propose → approve → save; you stay in charge of every write.
• Specific, small requests get faster and better results than vague, sweeping ones.

Pitfall to avoid

Treating your first session like a giant refactor: opening Claude in a huge repo and asking "rewrite the auth module". Instead, start with one file, one clear goal, one commit. You learn the tool much faster with five small successes than with one blurry mega-task, and you catch the tool's habits (which files it likes to touch, when it hesitates) before they matter.

So what? Claude Code turns "describe what I want" into "a diff I can review" — the fastest way to internalise it is to do one small, real task today, in a real project, with git diff open beside you.