A quiet workflow change is solving one of the oldest complaints in software: nobody writes documentation. The irony driving it is hard to ignore. Programmers who refused to write handoff notes for their coworkers are now writing detailed CLAUDE.md and PROJECT.md files for an AI. Mark Dominus noticed the pattern and turned the frustration into a practical technique.
The setup is straightforward. When working with Claude across multiple sessions, Dominus maintains a running handoff document: what was planned, what got done, other pertinent context. One Claude session writes it, the next reads it to get up to speed, then updates it for the session after that. The document exists to serve the AI. It was being thrown away at the end of each project.
The first improvement was obvious in hindsight: stop throwing it away. Copy the file into the repository and commit it. Anyone digging through the codebase later might find it with git grep and learn something useful. Low effort, non-zero value.
The better version came shortly after. Instead of committing the raw running notes, Dominus now asks Claude to write a fresh document at the end of the project. Not notes. A structured, high-level explanation of what problem was being solved and what changes were made. A proper overview written from scratch, then reviewed and committed.
This matters for a few reasons. First, the person doing the writing is not the person who resists writing docs. Claude has no ego investment in skipping documentation. Second, the timing is right: the summary is written at the moment of maximum context, right when the work is complete. Third, the format is intentional. It is not a chat log or a scratch pad. It is written to be read by a future human who knows nothing about the session.
The complaint that sparked this was about programmers documenting for AI but not for each other. The reframe is: that documentation impulse is real, it just needed a path into the repo.
What should you do with this today? At the end of your next Claude session, before you close it, ask Claude to write a structured summary of the problem solved and the changes made. Review it briefly. Commit it alongside your code. The habit costs maybe two minutes. Over time, it builds the kind of project history that teams usually only wish they had.