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

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 ?

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.

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.

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”

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.

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.

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.

My experience with these Vibe Review tools has been pretty mixed. Fundamentally, they are doing 2 things:

1. reordering the hunks in a "more relevant" order (instead of alphabetical)

2. adding some "fluff text" to connect the hunks together in a narrative

In practice, the reordering doesn't shorten the review time that much (and extends it greatly when the order is illogical), and the AI "explanations" rarely add value. The second video's Review Guide in TFA is way longer than the diff itself.

I much prefer the strict 2-pane setup with rationale and diff strictly separated, and the "self-review" author comments in the diff provide the context for reviewers.

Other similar attempts at this UI this year:

- by Graphite https://graphite.com/blog/code-tours (April)

- and CodeRabbit https://www.coderabbit.ai/blog/introducing-change-stack-the-... (May)

Is this seriously supposed to replace Pull Requests?

I have not gone so far as to allow agents to operate my version control, so excuse my ignorance, but by abandoning PRs for thread deltas, are we also abandoning human-written code entirely? Will every micro-change, fix, or refactor have to be prompted to be tracked in this paradigm?

For more see:

https://delta.dev/docs/concepts/core-concepts

It reminds me a bit of jujutsu in that there is a database with your code changes that is automatically kept in sync with your working directory. The agent edits the database copy directly. I guess the sync must be two-way?

I am not sold on this for 2 reasons:

-I was hoping deltadb would be agnostic about who writes/reads to it, but it actually forces you to use their editor/agent harness which is a no go for me.

-I am not sold on the value of reading other people agent threads and jumping into them half baked. Let me review the piece of code when you, person who made it with or without AI, think its ready to be reviewed with nice summary of the change. I don't need to read X threads with XX messages on the process how it was made with all the little "continue", "fix that" in between.

This stuff reminds me of people who are full into XP and pair programming, where you end up agreeing to pull in more or less any work done by two people together. Not the worst model in the world.

I am disappointed by the "agent chat"-centric design for the future. There is important value in highlighting what's important, and jettisoning the unimportant. Written artifacts are good when they're nice and cut down. And it's not really about the sequence of events (well, most of the time)

Instead of "agent chat", I feel like a written page (that could be interacted with through agents) is a much more interesting way of working through a problem. Capture the final idea, and minimize the fluff around it.

And if nobody is going to read it anyways, why have the chat in the first place?

And of course the glib comment that I can't help but make:

> Teammates can ask the same agent why you chose a Mutex instead of an RwLock.

you know in this hypothetical neither human involved has much of any idea what is going on. Skill atrophy is real, folks! Be careful.

Looks interesting for a small team that's working on a single project. I am curious to understand how this would work out for a large org that has multiple projects under the belt.

PRs may look old fashioned, but they're a very clear way of tracking an issue that may need multiple reviews. With Delta, things can get confusing after more than two reviews + RBAC is another challenge if the agent has similar context for every category.

I never liked it myself, but this looks like an extension of Zed's own systems of collaborative coding (remotely), which in turn is built on top of the ideas of Extreme Programming, and / or intensive pair or mob programming.

It's interesting enough and I'd like to try it sometime, but probably only for hackathons - my main line of work is more planning than actual coding.

I like this, it is high time we evolved/improved git. Given it's novelty, and the solo effort from Zed, I think an off-ramping mechanism would go a long way to attract more adoption from larger players. I hope forgejo comes onboard, but we must have an exir-ramp just Incase threads isn't AI's preference.

I was hoping to see something like this, though I didn't know what form it would take.

A few months ago I was at a demo night in SF and 4 people demo'd essentially the same tool for managing PRs. At the time my thought was "are we really going to be dealing with PRs in 2 years.

I don't know if Delta is the right solution, but Zed is at least questioning the current paradigm, which I think is important.

"software is made between commits" (their DeltaDb blog at https://zed.dev/blog/introducing-deltadb)... yes!

I tend to think the important bit is traceability of why the software changed in the way it did, but not yet convinced that Delta will help with that.

We did something similar for document version control. The fundamental premise is the same: give collaborators the full context involved in (agentic or otherwise) decision making, rather than inferring it from document snapshots. https://lexifina.com/blog/granular-ai-diffs-and-source-traci...

github pull requests are not performant. Alternatives that are not JavaScript based are welcome. Many projects still use mail lists for a reason.

I'd use some "DeltaDB"-like version control tool if it was lightweight and unopinionated about how it integrated into my workflow, since I think revisiting how some change came about at a more granular level could be enlightening. But I'm not interested in this agentic chat multiplayer stuff at all.

I haven't tested this yet, but after reading the post, the issue and the proposed fix make complete sense. I've been relying on markdown files to keep track track of threads. My repository has a mess of files because of it. Look forward to giving this a shot.

It sounds like it's not conceptually different from a MR, the main difference is preserving the rationale for all the changes by bolting the "threads" (a log of agent interactions) on top. I can see how the discussion logs are quite useful if you have an agent that is there to parse them.

This is exactly the kind of issue that makes me skeptical of LLM-focused tooling. Source control should make the human/LLM distinction less important, not build the workflow around it.