Claude Code can generate a usage report on your own sessions. It calls it Insights. Mine covered 16 July to 10 September 2026, and it's the closest thing I have to an outside view of how I actually work, as opposed to how I'd describe it. So here it is, with my notes. A few project names and one anecdote are redacted, for the same reasons the rest of this site keeps them private.
The numbers
Over those eight weeks: 855 messages across 53 sessions, 262 hours of session time on 24 active days, 195 commits, 906 files touched, and about 88,000 lines added against 3,600 removed. The tool mix tells you most of the story: 4,699 shell commands, 1,674 edits, 560 new files written, 547 reads, and 235 subagent launches.
The language breakdown surprised me more than anything else. Markdown came first, with 1,053 file touches, ahead of TypeScript (782), Python (280) and Rust (177). I write more documentation than code, or more precisely, the documentation is where the work gets specified and the agents turn it into code. That's the argument in your documentation is source code now, and here it is showing up in someone else's measurement.
"Prompt-and-release"
This is the line from the report I'd most want a builder to read:
You operate in prompt-and-release mode: most sessions begin with a substantial, pre-written brief (a PRD, a roadmap doc, a handoff file, an "execute this prompt" pointer) and then you step back and let Claude run for hours. With 855 messages across 262 hours, that's roughly one message every twenty minutes; you're not steering turn-by-turn, you're commissioning work.
That's accurate, and it's the whole trick. The brief is the work. When a session goes well, it's because the roadmap, the sprint doc and the handoff file gave the agent rails to run on for hours. When it goes badly, it's usually because the brief was ambiguous and I didn't find out until hours later.
The report also noticed where I step in. I don't steer turn by turn; I correct factual drift, supply missing context, and keep deployment for myself. In its words, the agent "ships to the commit boundary while you keep deployment." That line is on purpose. It's the same rule LEGION runs on: observe freely, change with a flag, destroy never.
What it credits
Three things, and all three are about verification rather than cleverness:
- Long unattended runs. One was an explicit five-hour unattended stretch on the interactive fiction engine that landed four commits and passed its full gate and probe batteries.
- Parallel agents at scale. One remediation session ran seven waves of subagents, landed 57 commits, and grew a test suite from 82 to 279 tests. A parallel review pass on a revived audio project surfaced two showstopper signal-processing bugs.
- Gates before commits. "You consistently demand empirical proof rather than 'it should work'": eval batteries, emulator runs, green CI. That's the habit I'd defend hardest. An agent will tell you it's done. The gate tells you whether it is.
By the report's own estimate, 49 of 50 assessed sessions fully or mostly achieved what they set out to do (17 fully, 32 mostly, 1 partially). Treat that as the model grading itself on my transcripts, not as an audited number. I do.
Where it goes wrong
This is the more useful section, and the report doesn't soften it.
The biggest single cost was self-inflicted: 51 instances of buggy code, mostly shell scripts where heredoc quoting and escaping mangled files and forced rewrites. Next came configuration fights. A permission fix covered one settings surface and missed the VS Code extension's, so supposedly autonomous runs kept stopping to ask. Then drift: a detached eval job that died at launch with its output thrown away, a background agent that stalled until I asked whether it had frozen, and one run that started "Phase 9" when I meant a differently named set of waves in another document.
None of these are model-intelligence problems. They're harness problems: how scripts get written, how settings are enforced, how a long run proves it's still alive, how a brief names its target.
What I changed
The report suggested five rules for my global instructions file. I adopted two of them word for word. Every session I run now starts with:
Never use heredocs (
<<EOF) to write files or patches from Bash. Use the Write tool for any multi-line file content, then execute it.
and
When launching detached eval/build jobs, always write stdout+stderr to an absolute log path, echo the PID and log path, and verify the process is alive after 30s before starting to monitor.
Did the heredoc rule end heredoc bugs? No. On 21 September an agent used a heredoc three times in one afternoon, apologising each time. Knowing the rule didn't change the behaviour. So the rule moved into the tooling: a small hook now checks every shell command before it runs and refuses any heredoc. That story is a rule it can argue with. A rule in a prompt is a request. A rule in the tooling is a wall. (It still works. While I was checking the quotes for this article, the hook blocked a search command because the search text contained the forbidden syntax.)
What it recommends next
Its "on the horizon" section describes closed-loop autonomy: a machine-checkable gate battery every wave must pass before committing, automatic rollback and retry, a defect ledger for what couldn't be fixed, and fleets of agents in isolated worktrees with an integrator that verifies their claims against the actual git log instead of trusting their summaries. Parts of that are already how I work: status is derived, not reported, and nothing ships without a gate. Parts aren't yet. The one I'll steal first is the last one. Subagents do report stale tallies and wrong commit counts. Verify the artifact, not the report.
Caveats
The outcome and satisfaction judgments are the report's own model estimates. Its time-of-day chart labels my hours Pacific; I'm on Mountain time. It stops on 10 September, so it misses the weeks since, which include this site. I'll run it again in a few months and give that one the same treatment.