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
Ok I rewatched that now. Maybe this could work? I'm still not sure how much confidence to place in their system for merge gating
Having land as a skill seems weird to me. You could write in your land skill that it should make sure CI is passing, but I wouldn't want to leave it up to the LLM to decide if CI is passing. I'd rather that be a decision enforced by the git remote
I think to make this work the way I imagine merge checks should work, I'd have to set up my git remote to only allow fast forward merges with checks passing. I don't think this work very well with my org's current merge queue setup, but might work better for people not using a merge queue
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 ?
Yes, but compared to seeing 3k lines of code in a PR with no history with vibes in the description, what is better? This definitely "feels" like something worth exploring.
You can defer review entirely to an LLM, only to human reviewers, or both. We are experimenting with both and have configured LLM skills for pull request reviews. On large projects we also configure LLMs to produce commit segregated diffs within a single pull request, to aid human review. This process is using the github pull request workflow that Zed is attempting to replace.
Anyway, I'm probably being over cynical and yes it is worth exploring alternatives to the current system.
However I already feel overwhelmed dealing with agent chats. I can't currently see how this deals with the pr problem:
If I am supposed to delegate to agents why do my conversations need reviewed by my peers. This feels like classic bad management practices of not trusting the staff below you to get on with it, instead turn up in every meeting.
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 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.
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”
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.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
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?
Redescribe, reorder, split, squash, abandon commits is trivial.
Auto-rebasing is fantastic, fix a conflict once and not have to keep correcting.
You can rebase individual commits, ranges of commits, etc. You can also rebase trees I.e. forking branches with a common ancestor, with a single command.
The operation log also makes it feel super safe. You can always undo a jj operation or restore to a past state
I've been curious about using it but the fact it needs to upload everything makes it something I can't do with work and then don't see the immediate value of on projects by myself.
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.
I want artifacts (PRs / work that was done) instead of sessions. The worst part about this era is that everyone feels productive because they are doing work and sessions are shaped around doing work instead of delivering. It is so easy to get duped by AI optimism and not actually ship stuff.
I agree with them that github should die and that we should track every bit of context and every edit, but I am sick of seeing tools about the input instead of the output. I actually only want to see/try PRs. good ones.
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.
frankly i think most of these "tools" are the result of people being addicted to watching the agent shit code out and as such quietly abolishing review.
There's tons of good ideas on how to improve the code review, but for some reason everyone just gravitates to the most basic "copilot" experience. I'm sure by next year someone will finally figure out a better flow.
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.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
I didn’t say they didn’t exist. I said it isn’t bizarre that a startup does not prioritize support for unpurchasable hardware that is no longer supported by its manufacturer.
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?"
I _think_ they fixed the file sync issue; I haven’t had desynced files in a few weeks.
Still a bad bug that lingered entirely too long.
> when a file is changed asynchronously, which for me, most happens due to a pull or LLM edits!
If you’re using Pi (I am), that’s partially because Pi doesn’t have “real” ACP and violates the spec as a result. File read/writes are supposed to happen via ACP RPC calls from the agent to the client, so Zed would see them and know to refresh. Pi wasn’t built for ACP so it embeds its own read/write tools and ignores the ACP ones, and Zed never gets the “refresh this file” signal it expects.
> 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.
Yikes. I had to stop using JetBrains software for similar reason (their autosave effectively conflicted with external git usage). This is inexcusable to me but to each their own.
Yes, but I think it still behaved weirdly with external changes. It's been a few years now, maybe it discarded any unsaved changes and just re-read the version from disk, or maybe it auto closed any editors for files that didn't exist after a branch change. Awkward behavior like that. VSCode and Sublime Text are much better in this regard.
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
> Closing this as I expect many of the remaining problems described in this issues comments to be fixed by #51208.
>
> Once that PR makes it to stable (expected March 25th 2026), please create new issues if you are still experiencing problems.
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.
:(
Yeah, JetBrains IDEs are Java-based, so rather heavyweight. Then again, VS Code (and Cursor) have a browser engine running in the background, so not really better in my book. Sublime and Zed are more efficient of course. OTOH, JetBrains IDEs might be memory intensive, but don't actually feel sluggish on my 5 year old Core i7 laptop with 16 GB RAM.
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've been running a latest-1 version of a few of their products on silicon Macs since M1 w/ 8GB RAM without issue. I use minimal plugins and work on medium-sized codebases and their IDEs are some of the most reliable software I use.
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
Did you finish the video? It has CI, but I don't know if they implemented merge gating. Though I suppose that could be part of the land skill
Ok I rewatched that now. Maybe this could work? I'm still not sure how much confidence to place in their system for merge gating
Having land as a skill seems weird to me. You could write in your land skill that it should make sure CI is passing, but I wouldn't want to leave it up to the LLM to decide if CI is passing. I'd rather that be a decision enforced by the git remote
I think to make this work the way I imagine merge checks should work, I'd have to set up my git remote to only allow fast forward merges with checks passing. I don't think this work very well with my org's current merge queue setup, but might work better for people not using a merge queue
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 ?
Yes, but compared to seeing 3k lines of code in a PR with no history with vibes in the description, what is better? This definitely "feels" like something worth exploring.
We never accepted 3k lines of code in a PR from a human, why do we from LLMs?
And if we're going to, why are LLMs not doing the PR review?
And if we don't trust them, then isn't that a rather large obstacle to the idea that LLMs are going to replace humans in software engineering?
You can defer review entirely to an LLM, only to human reviewers, or both. We are experimenting with both and have configured LLM skills for pull request reviews. On large projects we also configure LLMs to produce commit segregated diffs within a single pull request, to aid human review. This process is using the github pull request workflow that Zed is attempting to replace.
Why is "feels" in quotes?
Anyway, I'm probably being over cynical and yes it is worth exploring alternatives to the current system.
However I already feel overwhelmed dealing with agent chats. I can't currently see how this deals with the pr problem: If I am supposed to delegate to agents why do my conversations need reviewed by my peers. This feels like classic bad management practices of not trusting the staff below you to get on with it, instead turn up in every meeting.
And end up with 3k lines of code + conversation history?
It is for when management thinks PRs are “slowing us down” and we need to use Delta
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.
At least traditionally, software engineers avoided everything except coding for a long time, but now i guess that's changed
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.
I do want the messy in-betweens. The earlier you catch problems, the cheaper they are to fix. I hope this will become the default of collaborating.
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”
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.
Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
You needn't use your real name, of course, but for HN to be a community, users need some identity for other users to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
> cause we all know Claude will use 1000 words when 10 will do
Further, the agents are incentivised (if that's the appropriate term here) to do this, since more tokens equals more cost.
Tokens used for user-facing prose are a rounding error for coding agents. I don't think there's a conspiracy there.
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?
What does jj specifically enable for that workflow?
It drastically simplifies the process.
Redescribe, reorder, split, squash, abandon commits is trivial.
Auto-rebasing is fantastic, fix a conflict once and not have to keep correcting.
You can rebase individual commits, ranges of commits, etc. You can also rebase trees I.e. forking branches with a common ancestor, with a single command.
The operation log also makes it feel super safe. You can always undo a jj operation or restore to a past state
I've been curious about using it but the fact it needs to upload everything makes it something I can't do with work and then don't see the immediate value of on projects by myself.
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.
I want artifacts (PRs / work that was done) instead of sessions. The worst part about this era is that everyone feels productive because they are doing work and sessions are shaped around doing work instead of delivering. It is so easy to get duped by AI optimism and not actually ship stuff.
I agree with them that github should die and that we should track every bit of context and every edit, but I am sick of seeing tools about the input instead of the output. I actually only want to see/try PRs. good ones.
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?
frankly i think most of these "tools" are the result of people being addicted to watching the agent shit code out and as such quietly abolishing review.
There's tons of good ideas on how to improve the code review, but for some reason everyone just gravitates to the most basic "copilot" experience. I'm sure by next year someone will finally figure out a better flow.
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.
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.
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.
I hope you never handle other people's data.
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.
You also upload your code and conversations into their server-hosted DeltaDB service and the only way to remove it is to email their privacy contact.
Thanks but no.
Including non-tracked files that land in your local directory even if they're never committed.
github pull requests are not performant. Alternatives that are not JavaScript based are welcome. Many projects still use mail lists for a reason.
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.
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 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.
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.
"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...
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.
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.
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…?
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.
Certainly looks interesting and a new way of working which would take some time to get adjusted.
Look interesting, though admittedly I am mostly interested in the open-source release of DeltaDB.
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.
I don't think any of my interactive use machines (server/remote are another story) are less than 3 years old.
Some of mine are and some of mine aren’t, but the ones that are are on platforms that are still made and supported, unlike Intel Macs.
They haven't been sold for three years so they suddenly don't exist? Really?
I didn’t say they didn’t exist. I said it isn’t bizarre that a startup does not prioritize support for unpurchasable hardware that is no longer supported by its manufacturer.
Wow that entire workflow looks absolutely hellish
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.
Has anyone compared this with Cursor's Origin?
Origin is a platform, this is about storing context in your repository directly.
Apparently downloading this requires "signing in and accepting beta terms".
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
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?"
I _think_ they fixed the file sync issue; I haven’t had desynced files in a few weeks.
Still a bad bug that lingered entirely too long.
> when a file is changed asynchronously, which for me, most happens due to a pull or LLM edits!
If you’re using Pi (I am), that’s partially because Pi doesn’t have “real” ACP and violates the spec as a result. File read/writes are supposed to happen via ACP RPC calls from the agent to the client, so Zed would see them and know to refresh. Pi wasn’t built for ACP so it embeds its own read/write tools and ignores the ACP ones, and Zed never gets the “refresh this file” signal it expects.
> 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.
But isn’t Zed written in Rust?
Yikes. I had to stop using JetBrains software for similar reason (their autosave effectively conflicted with external git usage). This is inexcusable to me but to each their own.
Don't they have an auto-save setting that you can turn off?
Yes, but I think it still behaved weirdly with external changes. It's been a few years now, maybe it discarded any unsaved changes and just re-read the version from disk, or maybe it auto closed any editors for files that didn't exist after a branch change. Awkward behavior like that. VSCode and Sublime Text are much better in this regard.
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
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
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.
> Closing this as I expect many of the remaining problems described in this issues comments to be fixed by #51208. > > Once that PR makes it to stable (expected March 25th 2026), please create new issues if you are still experiencing problems.
Did you open a new issue?
No, but I posted on the existing one. Sounds worth trying.
edit: Done
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. :(
What is that library name? Sounds helpful.
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?
Yeah, JetBrains IDEs are Java-based, so rather heavyweight. Then again, VS Code (and Cursor) have a browser engine running in the background, so not really better in my book. Sublime and Zed are more efficient of course. OTOH, JetBrains IDEs might be memory intensive, but don't actually feel sluggish on my 5 year old Core i7 laptop with 16 GB RAM.
Visual studio (at least its "core") is written in C++, yet is very heavy weight, so it's not the programming language at play here.
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've been running a latest-1 version of a few of their products on silicon Macs since M1 w/ 8GB RAM without issue. I use minimal plugins and work on medium-sized codebases and their IDEs are some of the most reliable software I use.
This would force you to utilize agentic AI just to make small code changes.
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
Hmm, looks to me you can also just go and modify the code in the editor?
I'll admit that "force" was the wrong word here but Delta is still a what a vibe coder who doesn't understand version control would utilize.