Git was built for distributed work. That was the point.

It let large groups of developers branch, commit, merge, and reconcile code without depending on one central machine as the source of all motion. It became the basic grammar of modern software. Even people who dislike Git still organize their work around it.

Now the pressure is coming from a direction Git was not designed around: code that is generated, edited, tested, opened, revised, and resubmitted by agents at machine pace.

The issue is not that Git suddenly stopped working. It is that the software development workflow around Git was built for humans. Humans pause. Humans name branches. Humans open pull requests. Humans wait for CI. Humans read diffs, leave comments, fix two files, get coffee, come back, rebase, and try again.

Agents do not naturally work that way. They produce volume. They make overlapping changes. They create pull requests faster than teams can review them. They turn what used to be occasional background friction into something closer to infrastructure load.

The GitHub problem is bigger than GitHub

The Register framed the current tension through GitHub, where service complaints, slower pull requests, and AI-generated work are colliding in public. Mitchell Hashimoto, co-founder of HashiCorp and creator of the Ghostty terminal emulator, recently moved Ghostty away from GitHub after becoming frustrated with the service. He was careful to separate Git from the platform around it. The problem was not Git itself. The problem was the infrastructure wrapped around it: issues, pull requests, Actions, and the hosted workflow developers now treat as default.

That distinction matters.

Git is distributed. GitHub is centralized. The industry uses a distributed version control system through a handful of centralized social and automation platforms. That worked well enough when the bottleneck was human coordination. It becomes stranger when automated contributors start producing work at a scale the surrounding systems were not shaped to absorb.

The result is a contradiction hiding in plain sight: software teams adopted Git to avoid centralized version control, then rebuilt much of their daily work around centralized pull request platforms.

AI changes the tempo

AI coding tools do not merely help developers type faster. They change the tempo of the whole development loop.

A developer can ask an assistant to generate a feature, write tests, update documentation, refactor a module, or produce a shell script that would have been annoying to write by hand. GitHub's own Octoverse coverage says shell scripting saw 206 percent year-over-year growth in AI-generated projects. That is a small window into a larger shift: AI makes previously tedious coding work cheap enough to attempt more often.

That sounds like productivity. Sometimes it is. But every generated change still has to enter a system of trust.

Someone or something has to decide whether the code is correct, safe, maintainable, tested, documented, and compatible with the rest of the repository. The burden moves. Less time may be spent writing the first draft. More time may be spent reviewing, validating, untangling, rejecting, and cleaning up.

That is where Git workflows start to feel old. A pull request is a useful unit when a person is proposing a coherent change. It becomes less useful when agents can produce many small, overlapping, partially correct, context-limited patches across the same codebase.

The old workflow has too many stop signs

The standard GitHub-style workflow is full of gates:

  • Create a branch.
  • Make commits.
  • Push the branch.
  • Open a pull request.
  • Wait for CI.
  • Wait for review.
  • Revise the branch.
  • Resolve conflicts.
  • Squash, rebase, or merge.

That workflow is not broken. It encodes caution, accountability, and history. But it also assumes that changes arrive at a human rate. When agents enter the loop, the number of proposed changes can rise faster than the team's ability to evaluate them.

The bottleneck becomes less about producing code and more about deciding which code deserves to survive.

That distinction is the center of the AI coding problem. The future of software development is not just more code. It is more proposed code, more temporary code, more speculative code, more low-cost experiments, and more automated edits that need a place to exist before they become real.

Git is good at history, weaker at negotiation

Git is excellent at recording history. It is less elegant as a negotiation space.

Developers know the pain points: stacked changes, long-running branches, merge conflicts, rebases, unclear commit history, large pull requests, force pushes, fragile CI queues, and the strange social ritual of deciding what counts as a clean commit.

These problems already existed. AI just makes them harder to ignore.

If one person is working on a feature branch, the friction is manageable. If a person and two agents are editing adjacent parts of the same repository while another agent is updating tests and a fourth is trying to fix a failing deployment, the old model starts to creak.

The repository needs more than branches. It needs a better workspace for intent, review, isolation, metadata, partial acceptance, and rollback.

The interesting work is happening around Git

The Register points to several attempts to rethink this layer without necessarily throwing Git away.

GitButler, co-founded by GitHub co-founder Scott Chacon, tries to rethink the user-facing side of Git. Its virtual branching model is meant to make it easier to work across multiple streams of change at once. That matters in an agent-heavy workflow because agents and humans may need to operate in the same repository without constantly stepping on each other.

Jujutsu, usually called jj, is another serious attempt to make version control feel less hostile. It is Git-compatible, but it changes the user model. Features like easier undo and more flexible conflict handling point toward a workflow where mistakes and intermediate states are less punishing.

Gitoxide, a Rust implementation of Git tooling, points in a different direction: performance, memory safety, and the possibility of using more modern systems assumptions underneath familiar version control concepts.

Then there is Git 3, which is expected to bring reftable as a default. Reftable changes how Git stores references, replacing older packed reference handling with an indexable binary format. That sounds obscure, but references are one of the places where very large repositories and highly concurrent workflows can hurt. If agents create more branches, more changes, and more simultaneous activity, those internal details stop being academic.

The future may be less centralized

The irony is that Git already gave the industry a distributed foundation. The platform layer pulled much of that work back into central hubs.

That does not mean GitHub, GitLab, or similar platforms disappear. They solve real problems: identity, access control, CI, review, issues, releases, package publishing, security scanning, and social coordination. But the next version of the workflow may need to distribute more of the work again.

Agents may need local working contexts that are richer than a branch. Teams may need mirrors, queues, sandboxes, and review layers that do not treat every generated change as a normal human pull request. Hosted platforms may need to become less like the single town square for every edit and more like the final publishing layer for changes that have already been filtered, tested, grouped, and explained.

In other words, AI coding may force Git workflows to become more distributed in practice, not just in theory.

Review becomes the scarce skill

The obvious mistake is to treat this as a tooling story only.

It is also a labor story. AI coding shifts value away from typing and toward judgment. The senior developer's job becomes less about producing every hard line of code manually and more about defining boundaries, reading diffs, identifying failure modes, designing tests, protecting architecture, and saying no.

That is not a downgrade. It is a different kind of work.

The teams that benefit from AI coding will not be the teams that generate the most code. They will be the teams that build the best filters between generated code and production code.

Git, pull requests, and CI are part of that filter. They are just not enough by themselves.

The real question

The question is not whether Git survives AI coding. Git is too embedded, too useful, and too widely supported to vanish because agents made developers busier.

The better question is whether the current Git-centered workflow survives unchanged.

Probably not.

AI coding agents expose the parts of software development that were already overloaded: review, coordination, ownership, testing, deployment trust, and platform reliability. Git can still be the durable record underneath that work. But the layer above it needs new primitives for machine-speed contribution and human-speed judgment.

The code was never the whole product. The system that decides which code becomes real is the product now.

Sources