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 find pair programming very productive with agentic coding.
Two people (plus one or more agents) have the full context of the plan, execution, written code, automated and manual testing. Both can help drive to the point where it feels safe to sign off on the change right then and there and merge it.
Compare that to traditional PR / code review, where so much of that context is lost. At best the coder needs to spend a lot more time rewriting up a great PR description to bring the reviewer up to speed. At worst the reviewer needs to read lots of AI slop PRs, docs, transcripts, and code to try to make sense of things.
Doing it together then merging the thread and moving on can be efficient.
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 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.
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?
Oh, yeah. I gave Claude sudo on my AI dev machine: it commits, pushes, checks the results of pre-push tests, sudos to another user, deploys, checks the results of smoke tests, and then checks the end result.
It also has MCP access to Cloudflare. Front-end deploys on every push to main but Claude can adjust the pipeline, add environmental variables, etc.
That's like not putting protective guardrail on a staircase, and instead having first aid kits and emergency phone number on hand. In other words, dumb and irresponsible. Possibly illegal, depending on the case.
Why? It sounds like a pretty typical workflow to me.
It just depends on what you are building. Some things are more more forgiving to muck-ups than others and if the LLM screws the pooch, oh well! Roll forward.
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.
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?
Seems interesting! I have found my main bottleneck right now is having too primitive tools for code review. A tighter loop around that might be a solution.
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.
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.
But what if your PR was created as half chat, then an agent, then some more chat planning, possibly in a new chat to clear the context? I think my teammates would find my inner monologue rather confusing at times.
The sequence of commits I present a purely optimized for reviewing, and not an actual record of what happened. I’m not going to read another person’s 100 turn slop factory, because they couldn’t express their change in one paragraph.
Yeah, my solution to this problem has been to get Claude to use jj to create a clean commit history. Each commit serves a single purpose and includes what drove the decisions we made. You lose the noise and still have the meaning.
So I'm a little unclear as to benefit of this. It sounds...wasteful?
for a lot of teams that do pair programming etc and pairing with agents - this makes sense.
hell dare I say better than the pull-request model - since you don't have to wait on people to review the code and deal with the nonsense of merge-trains.
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...
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.
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 ?
Software Engineers avoid coding more than any other type of people I have ever met. It's clearly not better but much easier for the Engineers who just want the results without knowing anything about the solution.
I've lost faith in their editor and GPUI - you were the one, Zed! They are full-steam AI on things like this. I expected this article to be about a general alternative to git, but it is about LLM-focused coding in a way that doesn't make sense to me, as it slices a line between human-written and LLM-written code which does not exist in a meaningful way.
Their primary product, the Zed editor, is unusable for me and others due to it mismanaging file syncs on disk - when external edits happen, the editor retains stale state unless you close and re-open the specific file (Not even an editor reopen syncs it). There is a significant risk of your changes being silently overwritten or conflicted. Amusingly, the risk of this is increased when a file is changed asynchronously, which for me, most happens due to a pull or LLM edits!
It begs questions like: "If coding has changed so that we should use an LLM-focused source control tool, why can't the LLM fix a severe bug in our software that has a closed-form solution?"
Woah. I’ve been meaning to check out zed but that’s a huge problem. I’ve fixed this problem before in rust, there’s just a library you can use to update file trees with a combination of batching fs notifications and a periodic rescan. Wtf guys! Maybe I’ll submit a PR… oh wait! I mean delta.
:(
Similarly, I had to stop using Zed because the main thread would beachball for > 30s when trying to work in large repos on macOS. This behavior was clearly reported to them in a GitHub issue that they also closed without fixing (because they believed a partial fix was sufficient, and have ignored subsequent comments to the contrary): https://github.com/zed-industries/zed/issues/55746
No. Still heavy as hell. (AKA uses loads of ram and CPU, slow, sometimes unresponsive). It is the price we pay - the tradeoff is IMO the unmatched editing and introspection/refactoring capabilities. I'm surprised there hasn't been a real competitor in this space.
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.
Look interesting, though admittedly I am mostly interested in the open-source release of DeltaDB.
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.
Yes I like where Zed is going with this.
I find pair programming very productive with agentic coding.
Two people (plus one or more agents) have the full context of the plan, execution, written code, automated and manual testing. Both can help drive to the point where it feels safe to sign off on the change right then and there and merge it.
Compare that to traditional PR / code review, where so much of that context is lost. At best the coder needs to spend a lot more time rewriting up a great PR description to bring the reviewer up to speed. At worst the reviewer needs to read lots of AI slop PRs, docs, transcripts, and code to try to make sense of things.
Doing it together then merging the thread and moving on can be efficient.
Certainly looks interesting and a new way of working which would take some time to get adjusted.
Would have loved to have tried this, but it still bizarrely lacks Apple Intel support.
Intel Macs haven't been sold for over three years now. I don't think that's bizzare.
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 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:
you know in this hypothetical neither human involved has much of any idea what is going on. Skill atrophy is real, folks! Be careful.
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?
Oh, yeah. I gave Claude sudo on my AI dev machine: it commits, pushes, checks the results of pre-push tests, sudos to another user, deploys, checks the results of smoke tests, and then checks the end result.
It also has MCP access to Cloudflare. Front-end deploys on every push to main but Claude can adjust the pipeline, add environmental variables, etc.
That sounds like a problem waiting to happen.
All IT infrastructure is a problem waiting to happen. I have backups and a rollback mechanism.
That's like not putting protective guardrail on a staircase, and instead having first aid kits and emergency phone number on hand. In other words, dumb and irresponsible. Possibly illegal, depending on the case.
This almost reads like parody.
Why? It sounds like a pretty typical workflow to me.
It just depends on what you are building. Some things are more more forgiving to muck-ups than others and if the LLM screws the pooch, oh well! Roll forward.
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.
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?
Apparently downloading this requires "signing in and accepting beta terms".
Seems interesting! I have found my main bottleneck right now is having too primitive tools for code review. A tighter loop around that might be a solution.
Primitive in what way? There are already tools that categorize changes so that they are easier to follow during a review.
Like…?
This would force you to utilize agentic AI just to make small code changes.
Hmm, looks to me you can also just go and modify the code in the editor?
At 3:40 in the video you can see direct code editing in Delta with no AI involvement:
https://youtu.be/HWB48DFk4Sg?si=qTI7jgSiEwajcTab&t=220
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.
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.
Further, the agents are incentivised (if that's the appropriate term here) to do this, since more tokens equals more cost.
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.
But what if your PR was created as half chat, then an agent, then some more chat planning, possibly in a new chat to clear the context? I think my teammates would find my inner monologue rather confusing at times.
The sequence of commits I present a purely optimized for reviewing, and not an actual record of what happened. I’m not going to read another person’s 100 turn slop factory, because they couldn’t express their change in one paragraph.
Yeah, my solution to this problem has been to get Claude to use jj to create a clean commit history. Each commit serves a single purpose and includes what drove the decisions we made. You lose the noise and still have the meaning.
So I'm a little unclear as to benefit of this. It sounds...wasteful?
I must say again, can not manual refresh the file tree in zed https://github.com/zed-industries/zed/discussions/54150
Zed is fast and good at many things but need to focus on basic fix or agentic edits broken
for a lot of teams that do pair programming etc and pairing with agents - this makes sense.
hell dare I say better than the pull-request model - since you don't have to wait on people to review the code and deal with the nonsense of merge-trains.
Has anyone compared this with Cursor's Origin?
Origin is a platform, this is about storing context in your repository directly.
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...
Lexfina looks very cool. I need self-hosting to adopt at my business.
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.
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 ?
Software Engineers avoid coding more than any other type of people I have ever met. It's clearly not better but much easier for the Engineers who just want the results without knowing anything about the solution.
Obviously I don't get it because, for me, it's like PRs with some agentic generated description and a way to involve in a chat another guys.
I've lost faith in their editor and GPUI - you were the one, Zed! They are full-steam AI on things like this. I expected this article to be about a general alternative to git, but it is about LLM-focused coding in a way that doesn't make sense to me, as it slices a line between human-written and LLM-written code which does not exist in a meaningful way.
Their primary product, the Zed editor, is unusable for me and others due to it mismanaging file syncs on disk - when external edits happen, the editor retains stale state unless you close and re-open the specific file (Not even an editor reopen syncs it). There is a significant risk of your changes being silently overwritten or conflicted. Amusingly, the risk of this is increased when a file is changed asynchronously, which for me, most happens due to a pull or LLM edits!
It begs questions like: "If coding has changed so that we should use an LLM-focused source control tool, why can't the LLM fix a severe bug in our software that has a closed-form solution?"
Do you have a link to an issue, so I can know if I should be worried about this?
Here: https://github.com/zed-industries/zed/issues/38109
Ah, yeah, I get this issue too but I've been so conditioned to close and reopen files that I've stopped thinking it was an issue. Appreciate the link.
Woah. I’ve been meaning to check out zed but that’s a huge problem. I’ve fixed this problem before in rust, there’s just a library you can use to update file trees with a combination of batching fs notifications and a periodic rescan. Wtf guys! Maybe I’ll submit a PR… oh wait! I mean delta. :(
Similarly, I had to stop using Zed because the main thread would beachball for > 30s when trying to work in large repos on macOS. This behavior was clearly reported to them in a GitHub issue that they also closed without fixing (because they believed a partial fix was sufficient, and have ignored subsequent comments to the contrary): https://github.com/zed-industries/zed/issues/55746
What do you use instead?
Jetbrains (PyCharm and RustRover) for projects; Sublime for one-off files.
The last time I checked out Jetbrains' IDEs, they felt heavy as hell to use. Has that changed?
No. Still heavy as hell. (AKA uses loads of ram and CPU, slow, sometimes unresponsive). It is the price we pay - the tradeoff is IMO the unmatched editing and introspection/refactoring capabilities. I'm surprised there hasn't been a real competitor in this space.
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.
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.
Wow that entire workflow looks absolutely hellish