Last month, Mitchell Hashimoto, the co-founder of HashiCorp, announced he was moving his popular open source Ghostty terminal emulator project away from GitHub. His frustration was clear: service disruptions and painfully slow pull requests had become daily obstacles. In his own words, “This is no longer a place for serious work if it just blocks you out for hours per day, every day.” Hashimoto was careful to defend Git itself, blaming instead the infrastructure wrapped around it—issues, pull requests, and Actions. Yet this incident isn’t an isolated complaint. It’s a symptom of a deeper question: is git unprepared for ai? As AI-generated code floods repositories at unprecedented speed, the version control system designed by Linus Torvalds in 2005 is showing its age.
Sign 1: The Infrastructure Around Git Buckles Under AI-Generated Pull Requests
GitHub runs the world’s largest service built on Git. But in 2025, the platform witnessed a staggering 206% year-over-year growth in AI-generated projects, measured by the use of Bash shell scripts. This surge in automated contributions places enormous strain on GitHub’s infrastructure. Mitchell Hashimoto’s decision to leave GitHub wasn’t a one-off grudge—it reflected a growing sentiment among developers who find their workflows blocked for hours at a time. The problem isn’t Git’s core distributed design, but the centralized services that host repositories and manage pull requests. When AI agents can generate hundreds of PRs in minutes, the queue becomes unmanageable. Human reviewers wait longer, feedback loops stretch, and frustration mounts. This bottleneck is a clear sign that git unprepared for ai: the supporting tools were built for human-paced collaboration, not machine-generated floods.
To illustrate, consider a hypothetical scenario: a development team using GitHub Actions to automatically test PRs. When an AI agent pushes a batch of 50 minor refactor commits, the CI pipeline gets saturated. Meanwhile, a critical human-authored patch sits in line for hours. This imbalance forces teams to choose between blocking AI contributions or risking service degradation. Hashimoto’s move underscores a deeper truth: the ecosystem around Git must evolve, or developers will seek alternatives.
Sign 2: Git’s Stop/Go Model Clashes with the Continuous Flow Demanded by AI Agents
Peco Karayanev, co-founder of DevOps platform Autoptic, puts it bluntly: “Agents are nudging us toward a continuous flow.” Autoptic’s entire user base relies on some form of Git—whether homebrew installations or hosted services like GitLab. Yet Git operations remain fundamentally sequential. Updates, commits, pushes, and merges are strung together in stop/go episodes where a human must hit enter to continue. Karayanev argues that this model won’t hold up once AI agents start getting priority in workflows. Git wasn’t designed for real-time, always-on collaboration. It was built for asynchronous human coordination across time zones.
Imagine an AI agent continuously scanning a repository for security vulnerabilities and automatically patching them. Each patch requires a commit, a push, a pull request, and a merge. If each step requires human approval, the agent’s speed is wasted. Karayanev suggests Git needs to operate in a more continuous mode—enabling automated flows without constant manual pauses. This is another dimension where git unprepared for ai: the version control system lacks native support for agentic, event-driven workflows. Without changes, teams will either bypass Git or create fragile workarounds.
Sign 3: AI-Generated Code Introduces More Bugs That Git’s Review Process Cannot Handle Efficiently
Research from GitClear reveals a troubling statistic: AI-generated code heaps 10.83 issues per pull request, compared to 6.45 for human-written code. That’s a 68% increase in defect density. Git’s pull request and code review mechanisms were designed for a world where humans author code and other humans review it. But with AI agents producing code at scale, the volume of issues multiplies. Reviewers must spend more time filtering false positives, understanding agentic logic, and verifying patches. Git itself offers no tools to categorize or prioritize AI-generated contributions differently from human ones.
Consider a real-world parallel: in open-source projects, maintainers already struggle with review backlog. Now imagine an AI bot contributing hundreds of PRs per day, each with slightly higher defect rates. The Git workflow—branch, commit, PR, review, merge—wasn’t optimized for this density. Teams may resort to merging everything and relying on automated testing later, but that defeats the purpose of version control’s safety net. This mismatch is a third sign that git unprepared for ai: it lacks intelligent filtering or risk-scoring mechanisms to handle the buggier output from AI coders.
Sign 4: Git’s Usability “Sharp Edges” Hinder Integration with AI Agents and Developer Workflows
Scott Chacon, co-founder of GitHub and co-author of Pro Git, admits he still finds Git occasionally flummoxing. He points to “sharp edges” in Git’s porcelain—the user-facing commands—that make it difficult even for experts. Git was built by kernel developers for kernel developers, prioritizing power over polish. Today, AI agents must interact with Git through command-line interfaces or APIs that assume precise, well-structured behavior. A single malformed commit message or a failed rebase can derail an entire agentic pipeline.
You may also enjoy reading: MRI Tech School Program: 17-Month Training with Clinical Externships.
Chacon co-founded GitButler to rethink Git’s porcelain. GitButler uses virtual branching to let developers work on two branches simultaneously, eliminating what many call “rebase hell.” It keeps code synchronized with upstream, reorders commits, and enriches metadata. GitButler received $17 million in venture capital funding last year, signaling strong demand for a more usable Git client. Yet for AI agents, the problem runs deeper. Most agents rely on Git’s raw command set, which assumes human intervention when conflicts arise. If Git’s usability remains a barrier for humans, it’s even worse for autonomous systems that cannot “ask for clarification.” This reinforces the idea that git unprepared for ai: the interface layer needs a redesign that accommodates both human intuition and machine precision.
Sign 5: Git’s Design Assumptions Clash with the Parallelism of AI-Driven Development
Git was created in 2005 by Linus Torvalds and other Linux kernel developers after frustrations with BitKeeper. It was designed to support non-linear development across thousands of parallel branches—but for human contributors working at human speeds. AI agents, by contrast, can spawn hundreds of branches, each making overlapping changes simultaneously. Git’s merge algorithm, while powerful, can produce conflicts that are difficult to resolve automatically, especially when two agents inadvertently modify the same lines. The system assumes a human will step in to resolve conflicts, but in an agentic workflow, that assumption breaks down.
Chacon suggests Git could be run locally, mirrored globally, and managed with clients like GitButler that offer richer branch management. Yet the underlying Git protocol remains unchanged. The distributed model that made Git resilient for open-source collaboration also makes it slow when thousands of agents push updates to the same remote. Karayanev of Autoptic notes that given the volume and magnitude of changes across repositories, Git needs to start operating in a more continuous mode—embracing eventual consistency and automated conflict resolution rather than human-mediated merges. This fifth sign highlights how git unprepared for ai at a fundamental architectural level: its assumptions about human pace and serial intervention no longer hold.
What Does the Future Hold?
These five signs paint a picture of a version control system that, while revolutionary for its time, is now struggling to keep pace with AI-driven development. The solutions are not about abandoning Git. Instead, they involve rethinking the infrastructure, workflow models, usability, and conflict resolution strategies. Tools like GitButler and platforms like Autoptic are pioneering some of these changes. Perhaps Git-based version control systems could be customized for specific industry verticals, as Chacon hints. But the core message is clear: the AI coding tsunami is here, and Git’s current form is not ready.
Whether you’re a solo developer or part of a large team, recognizing these limitations is the first step toward adapting. The conversation has already started—from Hashimoto’s departure to GitButler’s funding. It’s time to address the signs head-on, because pretending Git will handle the flood of AI-generated code without changes is a risky bet.
