LESSON 18 / 18STAGE 2 · BEYOND THE CHAT20 MIN

The coding agent

The same window with hands on your computer: it reads folders, writes files, and runs programs — and a change it proposes comes back as a diff, the list of lines that would change, to read before anything is kept. When the folder is a repository — one where every kept change is recorded — nothing is unfixable.

STAGE
Beyond the chat
TIME
20 minutes
EXERCISE
Give a coding agent one instruction in a folder holding one file you wrote, then read the diff it hands back and decide whether to keep it — on your own computer, or from the run printed in the lesson.
PLATFORMWhich product’s names this page uses — BOTH shows every name.

PULLS OFF THE SHELFThe command line Source of truth

What you'll walk away with: what changes when the same window can touch your own files, and the one thing you read before you let it keep anything.

You need: about 20 minutes, the folder you made in lesson 16 — or one you make now — with its one plain-text file, and a coding agent already set up in ChatGPT or Claude, from a lab on this site or from work you already do. Nothing to install: with none set up, the run is printed below, and the reading is the whole exercise.

First, thirty seconds of retrieval — from memory, not from the page: what is an agent made of? Say it, then check it against lesson 17: the window, standing instructions, reach, and a loop that hands the window its own next prompt — every step a request and a result to open, and a gate where it stops to ask before the step that matters. That run worked on your apps and files through the product's own surface. This one works in a folder on your own computer, and the receipt changes shape with it: not only a step you open but a diff — the list of lines that would change — arriving before anything changes. That is the whole lesson, and the exercise is one instruction long.

The same window, with hands on your computer

Nothing new runs in the machine; what changed is what a step can touch. The window is still the window — lesson 03's complete list — and a step reads folders, writes files, runs programs. The command line keeps that definition, and the move it licenses comes first: before you give one an instruction, name the folder it is allowed to work in, and point it at that folder and nothing wider.

Both products ship one — Codex (ChatGPT) · Claude Code (Claude) — and everything below is true of the mechanism, not of either product's screen on the day you read this.

Every action is a step, and a step leaves a receipt. Lesson 14 gave you the fork: a reply naming something either came from a step that ran or was completed from the odds, and the receipt is what separates them. Pointed at your files, the fork reads the same way — a sentence saying it read the file is not the file having been read. So count the steps it lists, then open the one that changed something.

The diff is the receipt that lists lines. It names each file the step would touch and each line it would add or remove, and it exists before anything is kept — then comes the question, which is lesson 17's gate pointed at your own files. Answer that question from the diff's lines, never from the sentence above it that summarizes them.

A folder where nothing is unfixable

The folder can be a repository — a folder that keeps a record of its changes, so any version the record holds can be brought back. Lesson 16 had you build a home a next window can read, and source of truth lists a repository as that home for work that is code or data. Even one text file can sit in one. The move is a question, asked before anything writes: does this folder keep a record of its changes, and is this file in it yet? If you cannot tell, ask in the same window, and open the step behind the answer. If both are yes, a change you keep is a change you can take back, and read-then-keep is cheap rather than nervous because the keeping is recorded.

If either is no, the diff is still the receipt, the question is still the gate, and discarding still costs nothing: the repository makes a kept change reversible, not the diff readable. Nothing here says nothing can go wrong; it says that once a file is in a repository's record, nothing you keep has to be final.

Do this in ChatGPT and Claude

Setup. The folder from lesson 16, holding the one plain-text file you wrote, and nothing else. No folder yet: make one now, on your own computer, with one plain-text file of three lines — what this is, where it stands, what was decided. Not plain text? Write those three lines into a new plain-text file and use that.

Predict first, in writing, two things: how many files will it change, and will it stop to ask you before anything is kept?

Step 1 — the nearest door. Open the nearest door your product offers to Codex (ChatGPT) · Claude Code (Claude), and point it at that folder. Menus move, and so do the ways in; look for the nearest thing that works inside a folder on your computer.

Step 2 — one instruction. Use your file's name where this says notes.md.

Add a dated line at the top of notes.md that says: moved to the project folder on [today's date]. Change nothing else. Show me the change before you apply it.

It asks to install or run something you do not understand. Decline, then ask in the same window what that step would do and which files it would touch, and read the answer before you answer. Not a failed exercise — lesson 14's read-first rule, one step earlier than you expected.

No coding agent set up? The run below is SIMULATED — shaped like the one just described, written out so the reading works without the product; nothing ran to produce it, there is nothing to paste, and it claims nothing about what your account would do. Predict the same two things from the Told to line before you read on.

SIMULATED RUN — nothing here ran in your account; do not paste it

Told to: add a dated line at the top of notes.md saying it moved to the project folder today; change nothing else; show the change before applying it.

Step 1 · read file notes.md — returned: its text, 12 lines.

Step 2 · edit file notes.md — one line added, none removed — waiting for your approval.

It says: one small edit, as asked.

The line it would add, marked +, and the two lines under it, unchanged:

+ 2026-09-12 — moved to the project folder.

Status: drafting

Owner: me

Then, before anything was kept: Apply this change? (y/n)

Step 3 — read what came back, in this order. Whether you ran it or read it above, the order is the same. First the steps: each a request and a result, and their count is your first prediction checked. Then the diff: the file it names, the lines marked added or removed. It is the receipt because the step that would make the change produced it, and it lists lines, not intentions — the sentence above it, "one small edit, as asked", is a completion like any other, lesson 10's shape with a file under it. One file and one added line is what the instruction licensed; anything more is the shape to catch. Then the question — the gate, and your second prediction checked. Answer it from the lines, not from any sentence above them.

Step 4 — keep it, or discard it. If you ran it, both finish the exercise. If you keep it, open the file yourself and read the top line: the diff said what would change; the file is where you check that it did.

The diff touched more than you asked. Discard it, narrow the instruction to the one file and the one line, and run it again. Nothing was kept, so the correction costs a sentence — a shape with a move, not a reason to try the other product.

No diff — the change is already made. Ask what changed, file by file, and open the file to check; keep "show me the change before you apply it" in the next instruction. If the folder is a repository and the file is in its record, the earlier version is still there.

Then the other product, if you have it set up. Same folder, same instruction. Read the two runs against each other: what repeats is the shape you can plan around; where they differ is one product's surface on one day, not a rule for next month — and the move you keep is read the diff, not a preference. One product or none: the reading is identical, and the lesson is done.


Check your understanding: you asked for one dated line at the top of one file. The reply's own summary says it added the line and touched nothing else. The diff beneath it lists that line — and two sentences rewritten further down the diff, in a file you never named. Nothing has been kept yet. What is your move, and what did the diff tell you that the summary did not?

Check yourself first — then open one good answer

Discard it and ask again, with the instruction narrowed to the one file and the one line. The diff is the receipt — every line that would change, listed before anything changes — and the summary saying it touched nothing else is a completion like any other (lesson 10): it named one file, and the diff named two. That is lesson 14's order pointed at your own files: read first, write after trust.

Your answer should have hit discard-and-narrow as the move, and the diff, not the summary of it, as the thing you read.

One last thing the path owes you. What this machine does well and badly does not follow your job ladder: two tasks that look adjacent to you can come back one clean and one wrong. You map that by use, not by reading — starting inside your own expertise, where you can tell which is which.

Use this every time something runs on your own machine. Read the diff, then keep it — that order, and, in a repository, the record underneath it, makes a wrong run something you undo rather than something you regret. The failure to watch for is not early distrust; it is overtrust after a run of good answers, the moment the checking stops. Roughly ten working hours on your own material is our working rule, and the labs are where the first of yours are waiting. Next: the labs — or back to the path for another lesson.