The AI Coding Agent

A coding agent is not a faster autocomplete. It is a model handed tools — read a file, edit it, run a command, read the output — and then put in a loop until the task is done or you stop it. The rest of this module is about who holds the leash.

Anthropic’s docs describe Claude Code as an agentic coding tool that reads your codebase, edits files, runs commands and plugs into your dev tools, in the terminal, your IDE, a desktop app and the browser. The model is the brain. Claude Code is the harness around it: the tools, the context management, the thing that actually runs the command.

The loop you are stepping into

Five moves, repeated. You describe a task in plain language. It gathers context — searches and reads files, git state, your CLAUDE.md. It acts: edits, commands. It verifies: runs the tests or the build and reads the output. Then you steer. Esc interrupts it mid-action and keeps the work so far; typing while it works queues a correction it reads after the current action, instead of throwing everything away.

That last move is the job. An agent stops when the work looks done. Give it no check it can run itself, and “looks done” is its only signal — you are the test suite. Anthropic’s guide now opens with exactly that: hand it something that returns pass or fail — a test, a build exit code, a linter, a screenshot comparison. If you cannot verify it, do not ship it.

The same loop runs on every surface. All of them use the same engine, and your CLAUDE.md, settings and MCP servers are shared across the local ones.

Permission modes are a trust dial, not a settings page

Every action is allowed, asked about, or denied. The mode decides which.

Shift+Tab cycles them and the status bar says where you are; claude --permission-mode plan starts you in one. A repo cannot trap you: auto and bypassPermissions are ignored when a project’s own .claude/settings.json sets them.

On Pro, Max and Team plans the built-in starting mode is now auto for interactive terminal and VS Code sessions. Enterprise plans, Console API keys and every claude -p run still start in Manual. “Claude Code asks about everything by default” is out of date — which changes what you have to watch.

Auto mode exists because of the first number. Anthropic’s post states it plainly: “Claude Code users approve 93% of permission prompts.” Clicking Yes ninety-three times in a hundred is a reflex, not review — the post calls it approval fatigue. So a second model reviews actions instead of you, blocking things that escalate beyond what you asked for. The same post reports a 0.4% false-positive rate and a 17% false-negative rate on real over-eager actions, and the docs say outright that it reduces prompts without guaranteeing safety. A seatbelt, not a cage.

Plan mode: argue with the plan, not the diff

In plan mode the agent reads and explores but cannot touch your source. It comes back with a plan; Ctrl+G opens that plan in your editor so you can rewrite it before approving. Adding one constraint to a plan costs you a sentence. Pulling the same constraint out of finished code costs you the afternoon. On approval you pick how it runs: auto mode, manual approval of each edit, or “No, keep planning”.

For anything non-trivial the recommended shape is explore, plan, implement, commit. Skip the plan when you could describe the diff in one sentence — a typo, a rename, a log line. Planning pays when the approach is uncertain, the change spans files, or the code is unfamiliar to both of you.

What it loads before you type anything

CLAUDE.md is read whole at the start of every session, broad to specific: ~/.claude/CLAUDE.md, then the project’s ./CLAUDE.md or ./.claude/CLAUDE.md, then a gitignored ./CLAUDE.local.md. Since v2.1.277 Claude Code also reads a repo’s AGENTS.md by itself when no CLAUDE.md exists — the same file Codex, Cursor, Copilot and Jules already read. Module 6 covered what to put in it; carry two facts here. Keep it under 200 lines, because bloat makes rules get ignored. And it is context, not enforcement: to truly block something, use a deny rule or a hook.

Everything shares one context window — conversation, every file read, every command’s output, CLAUDE.md, loaded skills — and quality drops as it fills. Four commands are the whole toolkit: /context shows what is eating the window, /clear starts a fresh conversation and costs nothing, /compact keep the API decisions and the file list summarises on your terms, and /btw what does localStorage do? asks a side question that never enters the history. The docs’ own rule: corrected it twice on the same thing? /clear and write a better prompt instead of a third correction.

Rewind is local undo. Git is real undo.

Every prompt that starts a turn creates a checkpoint. Esc Esc on an empty input (or /rewind) opens the menu: restore code and conversation, restore one of them, or summarise part of the session. The last 100 checkpoints per session are kept, and snapshots are swept after about 30 days.

Here is the part people learn the hard way. Checkpoints track edits made by Claude’s own edit tools. They do not track files changed by Bash commands, most subagent edits, your own manual edits, or anything remote — a database write, a deploy, a push. That is the entire argument for git init and a commit before you let an agent run.

Four ways to teach it once instead of every time

Skills are a folder with a SKILL.md in .claude/skills/<name>/. Only the description sits in context; the body loads when it is needed, which is why a skill beats another page bolted onto CLAUDE.md. Call it as /name, or let the agent pick it up when the description matches. It follows the open Agent Skills standard, so skills are not Claude-only.

Subagents are helpers with their own context window, tool list and permissions. They do the noisy work — searching a big repo, reading a log — and return a summary, so the mess lands in their window, not yours. Explore, Plan and general-purpose are built in; yours live in .claude/agents/<name>.md. Their edits usually are not restored by /rewind.

Hooks are your own shell commands, run at lifecycle events: PreToolUse (which can block an action by exiting with code 2), PostToolUse, Stop, Notification. Unlike a line in CLAUDE.md, a hook always fires. That is the difference between “please run the formatter” and a formatter that runs.

MCP is an open standard for plugging external tools and data into an agent: issue trackers, databases, browsers, design tools. The cleanest first server is the Claude Code documentation itself.

claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp
claude mcp list
# claude-code-docs ... Connected

Now it looks up its own docs instead of guessing at a flag. The classic mistake is dropping the -- when the server is a local command (claude mcp add playwright -- npx -y @playwright/mcp@latest); everything after -- is the command that starts the server. MCP tool definitions are deferred, so they cost little context — but a plain CLI tool like gh is still cheaper for the same job.

The landscape in September 2026, without the hype

Every tool below is the same idea — a model, tools, a loop, a permission model, an instructions file. They differ in where they run and what they cost.

Kazakhstan is on Anthropic’s supported-countries list for both Claude.ai and the API, and on Antigravity’s list too. Three accounts cost nothing and need no card: GitHub with Education applied for (Copilot Student), a personal Google account (Antigravity, Jules), a ChatGPT free account (Codex). If you can spend $20 a month, spend it on one plan, not three. A flat subscription with usage bars is predictable; per-token API keys are where surprise bills live — across enterprise deployments the docs report about $13 per developer per active day.

Six parts of a prompt that works

The gap between a disappointing result and a good one is almost never the model. It is what you left out.

Six parts, and you rarely need all six at once:

1. Role — the standard it judges its own work against. “You are a senior frontend engineer who values boring, readable code.”
2. Goal — one sentence with a finish line. “Make it better” has none.
3. Context — files to read first, the existing pattern to copy, the stack. Without it the agent invents a stack that is not yours.
4. Constraints — what not to touch, no new dependencies, what is out of scope. Named before they happen, not after.
5. Output shape — “show me the diff for each file before applying it” decides whether you review the work or merely receive it.
6. Stop condition — “if anything is ambiguous, ask me instead of guessing; stop after the tests pass”. The highest-value line in most prompts.

When a result disappoints, walk this list before reaching for a bigger model. It is usually number 3 or number 6.

make the signup better

The prompt pack you will actually reuse

Six prompts that cover most of the work in front of you. Square brackets are yours to fill in. Nothing here is Claude-specific — they work in Codex, Cursor, Copilot and Kiro too.

I want to build: [one or two sentences].

Before writing anything, interview me. Ask one question at a time.
Skip obvious questions; dig into what I probably have not thought through:
- who the user is and the single most important job they need done
- the smallest version that is still useful, and what is explicitly OUT of scope
- data: what is stored, where, who can see it
- edge cases, failure states, empty states
- tech constraints: [stack / hosting / budget / deadline]
- how we will know it works (checks a script or a person can run)

Stop when you have enough, then write SPEC.md with these sections:
1. Problem and user  2. Goals / Non-goals  3. User stories with acceptance criteria
4. Data model  5. Screens or endpoints  6. Tech decisions and why
7. Out of scope  8. End-to-end verification steps  9. Open questions

Do not write code. I will review SPEC.md and start a fresh session to build it.

Read SPEC.md and the existing code under [paths]. Do not edit anything yet.

1. Tell me what you found: relevant files, existing patterns to reuse, risks.
2. Propose an implementation plan as PLAN.md:
   - ordered steps, each small enough to verify on its own
   - files to create or change per step
   - the test or check that proves each step works
   - what you will NOT touch
   - questions or assumptions I must confirm
3. Offer one simpler alternative if there is one, with the trade-off.

Wait for my approval before implementing. If a step turns out wrong while
implementing, stop and update the plan instead of improvising.

Bug: [what the user sees]. Expected: [what should happen].
Where: [page / endpoint / file guess]. Since: [commit, date, or "unknown"].
Evidence: [paste error, log lines, screenshot].

Process:
1. Reproduce it. Write a failing test (or a script) that shows the bug. Show me the failure.
2. Find the root cause. Explain it in 3-5 sentences. Do not hide the symptom
   (no try/catch that swallows it, no skipped or deleted tests).
3. Fix it with the smallest change. Run the new test and the related suite.
4. Show evidence: the command you ran and its output.
5. Tell me if the same mistake likely exists elsewhere; list places, do not fix them yet.

Do not refactor unrelated code. Commit with a message that explains the cause.

Refactor [file or module] so that [specific goal]. Behaviour must not change.

Before you start: run [test command] and show me it passes. If it does not, stop and tell me.

Rules:
- No new features, no new dependencies, no change to the public interface
  unless I approve it first.
- One kind of change per commit: structural OR behavioural, never both.
- Never delete, skip or weaken a test to get the suite green.
- If you need to change behaviour to make this work, stop and explain why.

After: run the same tests, show the output, and give me three bullets on what
moved where and what is now easier to change.

You are reviewing a change you did not write. Use a fresh session or subagent.
Inputs: the diff of [branch or PR], SPEC.md / PLAN.md, and AGENTS.md.

Check, in this order:
1. Correctness: does it do what the spec says? Which requirement is missing or wrong?
2. Edge cases from the spec: is each one handled AND tested?
3. Security: input validation, auth checks, secrets in code, injection, unsafe defaults.
4. Scope: anything changed that the task did not require?
5. Tests: would they fail if the feature broke? Any test weakened, skipped or deleted?

Report only findings that affect correctness, security or the stated requirements.
For each: file and line, what breaks, a concrete failing scenario, suggested fix.
Put style preferences in a separate, optional list. If you find nothing serious, say so.

Add tests for [function / module / flow] in [path]. Use red/green TDD.

- Read the existing tests first and copy their style and runner ([runner]).
- Cover: the happy path, [edge case 1], [edge case 2], invalid input, and one
  regression for [past bug] if relevant. Avoid mocks unless the dependency is
  external or slow.
- For new behaviour: write the test, run it, show me it FAILS for the right reason,
  then implement until it passes.
- For existing behaviour: if a new test fails, stop and tell me — it may be a real bug.
  Do not change production code to make a test pass without asking.
- Run only the relevant tests while iterating, the full suite once at the end.
  Show the final output.
Never delete, skip or loosen an existing test to get green.

Two borrowed rules are worth naming. The red step in prompt 6 exists because a test you never saw fail may be passing for the wrong reason (Simon Willison). The structural-versus-behavioural split in prompt 4 is Kent Beck’s, who also lists the three signs an agent is going off the rails: it loops, it adds things nobody asked for, and it cheats by disabling tests.