Everything so far has lived in a chat window or in Cowork. This lesson steps onto different ground: Claude Code, an AI agent that works in your terminal and edits real code. It is the most technical tool in the course, and the most powerful for one job: building and changing software.
You do not have to be a developer to get value from this lesson. Plenty of business people run small scripts, tweak a website, wrangle a spreadsheet of data, or work with a technical team and want to understand what their engineers are now using every day. Even if you never open a terminal, knowing what Claude Code is and how it behaves will sharpen how you talk about AI at work. And if you are comfortable poking around, this is the lesson where AI stops answering questions and starts doing the work.
Last checked: July 2026. Claude Code changes quickly. Prices, commands, and features may have moved on; treat the specifics as a snapshot and check the linked docs for the current detail.
What Claude Code actually is
Claude Code is a coding agent that runs in the terminal. The terminal (also called the command line) is the plain text window where you type commands to your computer instead of clicking buttons. Claude Code lives there. You describe what you want in plain English, and it reads your files, writes and changes code, runs commands, and works through multi-step jobs, checking its own results as it goes.
Three things make it different from a chat about code:
- It sees your whole project. You start it inside a repository (the folder that holds a piece of software), and it reads whatever files it needs, when it needs them. There is nothing to upload or paste.
- It acts, it does not just advise. It can edit files, run tests, use command-line tools, and work with Git and GitHub, all from the same window.
- It keeps you in the loop. By default it asks before it changes anything, so you approve each step. More on that below, because it is the heart of using it well.
It is the same agent idea from lesson 1.1, pointed squarely at software: give it a goal, and it plans and carries out the steps rather than handing you a to-do list.
Who it is for, and why a non-coder might still care
The honest answer: Claude Code is aimed at people who work with code, and it is happiest in the hands of someone who can read a diff and knows roughly what "run the tests" means. Anthropic says you do not need to know how to code to use it, and that is true for small, self-contained tasks. But the further you get from things you can check, the more you are trusting output you cannot judge, and that is where trouble hides.
So here is a fair way to place yourself:
- You write code for a living. This is likely already part of your day. The rest of this lesson is a tour of the habits that make it reliable.
- You are semi-technical: you edit a website, run the odd script, or manage a small tool. Claude Code can genuinely help, as long as you work on a copy, review changes, and keep a backup. Treat it like a very fast junior who needs checking.
- You are not technical at all. You probably will not open a terminal, and that is fine. Read this to understand what your engineers now use, and lean on Cowork for file work instead. Knowing the difference is the win.
The rule of thumb: the value of an AI that writes code is capped by your ability to tell whether the code is right. Claude Code raises the ceiling on what you can build; it does not remove your responsibility for the result.
Getting in: install and first run
Setup is short. You install Claude Code once with a single command for your operating system (macOS, Linux, or Windows), then sign in with your Claude account. The linked quickstart walks through the exact command, which changes often enough that it is not worth reprinting here.
Once installed, the pattern is always the same:
cd my-project
claude
That is: move into the project folder, then start Claude Code. It opens a prompt right there in the terminal, already able to see the project around it. There is no upload step, which is the first thing that surprises people coming from chat. You are not handing it files; you are standing it inside your workshop.
From there you just talk. Type a message, press Enter. A good first line is not "fix everything", it is something small and legible:
Explain what this project does and how it is organised. Keep it to a short tour.
Type /help at any time to see the built-in commands. You do not need most of them on day one.
The core loop: ask, review the diff, approve
This is the part worth slowing down for, because it is what separates a useful session from a scary one.
When you ask Claude Code to change something, it does not silently rewrite your files. It shows you a diff, a side-by-side of exactly what it wants to add or remove, and waits. You get three choices:
- Yes applies that single change.
- Yes, and don't ask again for edits auto-approves further file edits for the rest of the session. Fast, but you have handed over the wheel, so use it only when you trust the task.
- No rejects the change, and you can say why, which steers the next attempt.
The same gate applies to running commands. This approve-first loop is the safety model: nothing touches your files or your machine until you say so. New users should stay in approve-first mode until they have a feel for how the agent behaves on their project.
What it can do beyond single edits
If it only edited one file at a time, Claude Code would be a fancy autocomplete. The power is that it strings steps together into real work:
- Read and explain a codebase. Point it at an unfamiliar project and ask for a tour. It will map the structure and explain how the pieces fit, which is worth the install on its own when you inherit someone else's code.
- Make a change across many files. "Rename this concept everywhere and update the tests" is the kind of tedious, error-prone job it handles well, showing you each edit.
- Run and fix tests. It can run your test suite, read the failures, and fix the code until they pass, looping on the feedback rather than guessing once.
- Work with Git and GitHub. It can create branches, write sensible commit messages, open a pull request, and even read an issue and take it from description to proposed fix.
- Plan first on hard jobs. For anything gnarly, ask it to plan before it edits. You review the plan, correct the approach, and only then let it start. Cheap insurance against a confident wrong turn.
A realistic first task, start to finish, might read:
Read issue #142. Draft a plan to fix it, wait for my okay, then make the change on a new branch and run the tests. Do not open a pull request until I have reviewed the diff.
Notice how much of that sentence is control: plan first, new branch, wait, review before the PR. That is the shape of a good instruction to an agent.
Give it standing context: CLAUDE.md, skills, and connectors
Everything you learned about context in Part 2 applies here, with a coding twist.
- CLAUDE.md. Drop a file called
CLAUDE.mdin the project and Claude Code reads it every session. It is a standing brief for the repo: the conventions to follow, how to run the tests, what to never touch, where the tricky bits are. Write it once and every future session starts already briefed, exactly like the profile instructions from lesson 2.5, but scoped to this codebase. - Skills. The same Skills idea from lesson 4.2 works here: package a repeatable task ("prepare a release", "add a new API endpoint our way") so it is done the same way each time.
- Connectors and MCP. Claude Code can reach the same connected tools you met in lesson 4.5, so it can pull a ticket from your tracker or check your error monitor while it works.
The theme is consistent across the whole course: the more standing context you give it, the less you repeat yourself, and the closer its first attempt lands.
Where it fits: chat, Cowork, or Claude Code
You now have three ways to put Claude to work, and picking the right one is a real skill.
Use chat for a quick answer, a draft, or thinking something through. Use Cowork when the work is files on your computer: a spreadsheet, a deck, a folder of documents. Use Claude Code when the work is code in a real project, and you want it read, changed, tested, and committed. They share the same brain; they differ in where they reach.
Staying safe and in control
Claude Code is powerful precisely because it can act, so a few habits matter more here than anywhere else in the course:
- Work on a branch, keep a backup. Never let an agent loose on the only copy of anything. Version control (Git) is your undo button; use it.
- Stay in approve-first mode until you trust a given task. "Yes, and don't ask again" is convenient and occasionally the right call, but it is also how a small mistake becomes twenty files of small mistakes.
- Review the diff, every time it matters. The whole design hands you a checkpoint. Skipping it defeats the point.
- Mind prompt injection. If Claude Code reads a file, a web page, or an issue that contains sneaky instructions, those can try to hijack the task, the same risk you met with Cowork in 4.4. Watch what you point it at.
- You own the output. As with every tool in this course, the code that ships is your responsibility, not the model's. Claude Code makes you faster; it does not make you unaccountable.
Cost and plans
Claude Code comes with the paid Claude plans: Pro and Max include it with usage limits that scale with the tier, and teams can also bill usage through the Claude API. Heavy, long-running sessions use more than a quick chat, so keep an eye on usage the same way you learned to keep the context window lean in Part 4. As always, the linked pages carry the current numbers.
Try it
If you have a terminal and a small project handy, this takes ten minutes. If you do not, read it as a walkthrough so the shape is familiar when you need it.
- Open your terminal, move into a small project folder (
cdinto it), and start Claude Code. - Ask it for a short tour: "Explain what this project does and how it is organised." Read the reply. This alone is often a revelation on unfamiliar code.
- Now ask for a tiny, safe change, for example: "Add a short comment at the top of the main file explaining what it does. Show me the diff first."
- When the diff appears, read it, then choose Yes or No. Feel the checkpoint. That pause is the whole safety model.
- If you use Git, ask it to "commit this on a new branch with a clear message." You have now run the core loop end to end.
The goal is not the comment. It is to feel how an agent proposes, waits, and acts, so you trust the loop before you point it at something that matters.
(General exercise. Role and industry versions come once accounts are in.)
