Why Traditional Git Workflows Need Adaptation

The pace change

Traditional git workflows assume human typing speed. A developer writes code, tests it, stages changes, writes a commit message, and pushes. The process takes minutes to hours per commit. Teams designed branching strategies, review processes, and merge policies around this cadence.

Agentic development breaks these assumptions. Agents generate code fast enough that minute-by-minute commits become practical. A 2025 Jellyfish study found teams with extensive agent use create 98% more pull requests per developer. Individual developers touch 47% more PRs per day. Industry estimates put agent-generated code at roughly 41% of commits Google reports 25% of its new code is now agent-assisted.

This isn't just more of the same. The pace strains workflows designed for slower throughput.

From typing to directing

The workflow shift isn't about typing faster. It's about changing what the developer does.

In traditional development, you type code. Git tracks what you typed. Commits represent logical units of your typing. You are the author; git is the record.

In agentic development, you direct agents. Git tracks what agents generated under your direction. Commits represent checkpoints in an iterative generation process. You are the director; the agent is the author; git is the safety net.

This distinction matters. Traditional commits capture "what I did." Agentic commits capture "what I approved." The granularity, frequency, and purpose all change.

Boris Cherny at Anthropic describes the shift: "Give Claude a way to verify its work." Git becomes verification infrastructure. Each commit is a checkpoint where you've validated agent output. Each branch is an isolation boundary for experimental generation. The repository becomes a collaboration space between human judgment and agent capability.

The code churn problem

GitClear analyzed 211 million changed lines of code from 2020 through 2024. The data confirms what practitioners feel: agentic development produces more churn.

Code churn the proportion of new code revised within two weeks doubled from 2021 to 2024. In 2020, 3.1% of newly added code required revision within two weeks. By 2024, that number reached 5.7%. Looking at all revisions (not just the two-week window), 7.9% of new code in 2024 was revised, compared to 5.5% in 2020.

Agent-generated code specifically showed 41% higher churn than human-written code.

Three patterns explain the increase.

Agents produce plausible code, not proven code. The code looks right. It compiles. It might even pass initial tests. But it reflects the agent's interpretation of requirements, not verified correctness. Revisions catch the gaps between what was asked and what was generated.

Agents don't refactor. GitClear found that "moved" code lines relocated during refactoring dropped from 24.1% of changes in 2020 to 9.5% in 2024. Agents excel at adding new code. They rarely reorganize existing code for better structure. Technical debt accumulates, requiring later cleanup.

Agents duplicate. Clone and copy-paste code rose during 2021-2024. Duplicate code blocks over five lines increased eightfold in 2024. For the first time in software development history, copied code exceeds refactored code.

The implication for git workflows: expect more commits, more corrections, more iterations. Workflows designed for stable, deliberate changes need adjustment.

Higher velocity, higher error rates

The 2025 CodeRabbit analysis found agent-assisted PRs contain 10.83 issues on average versus 6.45 for human-only PRs. That's 1.7x across all issue types. Logic errors appear 1.75x more often. Security issues 1.57x. Maintainability problems 1.64x.

Higher commit velocity combined with higher error density creates compounding risk. More code enters the repository faster, and more of it contains problems.

Traditional review processes one reviewer, once per PR can't absorb this volume. The 2025 Pullflow report found code review agent adoption grew from 14.8% to 51.4% during 2025. Teams are adding agent review to handle agent-generated code. It's agents all the way down.

Git workflows need to accommodate this. More granular commits enable targeted review. More branches isolate experimental work. More frequent integration catches problems earlier. More checkpoints enable faster rollback.

The goal isn't to slow down generation. It's to structure version control so higher velocity doesn't mean higher risk.

What changes in git practice

The remaining pages in this module cover five areas.

Commit granularity changes because agents generate faster than humans type. Smaller, more frequent commits become practical and necessary. Each commit represents a verified checkpoint rather than a day's work.

Commit messages change because the story differs. Messages describe what was directed and approved, not what was typed. Agent-generated messages need human review before they become permanent history.

Worktrees become essential because parallel agent sessions need isolation. Multiple agents can't share a working directory without clobbering each other's work. Worktrees provide separation without the overhead of full clones.

Branching strategies adapt because experimental generation needs containment. Feature branches become experiment boundaries. Throwaway branches become normal. Integration points become quality gates.

Attribution practices emerge because regulatory requirements expect clarity about agent involvement. Co-authored-by conventions, commit message annotations, and audit trails become workflow concerns.

These aren't optional refinements. They're adaptations to a fundamental change in how code enters repositories.

The productivity paradox

A July 2025 METR study found something uncomfortable: experienced open-source developers using agents were 19% slower completing tasks compared to working without agent assistance. The study tracked 16 developers with an average of 5 years of experience on their repositories across 246 tasks.

Before the study, developers predicted a 24% speedup. After the study, they believed they had achieved a 20% speedup. The actual result: 19% slower.

This perception gap matters for git workflows. Developers feel faster while producing more churn, more errors, and more revision cycles. Subjective speed doesn't equal objective productivity.

Git workflows must support reality, not perception. More commits, more corrections, more iterations. Workflows assuming linear progress don't match how agentic development actually unfolds.

Setting up for success

The foundation is recognizing that agentic development is genuinely different not faster typing, but a different collaboration model that produces different commit patterns.

Effective git workflows for ASD share common characteristics. Frequent commits as checkpoints rather than milestones. Worktrees for isolation rather than coordination. Branches for experimentation, not just features. Reviews that expect higher error density. Attribution that satisfies compliance requirements.

These adaptations don't fight agentic development. They structure it so higher velocity becomes sustainable rather than chaotic.

The next page examines commit granularity: how small should commits be when agents generate the code?