353 Sessions in a Month

Between September 21 and October 22, my work machine ran 353 Claude Code sessions. I went back through the transcripts expecting to learn which kinds of tasks I hand to it. What I learned first was simpler: in about half of those sessions, nobody was at the keyboard.

That ratio turned out to be the most honest description of how I work now, so it's where this series starts.

The month at a glance

Source: my own Claude Code session transcripts on my work machine, Sep 21 – Oct 22, 2026, counting every session with at least one real prompt. Sessions were bucketed by a regex on the first prompt (scheduled = a cron command, headless = a probe pattern), so a few may sit in the wrong row.

Read it from the bottom up. Nearly a third of the volume is Claude checking my own configuration, and a fifth is Claude running on a schedule before I'm awake. Only the remaining half is the thing people picture when they hear "AI coding assistant" — and even there, most of the work isn't writing code.

What the table doesn't show is effort or value. A 184-turn session and a two-line question both count as one. Turn counts are a rough proxy for depth, nothing more.

Who does the work

Claude Code can hand a task to a subagent: a separate model instance with its own instructions and its own tool limits. Mine are defined by role, and counting which roles got spawned says more about my month than any prompt does:

Source: subagent spawns recorded in the same transcripts, same window, top five roles by count.

The agent that actually writes code came fifth. Testing my prompts, reviewing changes and reading production telemetry together outnumber it more than twelve to one. That's not because I write less code; it's because once the change itself is cheap, checking it becomes the job.

A typical day

Before I'm at the desk

The scheduled sessions start at 6am, spaced so none of them overlap. Each one reviews a slice of what happened overnight — new errors, background jobs that failed and got parked, reports that look off against their usual weekday — and writes its findings to one shared status page that keeps the last few days of history. By the time I sit down, the triage is a list to read, not a search to run.

Review batches

A good part of the morning is pull requests: mine, and the ones I've been asked to review. Claude reads each diff through two lenses — line-by-line correctness, and "does this do what the ticket asked" — because those find different bugs. I read its findings, read the diff myself, and decide. I approve a clean PR without comment. Anything with a comment gets drafted, shown to me, and posted only if I say so.

Investigations from a screenshot

The interactive sessions that run long usually start with an image: a screenshot of an error, a chart that looks wrong, a page that rendered strangely. I paste it into a Claude session — over SSH, which is its own story (Clip2Remote, then herdr) — and ask what happened.

This is where it saves me the most time. Answering "what happened" usually touches four systems: the logs, the code as it was deployed (not as it is in my local checkout, which is usually weeks behind), the git history of the lines involved and the ticket behind the change. Claude walks all four in one session and comes back with a timeline. I used to keep those four tabs open and do the joining in my head.

Release safety

Before a release, the question is less "is this code good" and more "what goes out with it." Which changes landed on the release branch, when they landed — not when they were written — and which of them touch something that's hard to undo. That is history archaeology: tedious for a person, and exactly the kind of work a model handles well.

Where it doesn't save time — on purpose

Every write that someone else can see waits for me. Pushing a branch, commenting on a PR, moving a ticket, posting in a channel: Claude drafts it, shows me exactly what will change and where, and stops.

It's also not only a matter of asking nicely. A rule in an instructions file is a request; a hook that refuses the command is enforcement — only as good as the hook's own tests, which is a story for Part 3. By default, my pre-push hook won't let a session push to the main branch at all, even when I'm the one asking. I push that by hand.

The part this series is about

None of this is a single clever prompt. It's a harness: a global instructions file, about fifty skills and commands, role-specific agents, hooks that block what instructions can only discourage and a memory that's tracked in git. The core of the instructions file is a routing table — match the situation, read its playbook first:

| Situation                                  | Read / run first               |
|--------------------------------------------|--------------------------------|
| Bug, test failure or unexpected behavior   | systematic-debugging           |
| About to claim done / fixed / passing      | verification-before-completion |
| Editing a skill, command, agent or prompt  | probe-changes                  |
| Writing to live state (DB, env, config)    | guarded-writes                 |
| Reviewing a diff, branch or plan           | /review-changes                |
| Answering a question about existing code   | /investigate                   |
| Building a feature with no plan yet        | /create-plan → /implement      |

Source: an excerpt from my global Claude Code instructions file, trimmed to seven of its rows and shortened.

The table tells a fresh session which procedure governs the work in front of it. Most of what follows in this series is the story of how each row got there — usually because something went wrong without it.

Next up is the third row of that first table: the 103 sessions where Claude was testing my own instructions, and why re-reading a prompt you just wrote tells you almost nothing.