I've been building with AI agents across every project I run — a SaaS product, a book, a company website, internal tools. Thousands of commits. The output is good. But the git history doesn't tell you who decided what.

My decisions — architectural calls, editorial judgment, the "no, not that, this instead" — are invisible. Buried inside machine commits. The record says AI did the work. That's not what happened.

I noticed when I thought about making the history public. For the book I'm writing, I wanted the commit log to show craftsmanship — 200+ commits of editorial decisions, structural rewrites, revision passes. When I looked, my voice wasn't in the record.

So I'm changing how I work. Starting now.

The Problem

The output doesn't carry fingerprints. A clean chapter reads the same whether a human wrote it or an AI generated it under tight constraints. A well-structured controller doesn't tell you who made the architectural decision. The finished work is what ships. The commit log is what's true.

Amazon just learned this the hard way. After a string of outages — including six hours where users couldn't check out or view prices — they traced the cause to "Gen-AI assisted changes" with "high blast radius." The fix: senior engineer sign-off on all AI-assisted code. "Controlled friction" because "best practices and safeguards are not yet fully established."

That's a commit discipline problem. If the history clearly showed which changes were AI-assisted and which were human-reviewed — with reasoning attached — you wouldn't need a new approval policy. The log would already tell you what was decided by whom and why.

As the collaboration model scales — multiple agents, multiple humans, same repo — the commit log becomes the only record of who contributed what. Without clear attribution, you can't debug the process. When things break, you can't trace the decision that caused it.

The Discipline

Two voices in one log. Human commits and machine commits, separated intentionally.

When I edit by hand — rewriting, restructuring, making a judgment call — that's my commit. My message. No co-author tag.

Foreword: rewrite personal section — real stakes, not a resume

When an agent executes work I directed, it gets the tag.

Craft pass: thought verb cleanup across Part III — 12 instances

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Every message follows: [scope]: [decision] — [reason]. "Updated files" is dead. If you can't explain the decision in one line, you haven't made the decision yet.

This is new. The format will evolve. I'll be tracking that evolution too.

Enforcing It With Tooling

I open-sourced Twain this week — a config-driven test runner for written content. Define quality rules, point it at your writing, get pass/fail. Built it for a book manuscript, but the architecture works on anything.

Twain applies at every scale of writing I produce:

Short form — commit messages. Audit the git log. Flag vague messages. Flag missing scope. Flag commits that mix human and machine authorship.

Medium form — blog posts and docs. Customer documentation flags technical jargon. Blog posts enforce voice consistency. Help articles require step-by-step structure. Different rules, same runner.

Long form — the manuscript. 24 chapters checked against a style guide, an outline with acceptance criteria, a story tracker with usage limits, and eight thematic threads. Craft rules catch anti-patterns. Semantic search will check whether chapters actually cover what the spec says they should.

One tool. Different configs. Define what "good" looks like, enforce it automatically, keep human attention on the things only a human can judge.

Git Beyond Code

Most people think of git as a software tool. It's a collaboration ledger.

My book is markdown in a git repo. Research documents, specs, style guides, project plans — all in git. Anything text-based that evolves and benefits from line-level change history.

git diff v1..v2 on a manuscript shows every editorial decision between drafts. That's the creative process made visible. As more work moves into structured text — and AI makes that natural — git becomes the record layer for everything.

The history accumulates whether you think about it or not. The question is whether it tells the truth.

Where This Goes

The discipline is new. The tooling is v0.1. The format will change as I learn what actually matters in the log.

But the direction is clear: as humans and agents collaborate on the same artifacts, the process record becomes as important as the output. The commit log is that record. Making it accurate, attributing it honestly, enforcing quality on it — that's the work I'm starting now.

The output is what ships. The history is what's true.