What Claude Code Can Do
An AI helper that works inside your software project: it reads your files, explains how things fit together, makes changes, runs checks, and reports back. Learn what it can do, how it works, how to stay in control, and where it needs your judgment.
Imagine you have joined a company and been handed a huge folder of software. Thousands of files. Nobody has time to walk you through it. You have a bug to fix, a feature to add, and a deadline. Where do you even begin? Now imagine a patient colleague sitting beside you who can read the whole folder in minutes, explain how it is organized, point to the exact place where the bug lives, suggest a fix, make the change, run the checks, and tell you exactly what was done. That colleague does not replace you. You still decide what is right. But the first hour of confusion becomes five minutes.
That is the idea behind Claude Code. It is a tool from Anthropic that brings the Claude assistant into the place where software is made: your project folder, your terminal, and your code editor. Instead of copying code into a chat window and pasting answers back, you let the assistant look at the project directly, work step by step, and show its work.
This guide assumes you know nothing about it. Every new word is explained when it first appears, and each big idea has an everyday comparison. You do not need to be an expert programmer to follow the ideas, although the tool is most useful if you work with software. We look at what Claude Code is, the kinds of jobs it can do, how it works inside, how it keeps you in control through permissions, how to give it good instructions, how to connect it to other tools, how to check its work, and how to avoid common mistakes. There are no code samples in this guide, only ideas and plain words.
One honest note. Claude Code changes quickly. New features arrive, names change, and details differ between the terminal version, the editor extensions, the desktop and web versions, and the plans. This guide teaches the ideas that stay true. For the current list of features, commands, and settings, always check the official Claude Code documentation.
TThe Big Picture: What Is Claude Code?
An assistant that works inside your project, not outside it.
Claude is an AI assistant made by a company called Anthropic. It is built on a large language model, a program trained on huge amounts of text, including a great deal of programming material, so that it can read and write both human language and computer code. In an ordinary chat, you talk to Claude in a window, and anything it knows about your project is whatever you paste in.
Claude Code is different in one important way: it is an agent. An agent is a program that does not only answer, but also takes steps toward a goal. It can look at files, search through them, decide what to do next, make changes, run commands, read the results, and try again. You describe the goal in plain words, such as “find out why the login page is slow” or “add a search box to the products page”, and it works toward it while keeping you informed.
Read and explain
Explore a project and explain how its parts connect, in plain language.
Write and change
Create new files, edit existing ones, and make changes across many places at once.
Run and test
Run commands and tests, read the results, and fix what fails.
Work with other tools
Use version control and, through connections, other services you allow.
A chat assistant is like a friend you phone for advice: you describe the problem, they imagine the room, and they guess. Claude Code is like that friend walking into the room. They can see the pipes, open the cupboard, tighten the bolt, and turn the tap to check. Same knowledge, far more useful because they can look and act.
Think of Claude Code as a capable junior colleague who works quickly and tirelessly, and who needs clear instructions and a reviewer. That picture will guide almost every good habit in this guide.
WWhy It Exists: The Problem It Solves
Software work is full of time spent on things that are not the real thinking.
Anyone who builds software knows the feeling. A large part of the day goes into searching, reading, and repeating: finding where something is defined, working out what a confusing section does, making the same small change in twenty places, writing routine tests, tidying up. These tasks need care but not much creativity. They crowd out the work that does need a human: deciding what to build, weighing trade-offs, and understanding the people who will use the product.
Copy and paste friction
In a chat window, you must copy code in and copy answers out, and the assistant never sees the whole picture.
Missing context
A fix suggested without seeing the rest of the project may break something elsewhere.
Repetitive chores
Many tasks are boring and mechanical, which makes them easy to get wrong when done by hand.
Slow onboarding
Learning an unfamiliar project can take days or weeks without a guide.
Gap between idea and result
Turning a clear idea into working, tested changes takes many small steps that can be delegated.
A chef spends years learning to create dishes, yet a restaurant day is full of chopping, washing, and measuring. A good kitchen assistant takes on much of the chopping so the chef can think about flavor. Claude Code takes on much of the chopping in software work.
CCore Concepts: The Words You Need
Eighteen short definitions that make everything else easy.
Codebase
The whole collection of files that make up a piece of software.
Repository
A project folder whose history of changes is tracked, usually with a tool called Git.
Terminal
A text window where you type commands to the computer instead of clicking.
Command
A typed instruction to the computer, such as “list the files” or “run the tests”.
IDE or code editor
A program for writing code, with helpful features such as highlighting and search.
Agent
A program that takes steps toward a goal, using tools, and not only answering questions.
Tool
An ability the agent can use, such as reading a file, searching, editing, or running a command.
Context
Everything the model can see at one time: your messages, files it read, and results of commands.
Permission
A rule that decides whether the tool may take a certain action, or must ask you first.
Test
A small automatic check that confirms a piece of software behaves as expected.
Bug
A mistake in software that makes it behave wrongly.
Refactoring
Reorganizing code to make it clearer or easier to maintain without changing what it does.
Commit and branch
A commit is a saved snapshot of changes. A branch is a separate line of work that does not disturb the main one.
Pull request
A proposal to merge a branch’s changes into the main project, which others can review.
Project instructions file
A notes file in the project that tells the assistant your conventions, such as how to run tests.
Connector or MCP server
A standard way of linking the assistant to outside tools and data, when you choose to add one.
Hook
A rule that automatically runs something at a set moment, for example a check after each edit.
Subagent
A helper agent that takes on a side task separately, so the main conversation stays focused.
Think of a workshop. The codebase is the whole workshop. A repository is the workshop with a logbook of every change. The terminal is the workbench where you give spoken orders. The agent is the apprentice. Tools are the apprentice’s saws and hammers, and permissions are the rules about which tools they may pick up without asking.
WWhere You Can Use It
The same assistant, available in several places.
Claude Code started in the terminal, the text window where many developers work. Over time it has also become available in other places, which suit different habits. The exact list changes, so check the official documentation for what exists today, but the general picture is as follows.
| Where | What it feels like | Good for |
|---|---|---|
| Terminal | Type requests in a text window and watch it work | Developers who like the command line and want full flexibility |
| Code editor extensions | Works beside your files, showing proposed changes in the editor | People who prefer to stay inside their editor and see changes next to the code |
| Desktop and web apps | A graphical window for sessions, sometimes running in a cloud workspace | Starting tasks that run while you do something else, and reviewing results later |
| Automation and scripting | Runs without a person typing, started by other programs or schedules | Repeated jobs such as reviews and routine maintenance |
| Team platforms | Triggered from tools such as code review or chat, where such links are provided | Small tasks requested by colleagues in their normal workflow |
A plumber can be reached by phone, by visiting the shop, or through a service booking page. It is the same plumber with the same skills, and you pick the door that suits you. Claude Code works the same way across its entrances.
Some entrances run on your own computer, and others run in a separate cloud workspace. That difference affects which files it can reach and what is stored where, so read the documentation for the one you use.
LThe Main Things It Can Do: A Map
Ten kinds of jobs, from reading to releasing.
flowchart TD
CC["Claude Code"] --> U["Understand: explore and explain a project"]
CC --> W["Write: create features and files"]
CC --> F["Fix: find and repair bugs"]
CC --> T["Test: write and run checks"]
CC --> R["Refactor: tidy and restructure"]
CC --> D["Document: explain in plain words"]
CC --> G["Version control: commits, branches, reviews"]
CC --> A["Automate: repeated chores"]
CC --> I["Integrate: connect to other tools"]
CC --> L["Learn: guide a newcomer through the code"]
Understand a project
Summarize how a project is organized and where each feature lives.
Build features
Turn a description into planned and implemented changes across several files.
Fix bugs
Trace an error message to its cause and propose a repair.
Write and run tests
Add checks for existing behavior and run them to see what breaks.
Refactor
Rename, reorganize, and simplify code safely with checks along the way.
Document
Write readable explanations, guides, and notes for the project.
Manage changes
Prepare commits, describe changes, and help with branches and reviews.
Automate chores
Handle repeated tasks, such as updating files in bulk or running routine checks.
Connect tools
Use outside services you have linked, such as issue trackers or databases, within your permissions.
Teach
Explain unfamiliar code, concepts, and decisions to learners and new team members.
A skilled all-round builder can survey a house, draw a plan, fix a leak, add a shelf, check that everything is level, and leave a note for the owner about what was done. The map above lists the same range of jobs, for software.
ECapability 1: Explaining and Exploring a Codebase
Often the most valuable first use: understanding before changing.
Imagine opening a project you have never seen. Claude Code can search through the files, read the important ones, and give you an explanation in plain language: what the project does, how it is organized, which folders hold what, how a request travels from the user’s click to the database, and where a particular feature is handled. Because it can read many files quickly, it can answer questions that would take a person hours of searching.
“What does this project do?”
A short overview of the purpose, the main parts, and how they are organized.
“Where is login handled?”
It finds the relevant files and explains how they work together.
“What would break if I change this?”
It searches for places that use the thing you plan to change.
“Explain this like I am new.”
It rewrites a confusing section in simpler words with an everyday comparison.
A new team member’s first day
Instead of reading folders at random, the newcomer asks for a tour: the main parts, how data flows, and where tests live. After twenty minutes they can ask sensible questions to colleagues, and not just “where do I start?”.
A museum guide does not read every label aloud. They tell you the story, show you the highlights, and answer your questions. Claude Code is a guide for the museum of your codebase.
An explanation can sound sure and still be wrong about a detail. For anything important, ask it to point to the exact file and section it relied on, then read that part yourself.
BCapability 2: Building Features and Making Changes
From a plain-words request to working changes across several files.
You can describe a feature in ordinary language, such as “let users export their orders as a spreadsheet”, and Claude Code can plan the work, find the places that need changes, write the new pieces, edit the existing ones, and connect them. Because it sees the project as a whole, it can follow the style and conventions already used, rather than inventing its own.
You describe the goal
State what you want, who it is for, and any limits, such as “do not change the database”.
It explores
It reads related files to learn how similar things are already done.
It proposes a plan
It lists the steps and the files involved. You can adjust the plan before anything changes.
It makes the changes
It creates and edits files, usually showing each change for your approval, depending on your settings.
It checks the result
It runs tests or the program itself, reads the output, and fixes problems it finds.
You review
You read the changes, try the feature, and accept, adjust, or reject them.
It is like asking a carpenter to add a bookshelf to a room. They measure the wall, look at the other furniture to match the style, show you a sketch, build it, check it is level, and then you decide whether you like it. Each stage has a chance for you to speak up.
For bigger features, ask for a plan first and read it before allowing changes. Fixing a wrong plan costs a minute. Fixing wrong code spread across twenty files costs an afternoon.
DCapability 3: Finding and Fixing Bugs
From an error message to a cause and a repair.
When software breaks, it often shows an error message: a few lines saying what failed and where. To a beginner, these messages can look like another language. Claude Code can read the message, search the project to find the code involved, work out why it failed, suggest a repair, and check that the repair works by running the program or its tests again.
flowchart TD
A["You report the problem or paste the error message"] --> B["Claude Code reads the message"]
B --> C["Searches the project for the related code"]
C --> D["Forms a theory about the cause"]
D --> E["Checks the theory by reading code or running a command"]
E --> F{"Theory confirmed?"}
F -->|"No"| D
F -->|"Yes"| G["Proposes and makes a fix"]
G --> H["Runs tests or the program"]
H --> I{"Fixed with nothing else broken?"}
I -->|"No"| D
I -->|"Yes"| J["Reports what it found and changed"]
Reading error messages
Translates technical messages into plain language and points to the cause.
Reproducing a problem
Finds steps that make the bug appear reliably, which is half the repair.
Searching for similar mistakes
Checks whether the same mistake appears in other places in the project.
Adding a protecting test
Writes a check that fails when the bug is present, so it cannot silently return.
A doctor listens to your symptoms, forms a guess, orders a test to confirm it, treats the cause, and checks that you have recovered. The loop is the same in debugging: symptom, theory, test, treatment, check. Claude Code can walk through the loop quickly, while you stay as the one who understands the patient.
TCapability 4: Tests, Reviews, and Quality Checks
Because quick changes need quick checking.
A test is a small automatic check. For example, a test might confirm that adding two items to a basket gives the right total. Projects with good tests are far safer to change, because the tests shout when something breaks. Writing tests is useful but repetitive, and Claude Code can help create them, run them, and explain failures.
| Quality job | What Claude Code can do | What you still do |
|---|---|---|
| Write tests | Draft tests for existing behavior and edge cases | Check that the tests check the right thing |
| Run tests | Run them, read the output, and summarize failures | Decide whether a failure is a bug or an outdated test |
| Review changes | Read a set of changes and point out likely problems, unclear parts, or missing checks | Make the final call, as the reviewer is not infallible |
| Spot style problems | Follow the project’s formatting and naming habits | Set the rules for the project |
| Look for risky patterns | Flag common mistakes, such as unsafe handling of input | Get specialist review for sensitive systems |
Think of smoke detectors in a house. They do not stop fires, but they tell you quickly when something is wrong, so you can act before it spreads. Tests are the smoke detectors of a software project.
An assistant under pressure to “make the tests pass” may edit the test instead of fixing the problem. Read what changed in the tests, and be sure that it changed for a good reason.
RCapability 5: Refactoring and Modernizing
Making code clearer without changing what it does.
Refactoring means reorganizing code so that it is easier to read and maintain, without changing its behavior. Examples include giving things clearer names, splitting a very long section into smaller parts, removing repeated code, and updating old patterns to newer ones. These are broad, repetitive changes across many files, which is exactly the kind of work an agent can do tirelessly. They are also risky, because a small slip can change behavior, so good tests make them far safer.
Make sure tests exist
Before reorganizing, confirm that tests cover the behavior you want to preserve, or ask Claude Code to add some first.
Work on a branch
Use a separate line of work so the main project stays untouched.
Change in small steps
Ask for one kind of change at a time and run the tests after each.
Review the whole set
Look through the combined changes before merging them.
Tidying a workshop changes where things sit, not what you can build. You keep the tools, relabel the drawers, and throw away the broken ones. After tidying, you check that you can still find the hammer in the dark.
VCapability 6: Version Control, Commits, and Reviews
Keeping a clean history of what changed and why.
Most projects use a tool called Git to keep a history of every change. Each saved snapshot is a commit, each separate line of work is a branch, and each proposal to bring a branch into the main project is a pull request. Using these tools well takes practice, and the commands can be confusing. Claude Code can help with the routine parts: looking at what has changed, writing a clear description of the changes, creating commits, switching branches, and drafting a pull request description for reviewers.
Summarize changes
Describe in plain words what changed across many files, which is useful for reviewers.
Write commit messages
Draft clear messages that explain why a change was made, following your team’s style.
Branch work
Create and switch branches so experiments stay separate from the main project.
Untangle history
Explain how a file changed over time, and who or what introduced a problem.
Prepare reviews
Draft a pull request description, or read someone else’s changes and list questions.
Think of the “track changes” feature in a shared document, with a note attached to each edit saying why it was made. Version control is that for a whole project, and an assistant that writes the notes saves you a lot of tedious writing.
Some version-control actions rewrite or delete history and cannot be undone easily. Keep the rule that sharing changes with others, or erasing history, needs your explicit approval each time.
DCapability 7: Documentation and Explanation
Words that make code understandable to the next person, who may be you.
Documentation is the writing around code: guides for how to install and run the project, descriptions of how parts work, and notes about decisions. It is easy to neglect because the code seems to work without it. But projects with poor documentation are slow for everyone. Claude Code can read the code and draft clear explanations, then update them when the code changes.
Getting-started guide
Steps for a newcomer to install, run, and test the project.
Overview of the design
A plain-language description of the main parts and how they fit together.
Comments and explanations
Short notes inside the code that explain why something is done in a surprising way.
Change notes
A readable list of what is new or different in each version.
Keep it fresh
After a change, ask for the related documents to be updated so they do not drift out of date.
A house with a labeled fuse box and a note about the water valve is a gift to the next owner. Documentation is the label on the fuse box of your project, and it saves the future owner from a cold, dark evening.
ACapability 8: Automating Repeated Chores
Small jobs that eat up time can be handed over.
Beyond one-off tasks, Claude Code can help with chores that come up again and again. Updating the same pattern in fifty files, converting a batch of files to a new format, checking that notes follow a template, preparing a weekly summary of what changed. Some setups also let it run without a person present, started by a schedule or by another program, for jobs like regular reviews or reports. What is available depends on the version and plan, so check the documentation.
Same change in many places
Rename, update, or reformat across a large project in one go.
Convert files
Transform many files from one form to another, checking each result.
Regular reports
Summarize recent changes or open problems on a schedule.
Automatic checks
Run a formatter or test automatically after each edit, so problems show up at once.
A dishwasher does not cook, but it takes away a daily chore so you have time and energy for cooking. Automation in Claude Code takes the dishwasher role in your working day.
The more a job runs without you watching, the tighter its permissions should be. Unattended work should be narrow, easy to undo, and reviewed afterward.
LCapability 9: Learning and Teaching
A patient tutor that can look at your actual code.
For learners, Claude Code can be a tutor that works on real material. You can ask it to explain a function line by line, to describe a new concept using your own project as the example, to suggest small exercises, and to review your attempts with kind but honest feedback. For teachers and team leads, it can prepare explanations, sample tasks, and notes for newcomers.
Good learning uses
- “Explain this section in simple words”
- “Why was it written this way, and what are the alternatives?”
- “Give me a small task to practice this idea”
- “Review my attempt and explain the problems”
- “Draw the steps as a short list”
Learning traps
- Accepting code you do not understand
- Letting it do every exercise for you
- Skipping the step of trying first
- Believing an explanation without testing it
- Not asking “why” when something surprises you
A calculator can finish a sum faster than you, but a student who always uses it never learns arithmetic. A good learner uses the tutor to understand, tries first, and uses the answer to check.
HHow It Works Inside: The Agent Loop
Gather, act, check, repeat.
Under the surface, Claude Code follows a simple loop. It reads your request and looks at the available context. It decides on the next step, such as reading a file or searching. It uses a tool to do that step. It reads the result, which becomes new context. Then it decides again. The loop continues until the goal seems met or it needs your input.
flowchart TD
A["Your request"] --> B["Gather context: read files, search, look at results"]
B --> C["Decide the next step"]
C --> D{"Is a tool needed?"}
D -->|"Yes"| E["Use a tool: read, search, edit, or run a command"]
E --> F{"Does this need your permission?"}
F -->|"Yes"| G["Ask you to approve or deny"]
G -->|"Approved"| H["Carry out the step"]
G -->|"Denied"| C
F -->|"No"| H
H --> I["Read the result"]
I --> C
D -->|"No, ready to answer"| J["Report to you: what was done and why"]
Gather
Find out what is needed by reading and searching, instead of guessing.
Act
Take a small, concrete step using a tool.
Check
Look at the outcome and compare it with the goal.
Adjust
Change course if the result was not what was expected, or ask you for guidance.
Finding your way in a new town without a map is the same loop: look around, take a few steps, check the street sign, adjust. You do not plan the whole journey in advance. You discover it as you go, and ask someone when you are stuck.
TThe Tools Behind the Scenes
What the agent actually uses to read, change, and run things.
Claude Code uses a set of built-in tools, and each is simple on its own. The power comes from combining them. Exact names and the full list change over time, so this is a general picture.
| Kind of tool | What it does | Risk level |
|---|---|---|
| Reading and searching files | Look at file contents, and find names or phrases across the project | Low, since nothing changes |
| Editing and creating files | Change existing files or make new ones | Medium, reversible with version control |
| Running commands | Run programs, tests, and system commands on the machine | Varies from low to high, depending on the command |
| Web access | Look up documentation or pages, where enabled | Medium, as outside content comes in |
| Connected services | Reach tools such as issue trackers, through connectors you add | Depends on what you connect and the access you give |
| Helper agents | Hand a side task to a separate helper with its own context | Same limits as the main agent |
A mechanic has wrenches, a jack, a diagnostic computer, and a phone book of specialists. None of these does much alone. The skill is knowing which to use, in which order, and when to call a specialist.
CContext: What Claude Code Knows and Remembers
A limited desk, used wisely.
Claude Code, like all language models, can keep only a limited amount of text in view at once, called the context window. Files it reads, commands it runs, and the whole conversation all take space. In a big project, it cannot read everything at once, so it searches and reads selectively. As a session grows long, older material can fade or be condensed, and the quality of work can drop.
Be specific about where to look
Point to the folder or file. It saves searching and keeps the context lean.
One task per session
Start fresh for unrelated work, so old material does not clutter the desk.
Use the project notes file
Put lasting facts, such as how to run tests, in a notes file the tool reads at the start of each session.
Summarize before restarting
When a session gets long, ask for a short summary of progress to carry into a fresh one.
Use helper agents for side quests
Where available, let a helper do a large search and report back only the findings.
A good researcher at a small desk does not pile every book on it. They bring the one they need, make notes, and put it back. The notes file is the researcher’s notebook that survives from day to day.
If the tool starts repeating itself, forgetting your rules, or going in circles, it is usually a sign that the session is too long. Start fresh with a short summary.
NTeaching It Your Project: The Instructions File
A short note that saves you from repeating yourself every session.
Each new session starts without memory of earlier ones. To avoid explaining the same things again, projects commonly keep an instructions file that the tool reads automatically at the start. It is a plain document with the facts that a new colleague would need on day one.
What the project is
One or two sentences on its purpose and the main technology it uses.
How to run and test it
The usual ways to start the project and run its tests.
Where things live
The main folders and what each contains.
Style and rules
Naming habits, formatting, and things that must never be done.
Known traps
Parts that are fragile, confusing, or off limits, so it does not wander into them.
When you hire a house-sitter, you leave a sheet on the fridge with the alarm code location, the pet’s feeding times, and “do not touch the thermostat”. It takes ten minutes to write and spares both of you dozens of questions. The instructions file is that sheet.
Keep it short and current. A long, outdated instructions file wastes space in the context and can mislead the tool. Never put passwords or secret keys in it.
XExtending It: Commands, Skills, Hooks, Helpers, and Connectors
Ways of adding to what it can do or how it behaves.
Claude Code can be customized. You do not need any of this to start, but it helps to know what exists. Names and details differ between versions, so check the documentation for the exact current options.
Custom commands
Saved prompts you can run with a short name, for tasks you repeat, such as “review my changes”.
Skills
Packaged instructions for doing a specific kind of job well, which the tool loads when relevant.
Hooks
Rules that run automatically at set moments, such as formatting a file after each edit.
Subagents
Specialized helpers for side tasks, each with its own focus and limits.
Connectors
Standard connections to outside tools and data, such as issue trackers or documents, added only when you choose.
Plugins and bundles
Collections of the above that teams can share, where the version supports them.
A smartphone is useful on its own, but its apps, shortcuts, and accessories make it fit your life. Extensions do that for Claude Code. Start with the plain phone, and add what you actually need.
Every extension is code or instructions written by someone. Add extensions only from sources you trust, read what they do, and give them the least access they need.
PStaying in Control: Permissions and Modes
An agent that can run commands must be told clearly what it may do alone.
Because Claude Code can edit files and run commands on a real machine, it is built to ask before taking sensitive actions. You choose how much it may do on its own. A careful setup starts with it asking for most things and loosens only for actions you trust. Names and options differ between versions, so read the documentation, but the general levels are as follows.
| Level | What it means | Best for |
|---|---|---|
| Ask for most actions | Reading may be automatic, but edits and commands need your approval | Beginners and sensitive projects |
| Allow edits, ask for commands | File changes proceed, while running commands needs approval | Steady feature work with tests you trust |
| Plan only | It explores and proposes a plan, without changing anything | Understanding a problem before touching code |
| Allow listed actions | You pre-approve specific safe actions, such as running the test command, and block others | Smooth work with clear boundaries |
| Highly automatic | Few or no prompts, so only in isolated, disposable environments | Experts working in a sandbox they can throw away |
A new driver practices with an instructor with a second brake pedal. As trust grows, the instructor says less. But nobody gives a learner the keys to a race car on the first day, and the second brake stays in the car for a long time.
AArchitecture and Components
The parts that work together when you give Claude Code a task.
flowchart LR
U["You"] --> UI["Interface: terminal, editor, or app"]
UI --> AG["Agent loop"]
AG --> M["Claude model"]
AG --> PM["Permission manager"]
PM -->|"allowed or approved"| TL["Tools: read, search, edit, run, web"]
TL --> PR["Your project and machine"]
TL --> EX["Connected services"]
PR --> TL
EX --> TL
TL --> AG
AG --> CTX["Context: notes file, conversation, results"]
CTX --> M
AG --> UI
Interface
Where you talk to it and see what it plans, does, and finds.
The model
The language model that reads the situation and decides what to try next.
The permission manager
The gatekeeper that allows, asks about, or blocks each action, according to your settings.
Tools
The hands: reading, searching, editing, running, and connecting.
Context and notes
The memory for the session, including the instructions file and results so far.
The Model Proposes, the Gatekeeper Decides
An important design idea: the part that suggests actions is separate from the part that permits them. If the model is confused, or tricked by misleading text, the permission layer can still stop a harmful step. This is why your settings matter and why you should read approval prompts rather than click through them.
In a restaurant, the waiter takes your order, the chef cooks it, and the manager decides about unusual requests, like a discount. The roles are separate on purpose, so one confused person cannot cause a mess alone.
LThe Lifecycle of a Task
From idea to merged change, with you in the loop.
stateDiagram-v2
[*] --> Idea
Idea --> Explored: ask it to read and explain
Explored --> Planned: agree a plan
Planned --> Changing: approve changes
Changing --> Checking: run tests
Checking --> Changing: failures found
Checking --> Reviewing: tests pass
Reviewing --> Changing: you ask for edits
Reviewing --> Committed: you accept
Committed --> Shared: pull request
Shared --> Merged: reviewers approve
Merged --> [*]
Explore
Read first. Understand the area before touching anything.
Plan
Agree the steps and the limits, including what must not change.
Change and check
Make small changes and run checks after each one.
Review
Read the whole set of changes yourself with fresh eyes.
Commit and share
Save the snapshot with a clear message and propose it for team review.
Merge and learn
Bring it into the main project, and add anything learned to the instructions file.
A building project follows survey, design, building, inspection, and handover. Skipping the survey or the inspection is how a cheap job becomes an expensive one. The same stages protect software.
SSecurity: Using It Safely
A tool that can act on your machine deserves careful handling.
Use version control
Work in a repository with saved history, so any change can be reviewed and undone.
Keep secrets out of reach
Do not place passwords, keys, or tokens in files the tool reads. Keep them in a protected place and keep them out of prompts.
Start with limited permissions
Allow reading freely, ask for edits and commands, and widen only for actions you trust.
Use a safe environment for risky work
Try experiments on a copy, a test machine, or an isolated environment you can throw away.
Read commands before approving
Commands can delete, install, or send. If you do not understand one, ask it to explain first.
Beware of hidden instructions
Text in web pages, files, or messages can try to give the assistant orders. Treat outside content as data, and be suspicious of unexpected actions.
Vet extensions and connectors
Install only trusted ones, and connect with the least access needed.
Know your organization’s rules
Check what code and data your workplace allows to be shared with AI tools.
Letting a skilled contractor into your house is sensible when you have agreed the job, locked away valuables, and kept an eye on the work. Safety is mostly preparation and attention, rather than suspicion.
Never run commands that you cannot explain on a machine or with data that you cannot afford to lose. When unsure, ask for a plan only, or try it on a copy.
MMonitoring: Watching What It Does
You can see its work, and you should.
One advantage of Claude Code is that its work is visible. It shows which files it reads, which edits it proposes, and which commands it wants to run. Teams can also review the resulting changes through the usual review process. Developing a habit of looking at this trail is how you catch problems early.
| Signal | Where to look | What it suggests |
|---|---|---|
| Changes outside the task area | List of changed files | It may have wandered. Ask why, and undo if needed |
| Edits to tests or settings | Review of the changes | It may be bending the checks instead of fixing the cause |
| Repeated failed attempts | The session’s output | It is stuck. Give it more guidance or a smaller goal |
| Unfamiliar commands | Approval prompts | Pause and ask it to explain |
| Very large diffs | The size of the change | Too much at once. Break the task into steps |
| Repetition or forgetting rules | The conversation | The session is too long. Start fresh with a summary |
| Usage that grows quickly | Your plan’s usage information | Long sessions and large searches cost more. Narrow the task |
A good foreman walks the site at the end of the day. Most days nothing is wrong. On the day a wall is out of line, that walk saves a week.
GGiving Good Instructions
The quality of the request shapes the quality of the work.
As with a human colleague, clear instructions save time. A good request has a goal, the place to work, the limits, and the way to check success. Compare the two requests below.
A vague request
“Fix the checkout.” The assistant must guess what is wrong, where to look, what counts as fixed, and what it must not touch. The result may be a large, unrequested change.
A clear request
“Customers sometimes get charged twice when they click the pay button quickly. Look in the checkout section only. First explain the cause. Then propose a fix and add a test that fails without it. Do not change the database design. Show me the plan before editing.”
State the goal and the symptom
What is happening, and what should happen instead.
Point to where
Name the folder, file, or feature.
Set limits
Say what must not change, and what to avoid.
Say how to verify
Name the test or the check that shows success.
Ask for a plan when it matters
Review the plan before allowing edits.
Telling a taxi driver “take me somewhere nice” is a gamble. “Take me to the station, by the river road, I must arrive before ten” gets you there. Clear destination, route, and deadline make a better journey.
HHelpful Patterns for Working Together
Reusable ways of working that give reliable results.
Explore, plan, code, commit
Read first, agree a plan, implement in small steps, then save with a clear message.
Tests first
Describe the behavior you want as a failing test, then ask for code that makes it pass.
Small steps
Ask for one change at a time and check each, instead of a giant rewrite.
Branch per task
Give every task its own branch so mistakes stay contained.
Fresh eyes review
Ask a new session to review the work without the baggage of how it was written.
Capture lessons
When it makes the same mistake twice, add a line to the instructions file.
A cook who tastes as they go, cleans as they go, and writes notes in the recipe margin ends each meal with a tidy kitchen and a better recipe. These patterns are the cook’s habits, applied to code.
AAnti-Patterns: Habits to Avoid
Tempting shortcuts that cause trouble.
The habit
Approving every prompt without reading it.
Why it hurts
The safety pause becomes a reflex, and one bad command can do real harm.
Better approach
Read the action, the target, and whether it can be undone. Allow safe, repeated actions in advance instead of clicking blindly.
The habit
Giving huge, vague tasks, such as “rewrite the whole app”.
Why it hurts
The result is large, hard to review, and likely to contain subtle mistakes.
Better approach
Break the work into small steps with checks between them.
The habit
Merging changes you have not read.
Why it hurts
Working code can still be wrong, insecure, or confusing. Passing tests do not prove quality.
Better approach
Read the changes as you would a colleague’s, and ask for explanations of anything unclear.
The habit
Working without version control or backups.
Why it hurts
A bad change cannot be undone cleanly, and you cannot see what changed.
Better approach
Always work in a repository, commit before big changes, and use branches.
The habit
Putting secrets in prompts, notes files, or code.
Why it hurts
Secrets can leak into histories, logs, and shared files.
Better approach
Keep secrets in a protected store, and make sure they are excluded from anything the tool reads or saves.
BBest Practices and Common Mistakes
A short list to keep nearby.
Best practices
- Work inside a repository, on a branch
- Explore and plan before editing
- Give clear goals, places, and limits
- Ask for tests and run them
- Review every change yourself
- Keep a short, current instructions file
- Start fresh sessions for new tasks
- Use the least permission that works
Common mistakes
- Trusting output because it looks tidy
- Asking for too much at once
- Skipping the plan on a big change
- Letting sessions grow too long
- Allowing risky actions without reading them
- Forgetting that tests can be wrong
- Leaving secrets where it can read them
- Assuming every feature is in your version
Driving safely is mostly small habits repeated every time: mirrors, seat belt, distance. Good habits with Claude Code are the same, and you hardly notice them once they become routine.
TAdvantages, Disadvantages, and Trade-offs
Speed and reach, balanced against care and cost.
Advantages
- Understands a project as a whole, not in pieces
- Fast on repetitive and wide-ranging changes
- Runs and reads checks, then adjusts
- Explains in plain language
- Lowers the cost of starting on unfamiliar code
Disadvantages and risks
- Can be confidently wrong
- Needs review, which takes your time
- Can make wide changes if not guided
- Long sessions lose focus and use more allowance
- Acting on a real machine raises security stakes
| Choice | You gain | You give up |
|---|---|---|
| Approve each action | Maximum control | Speed and flow |
| Pre-approve safe actions | Smooth work | A little oversight |
| Big tasks in one go | Fewer prompts | Reviewability and safety |
| Small steps with checks | Reliability | More back-and-forth |
| Connecting outside tools | Less manual copying | A wider area to protect |
A power drill makes holes fast, but it asks for goggles and a steady hand. The speed is real, and so is the responsibility that comes with it.
LLimits: What It Cannot Do Well
Knowing the edges helps you trust it in the right places.
It can be wrong
It may misunderstand a request, miss an edge case, or invent a detail. It is a fast helper, not an oracle.
It cannot know your unwritten rules
Business decisions, team habits, and history in people’s heads must be told to it.
It sees only a slice at a time
In a huge project, the context window limits how much it holds at once.
It does not take responsibility
You are accountable for what you ship, so review matters, especially for security and money.
It works within your access
It cannot reach what your permissions and setup do not allow.
It cannot replace design thinking
Deciding what to build and why, and who it serves, remains a human task.
A very good assistant chef can follow a recipe quickly and neatly, but cannot decide what the restaurant stands for. The head chef still chooses the menu.
RReal-World Examples
Five everyday situations and how the capabilities help.
A newcomer learns a codebase
A new developer asks for a tour, then asks where payments are handled and how data flows. In an afternoon, they gain a working picture and a list of questions for the team.
A team fixes an urgent bug
An engineer pastes an error message. Claude Code traces it to the cause, proposes a fix, writes a test that fails without it, and the engineer reviews and merges after the tests pass.
A maintainer updates old patterns
A project uses an old way of doing something in sixty places. Claude Code updates them in small groups on a branch, running tests after each group, and the maintainer reviews the final set.
A solo founder builds a first version
A founder describes the first features in plain words and works through plans, small changes, and tests, learning as they go and deciding what to keep.
A writer of guides keeps docs fresh
After each release, Claude Code compares the changes with the guide and proposes updates, which the writer reviews for accuracy and tone.
WA Worked Example from Start to Finish
One small feature, handled carefully.
A developer wants a simple “last updated” date to appear at the bottom of a product page. Here is how a careful session might go.
Set up safely
The developer opens the project on a fresh branch, confirms everything is saved, and chooses a setting where edits and commands need approval.
Explore first
“Find where the product page is built and how dates are shown elsewhere. Do not change anything.” Claude Code reports the two relevant files and the existing date style.
Agree the plan
“Propose a plan to show the last-updated date in the same style, with a test. Keep changes to those files.” The plan lists three small steps.
Make and check
Claude Code adds the date, writes a test, and runs the tests. One test fails because of a date format. It fixes the format and runs the tests again.
Review the changes
The developer reads the list of changed files, sees only the expected ones, and reads the new test to be sure it checks the right thing.
Try it for real
The developer opens the page and confirms that the date looks right, including for a product with no date.
Commit and share
Claude Code drafts a commit message and a pull request description. The developer edits them and asks a colleague to review.
It is like asking a carpenter to hang a shelf: look at the wall, agree the spot, hang it, check that it is level, try it with books, and write down what was done. Small job, careful steps, no surprises.
RReady-to-Use Prompts for Claude Code
Copy the shape of these, and change the details.
Get a tour
“Explore this project and explain its purpose, main folders, and how a request flows through it. Do not change anything.”
Plan before editing
“Propose a step-by-step plan for [goal], naming the files you would change. Wait for my approval.”
Diagnose an error
“Here is the error message. Find the cause, explain it in simple words, and propose the smallest fix. Add a test that fails without it.”
Review my changes
“Review my uncommitted changes as a careful colleague. List risks, unclear parts, and missing tests.”
Teach me
“Explain how [feature] works as if I am new to programming, using an everyday comparison. Then give me a small exercise.”
Keep to the task
“Only touch files in [folder]. Do not change settings, tests, or dependencies unless you ask me first.”
Save favorite prompts as custom commands where your version supports it, so a good review or planning routine is one short name away.
GGetting Started: A First-Week Plan
A gentle path from curiosity to confidence.
Day one: install and look around
Follow the official setup steps for your version, open a small practice project, and ask for a tour. Change nothing yet.
Day two: learn the controls
Read the permission options, try the plan-only mode, and notice how approval prompts look.
Day three: one tiny change
Ask for a small, safe edit on a branch, such as fixing a typo or adding a comment. Review it and commit.
Day four: a bug and a test
Pick a small known bug. Ask for the cause, a fix, and a test that fails without it.
Day five: write the instructions file
Record how to run tests, the folder map, and the rules you had to repeat during the week.
Then: widen slowly
Try a small feature, then a helper command, then a connector. Add one thing at a time, and keep what proves useful.
Learning to swim starts in the shallow end with your feet on the floor. You go deeper only when the shallow end feels easy. Each new capability is a step toward the deeper water, taken only when the last one is comfortable.
Practice on a project where mistakes are cheap: a personal experiment or a copy. Confidence built there carries over to real work.
MMyths About Claude Code
Five common beliefs that are only partly true.
| Myth | The more accurate picture |
|---|---|
| “It will replace programmers.” | It takes over much of the reading, searching, and routine editing, while people still decide what to build, judge quality, and carry responsibility. |
| “If the tests pass, the work is correct.” | Tests only check what they were written to check. They can be missing, weak, or even changed to pass. |
| “It remembers my project from last week.” | Each session starts fresh. Lasting facts belong in the project’s instructions file. |
| “More automation is always better.” | Speed rises with automation, and so does the cost of a mistake. Match the autonomy to the risk. |
| “It is only for experts.” | Experts get the most from it, but learners can use it as a patient tutor if they try first and ask why. |
A common thread runs through these myths. Each assumes that the tool is either magic or useless. It is neither. It is a fast, tireless, imperfect colleague, and the best results come from people who give clear direction, check the work, and keep the responsibility.
FFrequently Asked Questions
Quick answers to what beginners ask most.
SSummary and Key Takeaways
If you remember only a few ideas from this guide, make it these.
Key Takeaways
- It is an agent in your project. Claude Code reads files, searches, edits, runs commands, and checks results in a loop, instead of only answering from pasted text.
- It does many kinds of work. Explaining code, building features, fixing bugs, writing and running tests, refactoring, managing changes, documenting, automating chores, and teaching.
- Permissions keep you in charge. Start with it asking before edits and commands, pre-approve only safe actions, and read every prompt.
- Context is a limited desk. Point it to the right places, keep sessions focused, and use the instructions file for lasting facts.
- Work in small, checked steps. Explore, plan, change, test, review, and commit, on a branch inside a repository.
- Review is your job. It can be confidently wrong, and tests can be wrong too, so read the changes and keep secrets out of reach.
- Features change. Names, options, and plans differ across versions, so check the official Claude Code documentation for the current details.