My uncomfortable opinion: Git was not designed for a world where ten AI agents work in parallel on the same codebase.
Git is still one of the most successful developer tools ever created. It is simple where it needs to be simple, distributed where it matters, fast enough for most teams, and deeply understood by generations of engineers. The problem is not that Git suddenly became bad. The problem is that the shape of software work is changing around it.
The recent Show HN discussion around Oak, a Git alternative designed for AI agents, is interesting for exactly that reason. Oak describes a workflow with virtual mounts, agent-friendly access to repositories without a full local copy, and fewer fights over worktrees when many local or cloud agents are operating at once. The project is early: no Windows build, no full replacement ecosystem around CI, issues, comments, or long-standing team habits. But the direction matters.
Version control is becoming an orchestration layer
For a human developer, a branch is often a thinking space. You pull the repository, create a branch, make a few commits, and eventually merge. For a team, the branching model becomes a coordination language: feature branches, release branches, hotfixes, trunk-based development, pull requests, code review, and CI.
AI agents stretch that model. A single developer may now run several coding agents in parallel. One agent investigates a bug. Another writes tests. A third experiments with a refactor. A fourth prepares a migration. Some run locally. Some run in the cloud. Some need only part of the repository. Some need to come and go quickly without polluting the developer’s workspace.
At that point, version control is not only about preserving history. It starts acting like an orchestration layer for temporary, parallel, non-human work. That is a different job.
The pain is not only merge conflicts
It is tempting to reduce this discussion to merge conflicts. That is too narrow. The real pressure shows up in context loading, workspace isolation, repository size, permissions, CI cost, review noise, and the lifecycle of agent-created changes.
If every agent needs a full repository clone, startup becomes expensive. If every experiment needs a worktree, local state becomes messy. If every agent emits changes into the same review path, maintainers drown in low-context diffs. If the toolchain treats agent work exactly like human work, the team may lose visibility into which changes are experiments, which are ready for review, and which should be discarded.
This is why I see a connection to AI agents needing release engineering, not just better prompts. Prompt quality helps, but operational quality decides whether agent output can safely move through a real engineering system.
Why replacing Git is still a very high bar
Developer infrastructure rarely wins because the idea is clever. It wins when it fits into the daily rituals of teams.
That is the caution for every “Git alternative” story. Git is not only a storage format and a command-line tool. It is a massive ecosystem: GitHub, GitLab, Bitbucket, CI providers, security scanners, IDE integrations, deployment flows, audit habits, compliance workflows, onboarding materials, and years of muscle memory. A version-control tool without Windows support, mature CI integration, issues, comments, permissions, search, and review ergonomics does not replace that overnight.
The better framing is not “Git is dead.” It is: new workflows are creating new source-control primitives. Some of those primitives may live around Git. Some may sit above it. Some may become specialized agent workspaces that only turn into Git commits when the work is worth preserving.
What engineering leaders should inspect now
Before adopting a new version-control system, I would inspect the workflow friction. Tools should follow the pain, not the hype.
- Agent startup time: how long does it take an agent to get enough repository context to do useful work?
- Workspace isolation: how often do parallel tasks collide with local state, dependency state, generated files, or worktrees?
- Review quality: are agent-created diffs easy to inspect, or do they create more review noise than leverage?
- Change lifecycle: can the team distinguish experiments, suggested patches, approved work, and production-ready changes?
- Security boundaries: can agents access only the code and secrets they actually need?
- Integration cost: what breaks in CI, deployment, audit, and incident response if the source-control layer changes?
This also connects to the broader question of architectural decisions that become hard to undo. Source control is not just a developer preference. It becomes part of the operating model of the company.
My practical take
I do not think teams should rush to replace Git because agents are exciting. I do think teams should stop assuming the old human-first workflow will automatically scale to agent-heavy development.
The useful question is not “Which tool wins?” The useful question is: where does your agent workflow break because of the surrounding development system, not because of the model itself?
If the answer is repository access, worktree collisions, slow context loading, review overload, or unclear lifecycle management, then version control has become part of your AI engineering architecture. That deserves a serious design discussion, not just another prompt experiment.
Originally posted on LinkedIn: https://www.linkedin.com/feed/update/urn:li:share:7475830032834281473/
