Replacing Pull Requests with Delta
zed.dev
zed.dev
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
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
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?
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.
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
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.
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 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.
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.
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.
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?
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 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.
Thanks but no.
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.
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'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.
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 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.
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.
Zed is fast and good at many things but need to focus on basic fix or agentic edits broken
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?"
Did you open a new issue?
edit: Done
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?