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.
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.
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.
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 jujitsu 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.
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.
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.
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.
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.
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.
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?"
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.
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.
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.
90 comments
[ 3.0 ms ] story [ 85.8 ms ] threadIt'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.
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.
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.
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.
https://delta.dev/docs/concepts/core-concepts
It reminds me a bit of jujitsu 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?
https://youtu.be/HWB48DFk4Sg?si=qTI7jgSiEwajcTab&t=220
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.
Further, the agents are incentivised (if that's the appropriate term here) to do this, since more tokens equals more cost.
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...
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.
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
Zed is fast and good at many things but need to focus on basic fix or agentic edits broken
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.
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 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?
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?"
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.
But isn’t Zed written in Rust?