A few weeks ago, I argued that AI is not a great equalizer — it's a great amplifier. It amplifies what developers already are, for better and for worse. Juniors with AI produce junior code at senior speed. Seniors with AI produce senior code at supernatural speed.
This post is about where that amplification becomes visible: your Git history.
Every team that's adopted AI coding assistants — Claude Code, Cursor, GitHub Copilot, Windsurf — has introduced a new kind of contributor to their repo. Sometimes it's tagged explicitly (co-authored-by: claude). Sometimes it's invisible. Either way, the commits AI produces (or AI-assisted developers produce) look different, and Git reveals the difference within weeks.
Here's what to watch for, and why the fundamentals of Git practice matter more now than ever.
The two kinds of AI-assisted commits
Open any repository that's been using AI assistance for a few months and run this:
git log --oneline --since="3 months ago" | head -50
You'll see two patterns emerge.
Pattern A — the junior-amplified commit:
a7f3c21 fix stuff
9e2b8f4 more changes
12a4e5c update
8d1f90b fix tests
f5a23de wip
Large commits, vague messages, no clear scope. The developer asked AI "fix this bug" and committed whatever AI produced. A month later, nobody knows what any of these commits actually do.
Pattern B — the senior-amplified commit:
a7f3c21 feat(search): add cursor-based pagination for users endpoint
9e2b8f4 perf(search): replace LIKE '%q%' with full-text index
12a4e5c test(search): add edge cases for empty query and unicode input
8d1f90b refactor(search): extract query builder into reusable module
f5a23de chore(deps): upgrade full-text-search-lib to 2.3.1
Small, atomic, well-described commits. The developer guided AI to produce focused changes, committed each unit separately, and wrote messages a future debugger will thank them for.
Same AI. Same prompts, roughly. Radically different commit history.
Why this matters
A Git history full of Pattern A commits is a Git history that can't be bisected, can't be reverted cleanly, can't be understood by anyone who joins the team later. Every tool that relies on commit granularity — git bisect, git revert, git blame, git log --follow — degrades to the point of uselessness.
Before AI, bad commits came from rushed developers. They were relatively rare because writing bad commits took effort too — a huge "fix stuff" commit still required the developer to write the code. Now, bad commits are effortless. AI produces working code fast, and if the developer doesn't pause to structure the commits, everything lands as one undifferentiated blob.
This is the amplification effect in its purest form: AI doesn't cause bad commit practice, but it removes the friction that used to limit how many bad commits a team could produce per day.
What senior AI-assisted developers do differently
If you've worked with a senior developer using Claude Code or Cursor for real production work, you'll notice they don't work the way demos suggest. Demos show a developer asking AI to build a feature, accepting the output, committing, done. Senior developers rarely work that way.
What they actually do:
They break work into commits before writing a single line. Before prompting AI, they think: "This feature needs three commits — the refactor, the new endpoint, the tests. I'll work on one at a time." Then they prompt AI per-commit, not per-feature.
They review AI output for what it didn't do. AI produces code that answers the prompt. It doesn't answer the things you didn't ask about. Seniors read AI output asking "what edge case is missing? what error isn't handled? what happens at scale?" — and iterate until the output is actually ready.
They rewrite commit messages by hand. Even when tools offer auto-generated messages, seniors rewrite them. Because the message needs to explain why, not what — and AI can see what changed but not why it was the right change.
They separate refactors from features. A change that both refactors existing code and adds a new feature is a bisect nightmare. Seniors do the refactor, commit it, verify nothing broke, then add the feature as a separate commit.
None of this is specific to AI. These are basic fundamentals of Git hygiene. AI just made them dramatically more important, because AI makes it easier to skip them.
What Git reveals, three months in
Run these queries on any team that's been using AI assistance for a while, and the amplification effect becomes quantifiable:
Commits per PR — the concentration test:
# How many commits does each PR typically have?
gh pr list --state merged --limit 100 --json commits \
--jq '.[] | .commits | length' | sort | uniq -c | sort -rn
A healthy team, AI-assisted or not, has most PRs with 2-6 commits. If suddenly your team has half of PRs with 1 commit of 500+ lines, that's the junior-amplified pattern.
Commit message quality — the scoping test:
# Average commit message length
git log --since="3 months ago" --pretty=%s \
| awk '{ sum += length($0); count++ } END { print "avg length:", sum/count, "chars" }'
Teams writing good commit messages average 50-80 characters on the subject line. Teams that rubber-stamp AI's first suggestion average 20-30. If your team dropped to the lower range after adopting AI, it's a signal.
Changed files per commit — the atomicity test:
# How many files does each commit touch on average?
git log --since="3 months ago" --name-only --pretty=format:'---' \
| awk '/^---$/ { if (count > 0) print count; count = 0; next } { count++ } END { if (count > 0) print count }' \
| awk '{ sum += $1; n++ } END { print "avg files per commit:", sum/n }'
Atomic commits touch 1-5 files. If your average jumped to 15+ after AI adoption, commits are no longer scoped to individual changes.
These aren't vanity metrics. Each one directly correlates with how debuggable, revertable, and understandable your codebase is.
Three practical habits that preserve commit quality
If you want your team to use AI without destroying your Git history:
1. Commit before asking AI to do the next thing. Treat each AI interaction as one logical unit of work. If the unit spans multiple concerns, the unit is too big — break it down first, commit as you go.
2. Write the commit message yourself. Tools that auto-generate messages from diffs are convenient, but they miss the "why." Spend 30 seconds writing the message in your own words. Future you will save hours.
3. Review the diff before committing, even if AI wrote it. Seniors do this automatically. It's the equivalent of proofreading a translation — AI translated intent to code, you verify the translation matches what you meant. Unreviewed commits are a liability, AI-generated or not.
A small convention that helps
Some teams have adopted a tag in commit messages to mark AI assistance explicitly:
feat(auth): add SAML SSO provider [ai-assisted]
Implemented SAML 2.0 response parsing using python-saml library.
Generated test cases for malformed responses and signature
validation failures.
AI helped with: SAML library integration, test generation
Human decisions: auth flow design, error handling strategy
This is optional and your team may or may not want it. But it makes two things explicit: that AI was involved, and what specifically the human brought to the table. When a bug surfaces months later and someone git blames the line, they can see immediately whether the code was AI-generated and what context the human applied.
It's not a defensive measure ("don't blame me, AI wrote it"). It's an informational one ("here's the context you need to understand this change").
The quiet thing seniors know
If you've been using AI assistants seriously for a year, you've probably noticed something that doesn't make the headlines: you're more careful about commit hygiene now than you were before.
Pre-AI, if you wrote sloppy commits, you paid the cost linearly. You produced maybe 5-10 commits a day, so sloppy habits had bounded blast radius. Post-AI, you produce 30-50 commits a day. Sloppy habits destroy the codebase in a quarter.
The seniors who thrive in this new environment aren't the ones using AI the hardest. They're the ones who realized early that AI's productivity gain has to be matched by increased discipline elsewhere. Every minute saved by AI in writing code gets spent in structuring, reviewing, and documenting that code.
That's the amplifier in action. Use it well, and your output multiplies. Use it carelessly, and your technical debt multiplies just as fast.
This post is part of a series on AI and engineering fundamentals. My book Git in Depth is 658 pages on the Git fundamentals that AI assumes you already know — including atomic commits, commit message anatomy, and bisect workflows.
Related: Why AI made fundamentals more valuable, not less.
See all my articles on Git and engineering practice: dev.to/mdenda.
