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.

Setup stops being generic once the repository gets big. Scoping an agent to a large codebase covers what decides which instructions load and which files get read in a monorepo, and where the measured line sits between configuring your way out of the problem and buying your way out.

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.

Plugins are part of setup too, and every plugin costs context. Superpowers forces Claude Code to plan and test before it types. The rest is arithmetic: Caveman vs context-mode puts two popular token savers side by side, and the token-saver tax walks part of that advice back once the install itself is counted. That arithmetic has since changed: MCP against a CLI measures what a tool surface costs now that the client defers most of it, and the multiplier you read somewhere probably describes a client you are no longer running. If your agent reaches an OAuth-protected service over MCP, logging in to MCP servers from your shell is the one-liner that also works over SSH.

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.

One agent does not have to do it alone, either. From blind generation to an AI team gives the model roles that argue with each other before a line of code exists. What comes out of a session deserves the same attention as what goes in: stop letting your agents write Markdown weighs the gorgeous HTML output of the moment against what it costs. And if you are building AI into an existing application rather than next to it, AI in your Laravel backend and how I secured Gemini are two worked examples, the second with security as the main subject.

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. A month of those numbers showed where the agent's time actually goes: more of it into the shell and into waiting for me than into the model.

The cheapest lever works while the turn is still running: steering it with Esc, the queue and /btw. Over forty measured runs, an Esc at the first edit of the multi-file task cost nothing extra, and the same correction after the turn cost a median 56% more. 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. And when the session is one a crash took out from under you, recovering it from the transcript on disk is the harder version of that: the file outlives the process, and something other than the client that died has to read it.

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.

I read releases the same way. The best number in Opus 4.8 isn't a benchmark looks for the figure that changes your working day behind the one that made the headline, and the notes from the London talk walk through what Anthropic recently added to Claude Code and which defaults shifted along the way.

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.