A consensus has emerged in the developer community for 2026: GitHub, a platform built for human collaboration, is no longer fit for purpose. The platform logged hundreds of incidents over the 12 months leading into June, as monthly commit volume rocketed from around 1 billion across the whole of 2025 to 1.4 billion a month by April. By August, the figure had jumped to 2.9 billion commits each month. This growing load has manifested in spectacular outages, including a near-eight-hour disruption in August with web and API error rates reaching around 20 percent at the height of the incident.
Agents and the end of the pull request
At the heart of all of this is the reliability of GitHub, but a more fundamental question has also emerged: the interaction model itself. Agents can generate, revise, and submit code at a cadence GitHub was not designed for. When much of the reasoning behind a change happens inside a conversation with an agent, a pull request presents reviewers with the resulting diff while leaving the journey that produced it elsewhere. The diffs asked for review have “mushroomed,” as co-founder and CEO of Zed Nathan Sobo puts it in a blog post published on Wednesday.
Zed, for the uninitiated, started as a high-performance, multiplayer code editor built in Rust. When the company announced a $32 million round of funding led by Sequoia Capital in August 2025, it teased DeltaDB, a new kind of operation-based version control system designed to record code changes at edit-level granularity. Fast-forward to August, and Zed revealed Delta itself in private beta, pitching it as a multiplayer environment where developers can code with agents, share their ongoing threads with teammates, and review changes with the original agent context intact.
Wednesday’s public beta launch brings that idea out into the open and takes direct aim at GitHub’s defining feature: the pull request. The central concept behind Delta is the thread—a running record of an agent-assisted coding task in which the conversation and the files being changed remain connected. A developer can hand an agent a job, continue discussing and refining it, and later share that entire body of work with somebody else. Each thread can work against its own copy of a project, allowing multiple pieces of work to proceed independently without every agent touching the same checked-out files.
For a developer moving from a traditional workflow to Delta, the most visible change is the absence of a pull request button. Instead of packaging work into a commit and asking for a review, the developer simply keeps the conversation open and lets teammates join the thread. Teammates can join an existing thread or create a separate review thread to examine a proposed change, question the agent that produced it, and try revisions before feeding accepted changes back into the original work. This shift implies that the social layer of software development is moving from static snapshots of code to dynamic, persistent conversations.
Read Also: Meta simplifies WhatsApp Business setup with AI
DeltaDB sits underneath that model, recording activity at a finer level than Git. Instead of waiting for a developer to package work into a commit, it captures individual events as they happen—including code edits and activity within the conversation—and uses that history to keep participants synchronized. Zed calls those individual records “deltas.” Git hasn’t gone the way of the dodo quite yet, though. Delta currently works with Git repositories, and developers can continue using branches, commits, and remotes as usual. DeltaDB effectively adds another layer of history between commits, preserving the intermediate human and agent activity that Git would otherwise discard.
Migration strategies and the future of collaboration
Sobo acknowledges that this transition will not be instantaneous for every organization. The company is taking a measured approach to migrating its own public-facing projects, recognizing that GitHub offers a mature social network of contributors. Stranding external developers would alienate the community, so the public codebase will retain a pull request workflow for the foreseeable future. This allows contributors to submit fixes through standard channels while still using Delta internally for agent-assisted work.
However, the company is actively working to decouple its internal development from the legacy platform. Zed is only a few months away from leaving GitHub behind, as teams focused exclusively on Delta have already found little reason to visit the older system. Their conversations, reviews, and handoffs now occur entirely within the new environment. The company has disabled pull requests on its own Delta repository, and since making that switch, 33 developers have contributed 570 changes to the main branch without using traditional review mechanisms.
Technical dependencies also require attention before a total break can occur. The next major hurdle involves Git storage, which Zed intends to integrate directly into DeltaDB. Continuous integration and release management processes must also migrate away from GitHub, though Sobo believes CI is largely a solved problem that can be addressed through existing integrations rather than building new infrastructure from scratch. Repository-based access is another item on the roadmap, designed to use existing GitHub permissions to control who can view shared Delta threads.
The shift in fundamental units of development is central to Sobo’s vision. He predicts that the thread will replace the commit or branch as the primary object of software development. Commits will remain useful as checkpoints, but they fail to capture the intermediate reasoning, agent conversations, and incremental decisions that lead to the final code. DeltaDB preserves this history, allowing new collaborators to enter a project exactly where the previous work stopped and continue interacting with the same agent context.
