Meet Your Coding Agent

From here the AI gets hands (lesson 04). Steps 1 to 3 were conversation and writing, and a plain chat was enough. Steps 4 to 7 happen in your project, with a coding agent that reads your files and changes them. Before it builds anything, it needs a first day.

Our goal: know what a coding agent in your editor is, decide how much it may do without asking, see how it works from your documents, and give it a short file for the rules the documents do not hold.

Here is the route:

A new hire's first day, and the agent's.
The agent in your editor.
How much it asks before it acts.
Where your sessions happen.
From the documents straight to code, and later tasks.
Teaching it your project with a short file.

We leave out installing and pricing (they change often, so the official page is the place), and building anything (lesson 11).

The process in this course is general. It works with any capable language model and any tool that lets you talk to one. The examples use Claude Code, so there is something concrete to type and see.

A new hire's first day

Think of a developer's first day at a team. They get a desk, a login and a pointer: "start with the handbook". They read before they touch anything. For the first week, someone looks over their shoulder, and they ask before doing anything risky. Nobody hands them the production server on day one.

An agent is a new hire every time (lesson 02). It remembers nothing from yesterday, so the first day happens at the start of every session. The documents are what make that cheap: the agent reads them first, as a new hire reads the handbook. This lesson sets up the desk, the ask-first rule, and a short file for the rules the documents do not hold.

The agent in your editor

The agent you met in lesson 04 can live in two places. One is a terminal, the text window where you type commands. The other, which this course uses, is inside your editor. A panel sits beside your code. You type a request in it, and the agent reads your files, proposes changes and shows them as a diff (the old and new lines side by side) in the editor you already know.

💡 A simplification: the picture is one way to draw it. Products differ in the details of what the panel shows.

Claude Code, GitHub Copilot's agent mode and Cline all work this way. They look different and have different settings, and they follow the same pattern: a panel, a project they can read, tools they can run, and a way to ask you first. Most of them are strong, so the choice matters less than the habits around them. Use the one your team already has, and the process in this course carries over. This course shows Claude Code, because something concrete is easier to learn from.

In Claude Code. There is an extension for VS Code, and a terminal version started with the command claude. Install steps change often, so follow the official setup page and sign in with your Claude account when asked. Other tools have their own pages.

How much it asks before it acts

The agent can edit files and run commands, so the first setting to choose is how much it may do without asking. A person on day one is trusted a little, then more as they prove themselves. An agent works the same way.

Names and details differ between tools, so check yours. The names above are Claude Code's. Start at the left. The agent stops before every edit and every command, and you read each one. That is slow on purpose. As you learn what it does, you can loosen the setting for things you trust, such as letting edits through while commands still ask. The right-hand end is for isolated machines where nothing real can be harmed. A project folder with your real work in it is not that.

In Claude Code. The mode is shown at the bottom of the prompt box in VS Code, and you click it to switch. In a terminal, Shift+Tab cycles through the modes. Manual asks before edits and commands. A new session may start in a different mode, depending on your version and settings, so look at the indicator and choose Manual yourself.

The bar at the bottom of the picture is different in kind. A deny rule is a limit the tool enforces, so it holds in every mode, including the ones that ask nothing. It is a wall, and not a request (lesson 02). The last section uses one.

Where your sessions happen

This is where you would have held the sessions of lessons 07 to 09. Exploring, documenting and specifying work in a plain chat, and they work just as well in the agent's panel. Use whichever you like. The panel has one advantage: it can save the README and the specs straight into the project folder, so nothing is copied by hand.

By now those documents exist: a README, a task list and a spec for each task. That changes what a session looks like.

From the documents straight to code

You do not need a warm-up session to introduce the agent to the project. With the documents in place, go straight to one task and one spec:

Build task 03 from docs/specs/03-add-book.md.

The next lesson shows that request in full. The agent finds what it needs in the documents: what the project is for, what was decided and why, how the team likes code written, and exactly what this feature must do. That is what the documents were written for.

Later tasks: documents first, code only when needed

It is tempting to think the agent must read the whole codebase before each task. It does not. The documents carry the picture, and the code is the detail.

Think of a developer who has been on the team a while. Given a ticket, they do not reread the whole code base. They know what the project is, and they open the one file that the ticket touches. When something is unclear, they look at the code. The agent works the same way. It reads the documents first, and opens a piece of code when the documents cannot answer the question. A tidy, current set of documents therefore saves time and keeps the agent from guessing at what the code was meant to do. When the documents and the code disagree, rule 1 says to fix the documents first (lesson 14).

This is why the documents are worth the care you gave them in lessons 08 and 09.

Teach it your project

The agent starts every session knowing nothing. Most agents find the README on their own, so you rarely need to tell them. What they do not know to look for is the task list, the spec for the task at hand, and your working rules. Most tools read a small file at the start of every session, which we can call a pointer file, so those can live there. In Claude Code it is called CLAUDE.md, and it lives in the project folder. Other tools use another name (AGENTS.md is a shared one that several tools read), and the idea is the same.

A tempting mistake is to put a copy of the README in it. Do not. Two copies of the same facts drift apart, and then the agent follows the old one. That is rule 1 broken: the docs stop being true. Keep one README for the facts, and let the small file hold only what the README does not, and point at the rest.

Here is the file:

# Bookshop back office

The project overview is in README.md.
The ordered task list is @docs/tasks.md.
For a task, also read its spec in docs/specs/.

Build and test: dotnet build, then dotnet test.
Ask before changing README.md or a spec. Those are decisions.
Work on a new branch for each task. Never push.

The @docs/tasks.md line is an import. Claude Code loads the named file into the session at the start, next to this one. Only pointers and working rules live here. How to build and test, and the rules for the agent, belong in this file, because they are about how to work and not about what the project is. The build and test commands appear once task 01 has created the project.

⚠️ A common mix-up: this file is guidance, not a wall. The agent usually follows it and can still miss a line. A line that says "never push" is a request.

For a rule that must hold, use a wall. A deny rule goes in the project settings file (.claude/settings.json in Claude Code):

{
  "permissions": {
    "deny": ["Bash(git push *)"]
  }
}

This blocks the agent from pushing, whatever it decides and whatever mode it is in. Use walls for a few things that would hurt, such as pushing, deleting data or reading secrets, and use the file for everything else.

Start with these few lines. Add a line only when something has actually annoyed you, such as the agent using the wrong build command twice. That is rule 2 (lesson 08): what you learn goes back in. A file of fifty rules on day one is read less carefully than a file of five.

Where we ended

The project gains two small files. The documents (README, tasks, specs) stay tool-neutral, and these two are the only files that belong to the tool.

Before (the end of lesson 09):

bookshop-backoffice/
├── README.md
└── docs/
    ├── tasks.md
    └── specs/
        ├── 01-setup.md
        ├── 02-login.md
        ├── 03-add-book.md
        ├── 04-scan-barcode.md
        └── 05-search.md

After:

bookshop-backoffice/
├── README.md                  the project document (lesson 08)
├── CLAUDE.md                  <- NEW  the pointer file, read every session
├── .claude/
│   └── settings.json          <- NEW  deny rules, the walls
└── docs/
    ├── tasks.md
    └── specs/                 01 to 05, as before

Recap

A coding agent in your editor is a panel beside your code. It reads files, proposes changes as diffs, runs commands and asks you first. Claude Code, Copilot's agent mode and Cline follow the same pattern, so pick the one your team already has.
The agent is a new hire every time. Its first day is a read of the documents, and well-kept documents make that cheap.
Choose how much it asks before it acts. Start at "ask before every edit and command" and loosen it as you learn.
Your sessions for exploring, documenting and specifying can happen in the agent panel too. Once the documents exist, go straight to one task and its spec. Later tasks need no tour of the code: the agent reads the documents first and opens code only when they cannot answer.
Agents usually find the README alone. Keep a small file (CLAUDE.md in Claude Code) for what they would not: the task list, the current spec, and your working rules. Do not copy the README into it.
A line in that file is a request. A deny rule is a wall that holds in every mode.

Questions to think about

The answers are left out on purpose. Try them in your own words first.

Why does an agent need a "first day" at the start of every session?
Why start with an agent that asks before it acts, and not one that asks nothing?
Why does the agent not need to read the whole codebase before each task?
Why keep the facts in one README and not copy them into the small file?
What is the difference between a line in the pointer file and a deny rule?

Next lesson: step 4, Build. The agent builds one feature, on its own branch, from its spec.