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, every day, 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 very confident about.

The difference is rarely the model. It is the structure around it: what the agent knows about your project, what it is and is not allowed to do, and how you run the session. That is also 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. If you read one post from this cluster, read that one.

Memory comes right after. Every session starts from zero unless you fix that yourself. The CLAUDE.md file explains how to make project context permanent: your stack, your conventions, the traps the agent would otherwise rediscover every session. And maintain that file. A rule that no longer holds will steer your agent in the wrong direction with total confidence.

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: deterministic control over what an agent executes, instead of hoping it listens.

Claude Code now ships a sizeable toolbox: skills, subagents, hooks, slash commands, and variants in between. Which one you reach for genuinely matters. The decision guide builds the same task four ways and shows where each mechanism wins. And once you start writing your own skills, a good skill is a procedure that builds distrust of the model into itself, with checkpoints where things tend to go wrong.

The working method ​

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

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

Where this touches quality ​

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

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