Agentic coding

What this guide covers ​

A large part of this blog is about working with coding agents, Claude Code in particular. It is where I watch, daily, what happens when you hand a model real permissions in a real codebase. Sometimes that goes remarkably well. Sometimes you spend the next hour unwinding a refactor the agent was extremely confident about.

The difference is rarely the model. It is the structure around it: what the agent knows about your project, what it may and may not do, and how you run the session. That is the order of this guide.

Start with the setup ​

Default settings are written for the average user, and you are not the average user. Getting the best out of Claude Code is the overview piece: from status line to custom skills, everything that turns a bare CLI into an environment you can work in all day. Read that one first if you read nothing else here.

Memory comes next. Every session starts from zero unless you fix that yourself. The CLAUDE.md file is how you make project context permanent: your stack, your conventions, the traps the agent would otherwise rediscover every morning. Then maintain it, because stale memory is worse than no memory. A rule that no longer holds steers your agent the wrong way with total confidence.

Permissions are the other half of setup, and the docs are thin on them. The permissions guide is what I wish they said, including the day 'default' became 'Manual', when a rename quietly changed what a whole mode meant.

Rules you can enforce ​

Here is the lesson that cost me the most time. Instructions in a prompt are suggestions. The model weighs them and can drop them at any point. When something genuinely must not happen, you want a mechanism that says no regardless of what the model thinks that turn. That is what hooks are for, and why asking your agent nicely is not a control. The same question gets sharper with colleagues involved: what a repo can and cannot enforce across a team works out which parts of a checked-in .claude/ bind everyone on the first clone, and which parts sit there doing nothing until each person accepts a dialog.

The toolbox is sizeable now: skills, subagents, hooks, slash commands and the variants between. Which one you reach for matters. The decision guide builds the same task four ways and shows where each mechanism wins. Then a proper skill and a proper subagent are the two writing guides: both build distrust of the model into the procedure itself, with checkpoints where things tend to go wrong.

The working method ​

Tooling is half the story. The other half is what a session looks like: spec first, context small, verify along the way, review as a hard gate before the merge. Working with agents properly walks that from first thought to merged commit, including the trust boundaries that decide what an agent gets to finish alone.

Two tasks deserve their own treatment. Refactoring legacy code starts with characterization tests, because an agent cannot preserve behaviour nobody has written down. And debugging with an agent splits by who holds the narrowing information, which is usually you.

That discipline feels like overhead until you see what it buys: the difference between an agent that speeds up your work and one that multiplies it, mistakes included.

Keeping a long session honest ​

Two things decay over hours of work, and each has a lever. Plan mode is where you spend the expensive half of the job while it is still refundable, on a plan that now lives as a file on disk instead of a chat message. Context management is the other lever, because the million-token window removed the forcing function rather than the problem. The /doctor command turned into a context audit along the way, which is the shortest look at what your session is actually carrying.

A long session loses one more thing: any sense of how long it has been running. Neither you nor the model can read a clock in a transcript, and timestamps and elapsed time per turn put one back, along with a blunt summary of how much of the afternoon you spent waiting.

Then the recovery levers. Checkpoints and /rewind for the turn that went somewhere you did not want. Git worktrees for when one session stops being enough, which isolate the working tree while everything with teeth stays shared. And cross-session messaging for when two sessions need to know about each other on purpose. When the session you want is one you closed weeks ago, in a directory or a client you no longer remember, searching your agent session history is the lever, since every client keeps a full transcript and can only see its own.

Which model, and how hard it thinks ​

Model choice is a routing decision, not a loyalty test. Which Claude model for which coding task is the split I use, and Opus 5 is here and your effort settings just expired is what changed underneath it. If you want the mechanism rather than the settings, the agent is just a loop is the whole thing in one page.

Where this touches quality ​

The better your setup, the more code comes out of it, and the heavier the question of whether that code should go in. Everything an agent produces passes the same gate as human work: do you understand it, can you explain it, would you maintain it a year from now. That is never ship code you don't understand, and the whole AI and code quality guide under related topics below.

Below are three starting points, followed by everything I have written on this topic, newest first.