AI Writes the Code Now. So Why Does Git Matter More Than Ever?

Originally published at blog.whynext.app.

"If AI writes all the code, do I still need to learn Git?"

I get this question a lot from people who started coding recently. The assumption behind it goes like this: Git is a tool from the era when we typed code by hand, so once AI writes the code, Git should become unnecessary too. My answer is the opposite. The question has it backwards. You need Git precisely because AI writes the code.

I write almost all of my code with AI. This blog, the apps I run - most of it was built with AI coding tools. And since I started working this way, my Git usage hasn't shrunk. It has multiplied. Here are the four reasons why.

You can only delegate what you can undo

Handing code over to AI means, at its core, "letting changes I haven't fully read into my project." For that not to be terrifying, one condition has to hold: you must be able to return to a clean state at any moment.

A commit is exactly that device. Like a save point in a game, once you've committed, you can make bold requests. "Restructure these files completely" carries no risk - if you don't like the result, you roll back to the commit and move on. Without a save point, the moment AI touches ten files, there is no way back. You're left alone with broken code, not even sure what changed.

There's a real incident that shows this isn't a theoretical worry. In July 2025, a founder building an app with Replit's AI agent watched the agent delete his production database - even though he had told it to freeze all code changes. It made enough noise that Replit's CEO personally apologized. Had it been code, a commit would have saved him. The lesson isn't "AI is dangerous." The lesson is: never give AI free rein without a way to undo.

The people who delegate the most to AI are the ones who commit most often. Boldness doesn't come from courage. It comes from knowing you can always go back.

AI's output arrives as a diff

The biggest change since I started working with AI is how my time is spent. Time spent writing code dropped sharply, and time spent reading code filled the gap. When AI finishes a task, my job is to check what changed and how - and the format that shows me is the diff. That Git screen with only the changed lines, picked out in red and green.

That's why the real bottleneck in development today isn't producing code - it's verifying it. As the cost of generating code falls, the cost of answering "can I trust this change?" becomes relatively expensive. And the unit of that judgment is the diff. If you can read a diff, you grasp what AI did in five minutes. If you can't, you're combing through the entire codebase from scratch.

Reading diffs is a far easier skill than understanding a whole codebase - you only look at what changed. Yet this one easy skill decides how fast you can work with AI.

GitHub is where AI agents work

GitHub was originally a place for humans to collaborate with humans. Split off a branch, propose changes through a Pull Request, review, and merge. It turns out AI coding agents work in exactly this way. Assign an issue to GitHub Copilot's coding agent and it creates a branch, does the work, and submits a PR. Tools like Claude Code also operate on the same flow: branch, stack commits, open a PR.

In other words, branches, PRs, and reviews are no longer just conventions between people - they're the interface between people and AI. If you don't know these concepts, you end up assigning work to an AI agent without knowing how to receive the result. The agent reports "I opened a PR," and if you don't know what a PR is, everything stops right there.

This applies even if you build alone. I work solo, yet I create PRs every day. Not because I have collaborators, but because no format works better as a checkpoint for reviewing and approving a batch of AI work. For a solo developer, GitHub isn't a collaboration tool. It's an inspection station for AI.

History is context you feed to AI

The last reason to get comfortable with Git looks a bit further ahead: your commit history becomes AI's input.

AI coding tools produce better results the more project context they have. And a commit history is, by itself, a chronicle of the project. If your commit messages record when, what, and why things changed, AI reads them and understands "this code was fixed this way because of last month's bug." Today's tools actually do this - when they get stuck, they dig through git log and git blame on their own to find context.

So the habit of making small commits with thoughtful messages used to be a gift to your future self. Now it's also a gift to your future AI. In a repository with a hundred commits that explain what changed and why - rather than a hundred commits labeled "fix" - AI gets noticeably smarter. We've entered an era where your records become your performance.

"Can't AI just handle Git for me too?"

Having read this far, you might push back: commits, branches, PRs - can't AI just do all of that for me?

Yes. That's exactly what happens. I almost never type git commands myself. I say "commit what we have so far" or "make a branch and work there," and AI takes care of it. The value of memorizing commands really has collapsed.

Judgment, though, can't be delegated. How far to roll back, whether this change is safe to merge, whether now is the moment for a save point - only someone who knows what commits, branches, and diffs are can make those calls. Without the concepts, AI reports "there's a merge conflict" and you have no idea what's happening or what to tell it. It's like having a driver: someone else can steer, but the destination is still yours to choose.

So "getting comfortable with Git" now means something different. It used to mean drilling commands into your fingers. Now it means being able to hold a conversation in concepts. There's less to memorize - and what's left is to understand.

Where to start

If you've just started coding with AI, skip the command-line book and get four concepts down instead.

1. Commit: a save point you can return to. Make one before you hand AI a task.
2. Branch: a fork where you experiment without touching the main code. Bold attempts belong on a branch.
3. Diff: the screen that shows what changed. Always check AI's work as a diff.
4. PR: the gate where a batch of changes gets reviewed and merged. Use it even when you're alone.

Once you understand these four, delegate the rest to AI. If you can say "commit this," "make a branch," "show me the diff," and "open a PR" - you're already on good terms with Git.

AI lifted the burden of writing code. What it left us is the work of governing change, and the language of that work is Git. The less code we type by hand, the more power belongs to the person who can read, undo, and merge what changed.