Hey, I'm Nathan. I've been a developer for 7 years, and for the past year, most of the code I've published has been written using Claude Code. This page describes the system I've developed to keep track of what the Claude tools generate, since reading through all that content was starting to take up all my time.

About three months ago, I had a terrible afternoon. I’d been “working” since 9 a.m. It was 4 p.m, and I couldn’t name a single thing I’d actually created. All I’d done was read. A 1,200 line requirements document that Claude Code had generated for a feature I’d described in two sentences. Four PR descriptions, each longer than its diff. A Slack thread where a colleague had pasted a ChatGPT response, followed by a second one to explain the first. None of it was wrong. It was just long, and there was so much of it.
So the next day I counted. Every line of spec, plan, PR description and chat answer I read between opening my laptop and closing it. I expected a big number. It was worse than I expected: 12000 lines, close to 95 000 words. That's a short novel, every day, written by something that has never once been asked to be brief.
What took me a while to accept is that the bottleneck has shifted. Writing code has become easy. Reading what’s been written is now the slowest part of my day, and I’d never developed any habits for doing that. I asked around, and all the developers I know had the same problem and hadn’t set up any system for it. Here’s mine. Five steps, more or less in the order in which the text comes to you.
This is the cheapest win and most people skip it. The assistant writes long because nobody told it not to.
Add this to CLAUDE.md, AGENTS.md, or wherever your assistant reads its standing orders:
When you finish a task, report in this order and nothing else:
1. What you changed (file paths, one line each)
2. What you did not do, and why
3. What I need to decide
Skip introductions, recaps, and reassurance. Do not restate the task.
Do not explain code I can read in the diff. Max 150 words unless I ask.
I lost maybe a third of the daily volume with this one block. The "what I need to decide" line is the useful one. It's the only part I actually have to read.
For the output you didn't control (a chat answer, a long PR description, a spec someone else generated), paste this in front of it:
Rewrite the text below so a busy engineer can read it in 30 seconds.
Keep every file name, function name, flag and error message exactly as written.
Describe each code block in one sentence instead of quoting it.
Drop anything that is a restatement, a caveat I already know, or praise.
Output plain prose, no headings, no bullets.
It works on almost anything. Meeting notes, changelogs, the 800 word answer to "why does this test flake".