Chapter 3: Git for the Agentic Age

Rich Hickey asked how we factor programs so that when we look at any given part, we can understand it. That question matters more now than when he asked it in 2011, because the volume of code we produce has increased by an order of magnitude and the source of that code has become ambiguous.

A New Kind of Commit

commit 7f8a9b2c1e4d6f9a2b5a8c1f4d7a0b3c6e9f2a5c
Author: j@joshuaayson.com
Co-authored-by: Claude <noreply@anthropic.com>
Date: Tue Oct 15 14:32:18 2024 -0700

    Add content processing pipeline with graph database integration

    Claude designed the Neo4j relationship schema and implemented
    the core ETL logic. I refined the error handling and optimized
    for our specific content structure.

    Generated with Claude Code

This commit message tells a story that would have been impossible five years ago. Not just code. A record of collaboration between a human and something that is not human. Neither could have produced this alone.

Two of the terms in that message deserve a plain-words pass. Neo4j is a graph database: it stores content as a web of relationships instead of rows in tables. ETL, extract-transform-load, is the unglamorous plumbing that moves data from one system into another. Both will come up again.

Git was built for human-paced development. Linus Torvalds created it in 2005 out of frustration with existing version control. “I’m an egotistical bastard, and I name all my projects after myself. First Linux, now git.” But beneath the humor was serious intent: a distributed system that could handle the Linux kernel’s development pace.

AI changes these assumptions. When your pair programming partner can generate a thousand lines of tested code in thirty seconds, when experimentation costs approach zero, when you can explore dozens of architectural approaches in the time it used to take to implement one, your version control strategy needs to evolve. The boundary between human and machine contributions has moved past blurry into irrelevant. What matters is building software that works, with a history that tells the truth about how it came to be.

Semantic History

The fundamental unit of Git is the commit. What should a commit represent when AI can generate substantial changes in seconds?

Classic Git philosophy says commits should be logical units of change. One feature, one commit. Atomic, revertable, with messages that explain the why. Alan Perlis advocated in 1958 that every program should be a structured presentation of an algorithm. Version control extended this principle to the evolution of programs. But this model assumes human speeds and human cognitive limitations.

What used to take from 10 AM to 5 PM now happens between 10:00 and 10:25. You describe the feature to AI. Review the generated implementation. Refine edge cases. Verify tests. Done. The same logical unit of work, ten times faster.

Should this be one commit or five? That depends on what story you want your history to tell.

Organize around semantic intentions rather than time. Intent commits capture the human decision-making process: what authentication approach, how long sessions last, which features now versus later, where to store sensitive data. Implementation commits capture the technical execution, all co-authored, all honest about how the code came to be. Refinement commits capture the iterative process of review and improvement. Human review identified security gaps in the initial AI implementation. The collaboration continues.

This preserves both the human creative process and the technical details. It tells the truth about how modern software actually gets built.

---

You’ve read the opening sections of this chapter. The full chapter (Branches as Hypotheses, Honest Attribution, CI/CD Inverted, The Social Reality, Patterns That Work Now, Where This Goes) continues in the book.