Agentic Coding: A Practical Primer

How to get great results from an AI coding agent by treating it like the powerful tool it is, not a magic box you throw wishes at.

About this version: I first wrote this primer earlier in 2026 and updated it in October. The habits haven’t changed. The tooling around them has: bigger context windows, a new top model tier, an auto mode that is now the default, and built-in review commands.

Introduction

For most of the history of software, the developer typed every line. AI assistants started by autocompleting the next few, and then something changed. Modern coding agents don’t just suggest text. They read your files, plan an approach, write and edit code across the project, run commands, execute tests, read the output, and fix their own mistakes, in a loop, with very little hand-holding. Increasingly they do it in parallel and in the background, too.

That shift has a name: agentic coding. And it changes your job. You move from writing code to directing the writing of code. The interesting part is that the quality of what you get back depends almost entirely on how well you direct.

This guide covers the fundamentals: the handful of habits that separate “the AI keeps producing garbage” from “I shipped a week of work in an afternoon.” The examples use Claude Code, but the principles apply to any capable agent.

The one-sentence version: You are the architect. The agent is a fast, capable, literal junior engineer who has read most of the internet but knows nothing about your system until you tell it. Everything below follows from that.

1. You Are in Charge

This is the mindset everything else hangs on. The agent is not an oracle you delegate to and walk away from. It is a tool you steer.

Stay in the loop. Watch it work. The moment it heads the wrong way, interrupt it (Esc in Claude Code) and redirect. A bad direction caught in five seconds costs nothing; caught in five minutes it has rewritten ten files.
The decisions are yours. Architecture, trade-offs, which library, what “done” means: those are your calls. The agent can recommend, brilliantly, but you decide.
You own the output. “The AI wrote it, I don’t know why it’s broken” is not a thing you get to say. If your name is on the commit, it’s your code (more on this under Verify).

The developers who get the most out of agents aren’t the ones with the cleverest prompts. They’re the ones who understand their problem well enough to direct someone else to solve it.

2. Context Is Everything

If you remember one thing from this guide, make it this:

The agent can only act on what it knows, and it does not know what you know. If you can’t articulate what knowledge a task requires, the agent can’t supply it either. This is no different from coding by hand: you couldn’t write that integration without the API docs either. Don’t assume the agent already knows your system. Give it the knowledge.

A vague request (pasting a stack trace with “fix this,” or “do XYZ” and hoping) forces the agent to guess. Sometimes it guesses well. Often it invents something plausible and wrong. The fix is always the same: supply context.

What to supply

If the task involves…	Give the agent…
An API client	The OpenAPI / Swagger definition
JSON or XML handling	The JSON Schema / XSD and a couple of real example files
An internal or third-party library	The actual docs or source, so it can’t invent methods that don’t exist
Your existing codebase	A pointer to the relevant files/folders, and an instruction to read them first
A specific outcome	Your conventions, constraints, and what “done” looks like

How to hand over context (Claude Code)

@path/to/file: pull a specific file into the conversation.
Paste a screenshot or image: for UI work, error dialogs, diagrams.
Point it at a URL: let it fetch documentation it needs.
!command: run a shell command yourself and put its output straight into the conversation, e.g. !npm test.
Pipe data in: cat error.log | claude -p "what went wrong?".
Tell it what to read: “Read src/auth/ and explain how sessions are managed before changing anything.”

Don’t make it guess

Structure your prompt to match your mental model of the problem. If you’d explain it to a colleague by pointing at three files and one constraint, say exactly that.
A stack trace alone is weak. A stack trace plus what you expected, where you suspect the cause, and which file to start in is strong.
Experiment with phrasings. You’ll quickly learn how the agent interprets you and how to be unambiguous.

When the agent has no data: hallucination

Agents are strong where their training data is rich (popular languages, frameworks, public APIs) and weak on proprietary or niche systems: your internal libraries, a vendor’s SDK, a PLM/PDM platform’s plugin API. With no exposure, the agent often doesn’t say “I don’t know.” It confidently invents APIs that don’t exist.

The workaround: extract the relevant documentation into machine-readable Markdown and feed it in as context. A few pages of real reference material turns confident hallucination into correct code. Keep those files in the repo, next to the code that needs them, and the next session can find them too.

3. Teach It Your Rules: `CLAUDE.md`, Memory, Skills and Hooks

When the agent keeps doing something wrong (using the wrong build tool, ignoring your formatting, forgetting a convention), don’t re-explain it every session. Write it down once, and the agent loads it automatically every time.

`CLAUDE.md`: the rules you write

File	Scope	Use it for
`~/.claude/CLAUDE.md`	Personal: every project on your machine	Your preferences, shortcuts, tone
`./CLAUDE.md`	Project: checked into git, shared with the team	Build/test commands, architecture, team conventions
`./CLAUDE.local.md`	Personal, this project: add it to `.gitignore`	Your sandbox URLs, test data, local quirks
`CLAUDE.md` in a subfolder	That part of the tree: loads when the agent works there	Rules for one module or area
`.claude/rules/*.md` with `paths:`	Matching files only, e.g. `src/api/*/.ts`	Rules that only matter for one kind of file

Tips:

Keep it short and concrete. Aim for under 200 lines. “Use 2-space indentation” works; “format code properly” doesn’t. A bloated file is worse than none: the important rules drown in noise.
Run /init in a new project to get a generated starting point, then cut it down to what the agent couldn’t work out on its own.
Add a rule when the agent makes the same mistake twice, or when you catch yourself typing the same correction you typed last session.
Good content: “always run mvn verify before claiming done,” “never edit files under generated/,” “this project uses pnpm, not npm.”
If your repo already has an AGENTS.md for other tools, Claude Code reads it when there’s no CLAUDE.md.

Auto memory: the notes the agent writes

Claude Code now also keeps its own notes per project. Say “remember that the API tests need a local Redis” and it saves that to its memory folder and loads it next session. It also picks up your corrections and preferences on its own. Run /memory to see what it saved, edit it, or switch it off. (The old # shortcut for saving a rule is gone. Just ask, or say “add this to CLAUDE.md” when you want it in the shared file.)

Skills and hooks: when a note isn’t enough

A skill is a packaged procedure (“how we deploy,” “how we cut a release”) that the agent loads only when it’s relevant. Use one for multi-step workflows that would bloat CLAUDE.md.
A hook is a shell command that runs at a fixed point, e.g. after every file edit or before a tool call. CLAUDE.md is advice the agent tries to follow; a hook always runs. If something must happen every time (formatting, blocking edits to a folder), make it a hook.

Think of CLAUDE.md as onboarding notes for a new teammate who has perfect recall but starts every day with amnesia, skills as the team wiki, and hooks as the CI check that doesn’t care what anyone intended.

4. Pick the Right Model, and the Right Effort

The model is a dial you set per task. Bigger isn’t always better; matching the model to the job is what builds throughput.

Model	Reach for it when…
Fable	The hardest and longest-running work: big migrations, deep investigations, tasks you’d otherwise split across days
Opus	Complex, ambiguous, or multi-step work: architecture, gnarly refactors, deep debugging
Sonnet	Everyday development: well-scoped features, routine changes, the daily workhorse
Haiku	Simple tasks you want fast and cheap: small edits, quick lookups, background work

Switch with /model. There’s also opusplan, which plans with Opus and implements with Sonnet.

Effort (thinking level). Capable models “think” before they act. More effort means better answers on hard problems, at the cost of more tokens and more latency. Current models offer low, medium, high, xhigh and max, and Opus and Sonnet now default to medium. Set it with /effort. Raise it for genuinely hard problems; for a one-off deep think on a single turn, put the word ultrathink in your prompt. (Only that exact word counts; “think hard” is just text.)

Speed. /fast toggles fast mode for when you’d rather wait less than pay less.

Watch your usage. Run /usage regularly, especially in your first weeks. Subscription plans meter usage over rolling time windows, and the only way to develop a feel for “how much can I get done today” is to look. You’ll quickly learn what a big refactor costs versus a quick fix, and how far Sonnet carries you before a problem actually warrants Opus or Fable. That intuition is what lets you spend the expensive model only where it pays off.

5. The Context Window: Why It Still Matters

What’s a token? The basic unit of text a model processes: roughly 4 characters, or about ¾ of a word. What’s a context window? Everything the agent can “see” at once: your prompts, the files it has read, the running conversation, and its own output. The agent only knows what’s currently in the window.

The windows got big. When I first wrote this, a 1M-token window was a premium option. Now the current Claude models (Fable, Opus and Sonnet) run with a 1M window in Claude Code on every plan. That changes the arithmetic: a large codebase and a long task fit without the agent constantly forgetting.

But a big window is not a free one.

When the window fills, the agent compacts: it summarizes older conversation to make room. Summarizing loses detail: forgotten instructions, dropped facts, subtle drift.
Long before that, noise costs quality. Three unrelated tasks, a 5,000-line log, and a dead end you abandoned an hour ago are all still in there, competing for attention.
Every token in the window is re-read on every turn, which shows up in your usage.
Other tools that use the same models may cap the window lower. Check before you assume.

How to manage the window:

/context: see exactly what’s consuming tokens right now.
/clear: start fresh between unrelated tasks rather than dragging a polluted history into new work.
/compact: summarize on purpose, optionally with a focus: /compact keep the API changes and the failing test output.
/btw: ask a quick side question (“what was that config file called?”) without adding it to the conversation.
Start a new chat with a refined prompt when a thread gets confused. A clean start with a better prompt usually beats fighting a muddled conversation.
Delegate verbose work to subagents: large searches, log crunching, codebase surveys. A subagent does the heavy reading in its own window and reports back a clean summary, so the noise never lands in your main context.

6. The Core Loop: Explore → Plan → Implement → Verify

Reliable agentic work has a rhythm. Skip the rhythm and you get fast nonsense.

   Explore  ──▶  Plan  ──▶  Implement  ──▶  Verify
  (read &       (agree on    (agent writes    (you test,
   understand)   the approach) the code)        review, own it)

1. Explore / Plan. For anything non-trivial, or any unfamiliar code, let the agent read and propose a plan before it edits anything. In Claude Code, Plan Mode (cycle to it with Shift+Tab) doesn’t edit files: the agent investigates and drafts an approach, you review and refine it, and only then do you approve execution. This is the single best defense against the agent confidently solving the wrong problem. For small, obvious changes, skip straight to implementing.

2. Implement. The agent writes the code. Stay present. The instant it drifts, hit Esc and correct it; early course-correction is cheap. You can also just type while it works: your message is queued and read as soon as possible. And if it fails the same fix twice, stop letting it dig: step back, clear the context, give it better information, or drop to Plan Mode and rethink the approach.

3. Verify. You own this code. That means:

Test it. Actually run the thing.
Review every changed file. Scale your scrutiny to the stakes: for production code, read until you fully understand it; for a throwaway prototype, a careful scan may be enough.
Give the agent something to verify against: a test that must pass, an expected input/output, a screenshot to match. An agent with a concrete target checks its own work; an agent without one just declares victory.
Let a second pass review it. /code-review reviews your diff for correctness bugs, /simplify looks for duplication and needless complexity, and /security-review checks the branch for vulnerabilities. They’re a second pair of eyes, not a replacement for yours.
Batch your fixes. Collect the issues you found, then send one follow-up prompt that addresses them all. Repeat the test-and-fix cycle until you’re satisfied.

7. Letting the Agent Run: Permission Modes

How much the agent may do without asking is a setting, and it’s the biggest change since the first version of this primer. Cycle modes with Shift+Tab:

Mode	What runs without asking	Use it for
Manual (`default`)	Reads only; asks before every edit and command	Learning, sensitive work
acceptEdits	Reads, file edits, and common file commands (`mkdir`, `mv`, `cp`…)	Iterating on code you’re reviewing as it goes
plan	Reads and investigation; no edits	Exploring before you commit to an approach
auto	Everything, with a second model reviewing each action in the background	Longer tasks without prompt fatigue. This is now the default starting mode
dontAsk	Only pre-approved tools; everything else is denied	Locked-down scripts and CI
bypassPermissions	Everything, no checks	Throwaway containers/VMs only, never on a machine you care about

Auto mode being the default is a big deal: most sessions now run without a stream of “may I?” prompts. The classifier catches the obviously risky actions, but it reduces prompts; it doesn’t make the result correct. Your review still has to happen.

The safety net that makes any of this comfortable is git. Letting the agent run only works because you can see and undo everything:

Work on a branch and commit before a big change, so you always have a clean point to return to.
Review the diff before you commit. This is where you actually own the code.
Decide deliberately what the agent may commit or push. Generated code is reversible; a pushed commit is a conversation with your team.
Claude Code also keeps its own checkpoints: press Esc Esc on an empty prompt (or run /rewind) to roll back code and/or conversation to an earlier point. Useful, but it only tracks the agent’s own edits, so it’s a convenience, not a replacement for git.

One more habit: don’t paste secrets or credentials into the context, and switch back to Manual for anything that touches production, deletes data, or runs unfamiliar commands.

8. Know Your Craft, and How to Review AI Code

An agent amplifies your judgment; it doesn’t replace it. Knowing the classic pitfalls lets you steer, either by instructing the agent to handle them up front or by asking, after the fact, “does this implementation deal with X?”

General frontend concerns: load/performance, caching and cache invalidation, virtualization for large lists, unnecessary re-renders, responsiveness and mobile, accessibility (ARIA, keyboard nav), state management, cross-browser support, UI/UX consistency.

General backend concerns: security (injection, XSS, authorization), scalability, error handling and logging, database optimization (indexing, query efficiency, N+1), rate limiting, authentication/authorization (JWT, OAuth), concurrency and thread-safety, data integrity and validation, graceful handling of external-service failures.

You don’t have to be an expert in every item. But knowing they exist turns a glance at “looks fine” into the pointed question (“is this query going to N+1?”) that catches what the agent quietly introduced.

On top of those, watch for the mistakes that are specific to AI-written code, the things a human teammate rarely makes but an agent makes often:

Reinvents what already exists: writes a new helper instead of using yours, because it didn’t know yours was there (a context problem: point it at the file).
Uses outdated or deprecated APIs: its training has a cutoff; it may reach for an old library version or a method that has since been removed. Hand it the current docs.
Writes tests that pass trivially: asserting the obvious, or testing the mock instead of the behavior. A green checkmark is not proof.
Over- or under-engineers: a sprawling abstraction for a one-line need, or a happy-path-only version of something that needs edge cases.
Scope creep: quietly “improves” unrelated code or reformats files you didn’t ask it to touch. Read the whole diff, not just the part you expected.
Adds dependencies you didn’t want: check new imports and package files.
Confidently wrong on security: plausible-looking auth or input handling that doesn’t hold up. Treat security-sensitive code as something to verify, never to assume.

The throughline: the agent is fast and fluent, which makes its mistakes look finished. Your review is what separates “looks done” from “is done.”

Closing: Build the Habits

Six habits, and you’re most of the way there:

You’re in charge. Steer continuously; don’t delegate and disappear.
Context is everything. Give the agent the knowledge a task needs. If you don’t know what it needs, neither does it.
Write recurring rules down in CLAUDE.md, and turn must-always-happen rules into hooks.
Match the model and effort to the task, and watch your usage to build intuition.
Explore → Plan → Implement → Verify, and remember you own the result.
Let it run deliberately: auto mode and auto-accept are great, with git as your safety net and your own review as the last step.

Start on something small and low-stakes. Watch the agent closely, interrupt freely, and pay attention to what works. The feel for it comes fast, usually within a few sessions, and it’s worth the investment, because this is how a growing share of software now gets built.

Cheat Sheet

You want to…	Do this
Stop the agent immediately	`Esc`
Undo to an earlier checkpoint	`Esc Esc` on an empty prompt, or `/rewind`
Cycle permission modes (Manual / acceptEdits / plan / auto)	`Shift+Tab`
Pull a file into context	`@path/to/file`
Run a shell command into the conversation	`!command`
Switch model	`/model` (Fable / Opus / Sonnet / Haiku)
Adjust reasoning effort	`/effort`, or `ultrathink` in a prompt
Toggle fast mode	`/fast`
Check plan usage / limits	`/usage`
See what’s filling the window	`/context`
Reset context for a new task	`/clear`
Summarize context on purpose	`/compact <focus>`
Ask a side question without polluting context	`/btw <question>`
Generate a starting `CLAUDE.md`	`/init`
View / edit memory and `CLAUDE.md`	`/memory`
Review your changes	`/code-review`, `/simplify`, `/security-review`