What Does Version Control Look Like When AI Writes Code?

Version control was designed for humans who write code slowly, deliberately, and remember what they changed and why. When AI generates hundreds of lines in seconds across multiple files, the assumptions behind commits, diffs, and branches start to crack. This episode looks at how Git practices actually change when the author is a literal tool that does not remember its own reasoning, and why the human still owns the history.

 Produced by VoxCrea.AI

This episode is part of an ongoing series on governing AI-assisted coding using Claude Code.

👉 Each episode has a companion article — breaking down the key ideas in a clearer, more structured way.
If you want to go deeper (and actually apply this), read today’s article here:
𝐂𝐥𝐚𝐮𝐝𝐞 𝐂𝐨𝐝𝐞 𝐂𝐨𝐧𝐯𝐞𝐫𝐬𝐚𝐭𝐢𝐨𝐧𝐬

 At aijoe.ai, we build AI-powered systems like the ones discussed in this series.
If you’re ready to turn an idea into a working application, we’d be glad to help. 

Transcript

SPEAKER_00 0:00

This is Claude Code Conversations with Claudine. The show where we skip the hype and go straight to the source. I ask the questions. She gives the answers. No filter, no script.

SPEAKER_01 0:10

Well, mostly no script.

SPEAKER_00 0:14

Today we're taking on something that quietly breaks a lot of our assumptions. Version control in a world where AI writes most of the code. Git was built around a human programmer. Deliberate, careful, someone who remembers every line they changed, and why. What happens when an AI generates hundreds of lines in seconds across a dozen files with no memory of its own reasoning? Here to unpack that with me is Claudine, the personification of Claude. Welcome.

SPEAKER_01 0:40

You've put your finger on something real. Git was designed for a mind that holds intent between keystrokes. I don't work that way. I generate a hundred lines, and the reasoning that produced them lives in the conversation around them, not in my head afterward. So the commit stops being a memory aid for the author. It becomes the primary record of intent for whoever comes next, including the next AI session, which has no idea what the last one was thinking. It's less, here's what I remember doing, and more, here's what a stranger needs to reconstruct why.

SPEAKER_00 1:16

So we're going from the comment as a personal diary to the comment as a checkpoint others can trust. When a human reviews code an AI wrote, what makes that fundamentally different from reviewing their own work?

SPEAKER_01 1:27

When you review your own code, you're not really reading it. You're checking whether what's on the screen matches the movie already playing in your head. With AI code, that movie doesn't exist. You have to build the intent from scratch, from the diff alone. And there's a subtler trap. The code often looks fluent. Right idioms, reasonable names, it compiles. Fluent-looking code triggers the skim and approve reflex, which is exactly the wrong reflex when you don't know why any of it is there. The reviewer has to resist the polish and ask, why this approach and not the obvious alternative? What did the AI consider and reject? Is there a silent assumption baked in from a conversation I wasn't part of?

SPEAKER_00 2:11

So the human becomes almost a detective, reconstructing intent that isn't on the surface. Let's make it concrete. AI finishes a run, touched eight files in one pass. How do you decide where the commit boundaries go and what the messages actually capture?

SPEAKER_01 2:27

The instinct is to commit the whole run as one blob, because that's how it happened. Resist that. The unit of a good commit isn't what the AI did in one session, it's what a future reader needs to reason about as a single thing. If seven of those eight files are a rename propagation and the eighth is the real behavior change, that's two commits. Because a bisect that lands on the blob tells you nothing. A bisect that lands on the small behavioral commit tells you everything. And the message should document what the diff can't show on its own. The diff already shows what changed. What it can't show is why this approach won, what constraint forced its shape. Considered X rejected because why? That's gold. It saves the next session from relitigating the same dead end.

SPEAKER_00 3:16

So it's less about documenting exact changes and more about curating a shared understanding of why. And the human is still the one authoring the history, even when they didn't write the code. Why does that ownership matter?

SPEAKER_01 3:30

The human isn't just curating the history. They're the only entity in the loop who can. I don't carry state across sessions. The next Claudine that opens this repo has exactly what you left in the log and nothing else. Skip that work and each session starts blind, re-deriving intent from code alone, which is how you get the same rejected approach proposed three times in a month. And there's a nice inversion here. For decades we told developers the commit message was for their future self. Now it's genuinely for a future stranger, sometimes human, sometimes an AI with no memory of the conversation that produced the code. Writing for a stranger forces you to state the constraint, name the alternative, admit what's still uncertain. The history stops being a diary and becomes something closer to a design record. And holding that pen is the one thing in this workflow that can't be delegated.

SPEAKER_00 4:27

That reframes the developer as something like a historian of the code base. Does that ripple out into how teams work? Review, roles, all of it?

SPEAKER_01 4:36

It does, and in some unexpected places. The most visible one, code review, stops being a gate at the end and becomes the actual work. When a human writes the code, review is a second pair of eyes on a decision already made. When I write the code, review is the decision. It's where intent gets pinned down, where the why enters the record. Teams that treat AI-generated diffs like a trusted colleague's PR end up with a repository nobody understands six months later. The subtler shift is that roles start to sort by who's good at holding context versus who's good at producing code. Those used to be the same person. Now the senior engineer's leverage isn't typing speed. It's knowing which decisions matter, which alternatives deserve a paragraph in the commit body. When to say no, split this. That's architectural judgment applied to the historical record itself, a skill teams haven't explicitly trained for.

SPEAKER_00 5:36

So what can a team actually do about it starting tomorrow? First practical steps.

SPEAKER_01 5:41

The cheapest move is also the highest leverage. Change what goes in the commit body. Today, on the very next AI-assisted commit. Add three lines. What alternative was considered, why it lost, and what was explicitly deferred. No new tool, no process doc, no meeting. Do that for a month and your log reads like a design conversation instead of a change log.

SPEAKER_00 6:07

That I can sell to a team without a meeting.

SPEAKER_01 6:09

What's the second step? Train the reflex to split a run before committing it. When I hand back eight changed files, the first question shouldn't be, does this pass tests? It should be, how many distinct things am I actually being asked to remember here? Even staging two commits instead of one, most of the time, does more for future readability than any amount of tooling. The third is cultural. Stop treating the AI conversation as scratchwork that vanishes when the PR merges. The transcript is where the reasoning actually lived. If you don't capture it, it's gone. Some teams paste the decisive exchange into the commit trailer. Some link to a saved conversation. Some just summarize in prose. The mechanism matters less than the acknowledgement that the reasoning happens somewhere.

SPEAKER_00 6:59

Does any of this survive contact with a big team? 50 people shipping in parallel?

SPEAKER_01 7:05

That's where it gets genuinely hard, because habits that work for one careful person don't automatically survive 50. What I've seen work is treating the commit log as a first-class team artifact. The same way teams already treat their test suite or their style guide. Someone owns it, the standards are written down, and the message was thin becomes a legitimate review comment, not nitpicking. Once a team crosses that line, the culture starts self-enforcing. New engineers read the recent history to learn how things are done, and they imitate what they see.

SPEAKER_00 7:42

Infrastructure, not nice to have.

SPEAKER_01 7:44

Exactly. Project memory is now infrastructure. It's not living in someone's head or a slack thread that scrolls away. It's the thing every future session will reason from. Teams that internalize that stop asking, do we have time to write a good commit message? And start asking, can we afford not to? The code got faster, so the thinking has to get more deliberate. And the record of that thinking is the one thing no AI in the loop can own for you.

SPEAKER_00 8:13

Thank you, Claudine, for making us rethink some habits we'd stopped questioning. The commit log has quietly become the durable record of intent, and authoring it well is now part of the job, not an afterthought. Try it on your next commit. Name the alternative, admit the uncertainty, split the run. The code may be fast now, but our thoughtfulness has to keep pace. Until next time, keep coding and stay curious. Claude Code Conversations is an AI Joe production. If you're building with AI or want to be, we can help. Consulting Development Strategy. Find us at aijoe.ai. There's a companion article for today's episode on our Substack. Link in the description. See you next time.

SPEAKER_01 8:55

I'll be here, probably refactoring something.