What the agent actually does

From the outside it looks like magic: you type a sentence, files appear, the thing runs.

From the inside it is five boring steps in a loop. Knowing them is what turns “it didn’t work” into “it failed at step one, and here is why”.

The five steps

Say you ask for this:

Add a dark mode toggle to the settings page.

Here is what happens.

1. It gathers context. The agent looks for what it needs to know: which files exist, what the settings page currently contains, how styling is done in this project. It opens a handful of files and reads them.

It does not read your whole project. Projects are too big, and the agent has a limited working memory — a context window. It reads what it thinks is relevant.

2. It forms a plan. Usually silently, sometimes out loud. Something like: add a toggle control to the settings page, store the choice, apply a CSS class to the root element.

3. It writes changes. It edits real files on your disk. Not a preview, not a suggestion — the actual files, unless your tool is set to ask first.

4. It runs something. Starts the app, runs the tests, executes a build. This is where reality gets a vote.

5. It reads the result and decides whether to loop. If the build failed, it reads the error and goes back to step three. If it looks fine, it stops and tells you what it did.

Step one is where most failures start

The agent knows three kinds of things:

• What it read — the files it actually opened in this session.
• What you told it — your request, plus any notes file in the project it picked up.
• What it absorbed during training — general knowledge of languages, libraries and patterns, frozen at some point in the past.

That last category is the dangerous one, because it feels identical to the other two from the inside. The agent cannot tell you “I am remembering this rather than reading it”. It just answers.

So when it invents a function that does not exist in your project, it is not lying. It read three files, none of which contained your existing helper, and generated something reasonable for a project shaped like the one it saw.

What it changes, and what you can stop

Two things happen in a session that touch the real world:

File edits. New files, modified files, occasionally deleted files. All reversible if you are using version control — a system that records snapshots of your project so you can go back. If you are not, they are reversible only by hand.

Commands. Installing packages, starting servers, moving files, calling out to the internet. Some of these are reversible. Some are not.

Most tools will show you a command before running it and wait for approval. That prompt is not a formality. It is the single cheapest place to catch an expensive mistake, and it takes two seconds to read.

Where you are supposed to interrupt

There are three natural interruption points, and using them is most of what separates a smooth session from a mess:

• Before the plan is executed — “wait, that is not what I meant”.
• Before a risky command runs — “no, do not install that”.
• After the first run — “it works, but not the way I want”.

Interrupting is cheap. A wrong direction caught in the first thirty seconds costs one sentence. The same wrong direction caught after twenty files have been edited costs an afternoon.

Try it yourself

One request, all five steps. Two of them are yours to interrupt.

The mental model to keep

Think of it as a fast, capable collaborator who has never seen your project, cannot ask your colleagues, remembers a lot of general knowledge that may be out of date, and will confidently fill any gap you leave.

That model predicts nearly everything you will experience. Gaps get filled by guesses. So the job is to leave fewer gaps — which is exactly what level 2 of this course is about.