Zed's Delta kills the pull request on its own repo

Replacing Pull Requests with Delta

Zed's Delta kills the pull request on its own repo

Zed has launched the public beta of Delta, a multiplayer coding environment built on DeltaDB, which extends Git with incremental deltas. The company disabled pull requests on Delta's own repository, and 33 engineers have since landed 570 changes to main. Delta lets teammates join agent threads, inherit context, and review code without branches or diffs. It's free during beta, with paid plans coming.

We believe that threads will be the new fundamental unit of software development, and the best way to model their state is with deltas.
  1. ch71r22

    It sounds like it has no CI / merge gating solution. This doesn't look like a substitute for pull requests -- just a way of sharing edit history.

    I don't buy the argument that being able to trace down the initial LLM prompts that led to a line of code will meaningfully accelerate review. That's just like a more advanced git blame. Reviewers will need to understand the code for themselves. A more advanced git blame doesn't really help with that

    Just looking at the final version of the PR without all the intermediate history may be better since it won't sidetrack you with half-baked thoughts and assumptions from the development process. You can just focus on the result

    There are cool things about this, but I'm not convinced it's actually useful. Even less convinced it's a replacement for pull requests. GitHub isn't great but I don't think this is really tackling the problems with GitHub

  2. pipes

    My first thought is, does this mean that along with the burnout I'm feeling with talking to my own agents I now need to try and consume and understand my teammates conversations with agents? Why is this better than a good pr description that distills completed work and explains why it was required ?

  3. emerongi

    I applaud Zed for innovating.

    I like the workflow presented in the video, although I don’t care much about the collaborative part of it. I want to see a polished result from my coworkers, not the messy in-betweens. However, what’s clearly super useful is that if you do have the thread as a reviewer, it can shorten the feedback loop - instead of asking “why did you do it this way?” from a coworker, then waiting for them to proxy that to their AI, you can just do it yourself and only leave the comments that truly matter. Some will claim that this removes learning opportunities, and while it’s true to some extent, it just means that we need to start training juniors differently. Instead of training them through PR comments, maybe the training moves toward short calls or office chats. That would be kind of nice, actually.

    There’s some negative comments, but the truth is that this industry is changing, and Zed as a company must capitalize on that. They will need to make money and it would be suicide to expect that a regular code editor will make money in the future.

    The innovation they bring is exciting and new, even if I am not sure how it will all pan out.

  4. zndbzbz

    This seems like a cool augment to current PR processes but fundamentally I don’t see anyway around still reading the code? Review should optimize for that. Agents make it very easy to create human digestible logical chunks of work that are easily understood and testable. Your job as a dev is to make it easy for your teammates (and your future self) to understand what your change is doing - cause we all know Claude will use 1000 words when 10 will do.

    Other end of this is all the high performing teams I’ve worked on don’t really need PR review. Work is discussed prior to it happening so by the time PR review comes up it’s a rubber stamp. Agents changed none of that - again, unless you’re not reading the code. PR review is mostly for new devs to get brought up to speed. Trust lets you move really fast.

    > but the decisions behind the code still need review. Smaller diffs don't supply that context

    Maybe this is the bit that just seems wrong? Yes they do. You write out what the small change is working towards as part of optimizing your PR for your reviewers time. Might be just text, a link to a doc, link to a prototype etc.

  5. Robdel12

    Man, I just do not care to see people’s LLM conversations. Those are not the artifacts. The changes are. It’s like attaching your slack convo with your teammate as a “pr”

  6. kettlez

    I've been using the beta of Delta for a couple weeks and using it for review is a huge improvement over reviewing directly on the PR. Being able to jump into a team mates thread and see the context of how something got created and be able to ask questions about it very nice. There's some rough edges in the product, but the direction they are going is pretty interesting.

  7. tyingq

    Does it expose all my "Jesus Christ Claude, why on earth did you do that? Revert that now and do x instead." ?

    Meaning, does it prune out some of the not meaningful path to what exists? It's hard to visualize what they actually get to review.

  8. FinnLobsien

    I think the humble PR is definitely not made for this era of software.

    It used to be a finished piece of work that meant „this is the way I solved this engineering challenge.“

    The team member could generally answer questions about that PR and why they chose to do it this way, not some other way, explain discarded approaches, etc.

    Now a lot of that reasoning happens in AI coding agents. So even if a choice on approach was made, the human presenting the PR rarely has the same depth of understanding of each tradeoff and line of code.

    That (in combination with the ease of producing tons of code instantly) makes each PR less meaningful.

    I’m not sure I want my coworker’s AI chat history (who has time to read all that?), but it’s good that innovation is happening.

More from this day

2026-09-18