Skip to content
Auf Deutsch ansehen

Lesson10 min

How coding agents work

Claude Code, Codex and their relatives all work to the same loop: read, plan, edit, verify. Know the loop and you know where to step in – and which permissions to grant for what.

Boaz Lichtenstein

Part of the path Building with coding agentsstation 2 of 5level 3 Expert

A chat assistant suggests code that you copy. A coding agent works in your project itself: it opens files, runs commands, edits, tests. The tools are called Claude Code, Codex, Copilot or Cursor and differ in many ways – but not in the loop they work to.

The loop

1. Read. The agent looks for the places that belong to the task: list file names, search for terms, open files. What it does not read it does not know – an agent that changes a function without having read its callers breaks them.

2. Plan. From what it has read comes an approach. Good agents write it down before they change anything.

3. Edit. Modify files, create new ones, run commands.

4. Verify. Run tests, start the program, read the output. If something fails, the loop starts again.

The fourth step is where good results part from bad ones. An agent with no means of verifying guesses – very convincingly.

Where it runs

Place What that means
Terminal the agent works in your project folder, with your permissions
Editor the same, embedded in the development environment
Desktop app several sessions side by side, often with a preview
Cloud a copy of the repo on the provider’s machine; the result is a pull request

Locally the agent sees everything your user account sees. In the cloud it sees only the repository – safer, but without your local files and services.

Permissions: three levels

Every agent has gradations that look roughly like this:

  • Plan only. It reads and proposes but changes nothing.
  • Ask. Before every file change and every command it waits for your consent.
  • Autonomous. It works through and asks only for certain commands.

The right level depends not on your trust in the model but on what can go wrong. In a throwaway project on a separate branch it may work through. In a folder with credentials or with access to a production system it may not.

Many agents additionally offer a sandbox: commands run in a sealed-off environment with no network and no access outside the project folder. If it exists, switch it on.

Plan mode

Have the agent plan first for every non-trivial task. You get a list: which files, which changes, in which order. From that you can see in a minute whether it understood the task. Correcting a wrong plan costs one sentence. Undoing a wrong implementation costs the afternoon.

Context is finite

Everything the agent reads takes up room in its working memory. After two hours with many files and failed attempts the answers get less precise: earlier decisions are lost, things already discarded resurface.

Three countermeasures:

  • Rules file instead of repetition. What always applies is in AGENTS.md or CLAUDE.md.
  • New session for a new subject. With a handover in five sentences: goal, state, open points.
  • Start afresh after the third correction. A better brief in a fresh session beats the fifth patch attempt.

What you should demand

An agent likes to say “done”. Demand three things instead: what was changed, which command it ran to verify and what the command printed. If the third part is missing, nothing was verified.

What a brief looks like that supplies this verification from the start is the subject of the next station.

Self-test

After a change an agent reports: “Done, everything works.” What can you rely on?

On this learning path

Building with coding agentsStation 2 of 5

Next station

Briefs an agent's work can be accepted against

You write briefs an agent can implement without follow-up questions and measure against a test.

9 minLesson