[HN Gopher] Replacing Pull Requests with Delta
___________________________________________________________________
Replacing Pull Requests with Delta
https://delta.dev/
Author : vquemener
Score : 140 points
Date : 2026-09-16 14:05 UTC (2 days ago)
HTML web link (zed.dev)
TEXT w3m dump (zed.dev)
| Palmik wrote:
| Look interesting, though admittedly I am mostly interested in the
| open-source release of DeltaDB.
| Cthulhu_ wrote:
| 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.
| nzoschke wrote:
| 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.
| sajithdilshan wrote:
| Certainly looks interesting and a new way of working which would
| take some time to get adjusted.
| ghusto wrote:
| Would have loved to have tried this, but it still bizarrely lacks
| Apple Intel support.
| steveklabnik wrote:
| Intel Macs haven't been sold for over three years now. I don't
| think that's bizzare.
| ghusto wrote:
| They haven't been sold for three years so they suddenly don't
| exist? Really?
| steveklabnik wrote:
| 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.
| abeyer wrote:
| I don't think any of my interactive use machines
| (server/remote are another story) are less than 3 years old.
| steveklabnik wrote:
| 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.
| dguest wrote:
| 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.
| rtpg wrote:
| 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.
| DR0D4 wrote:
| 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?
| blfr wrote:
| 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.
| tacomagick wrote:
| That sounds like a problem waiting to happen.
| blfr wrote:
| All IT infrastructure is a problem waiting to happen. I
| have backups and a rollback mechanism.
| pferde wrote:
| 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.
| pebble wrote:
| This almost reads like parody.
| cruffle_duffle wrote:
| 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.
| yencabulator wrote:
| I hope you never handle other people's data.
| samayashar wrote:
| 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.
| skybrian wrote:
| 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?
| LoganDark wrote:
| Apparently downloading this requires "signing in and accepting
| beta terms".
| meffmadd wrote:
| 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.
| mechazawa wrote:
| Primitive in what way? There are already tools that categorize
| changes so that they are easier to follow during a review.
| itsdesmond wrote:
| Like...?
| kittikitti wrote:
| This would force you to utilize agentic AI just to make small
| code changes.
| _flux wrote:
| Hmm, looks to me you can also just go and modify the code in
| the editor?
| kittikitti wrote:
| 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.
| rtfeldman wrote:
| 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
| zndbzbz wrote:
| 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.
| cutthegrass2 wrote:
| > 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.
| anamexis wrote:
| Tokens used for user-facing prose are a rounding error for
| coding agents. I don't think there's a conspiracy there.
| dang wrote:
| 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...
| kettlez wrote:
| 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.
| refactor_master wrote:
| 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.
| ncphillips wrote:
| 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?
| anamexis wrote:
| What does jj specifically enable for that workflow?
| ncphillips wrote:
| 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
| wldcordeiro wrote:
| 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.
| NoDodgeQuestion wrote:
| 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
| dzonga wrote:
| 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.
| esafak wrote:
| Has anyone compared this with Cursor's Origin?
| steveklabnik wrote:
| Origin is a platform, this is about storing context in your
| repository directly.
| alansaber wrote:
| 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...
| pbronez wrote:
| Lexfina looks very cool. I need self-hosting to adopt at my
| business.
| computerfriend wrote:
| 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.
| pipes wrote:
| 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 ?
| kittikitti wrote:
| 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.
| subarctic wrote:
| At least traditionally, software engineers avoided everything
| _except_ coding for a long time, but now i guess that 's
| changed
| lnenad wrote:
| 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.
| AlfeG wrote:
| And end up with 3k lines of code + conversation history?
| pipes wrote:
| 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.
| SoftTalker wrote:
| 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?
| waffletower wrote:
| 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.
| dlopes7 wrote:
| It is for when management thinks PRs are "slowing us down" and
| we need to use Delta
| okokwhatever wrote:
| 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.
| the__alchemist wrote:
| 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?"
| prodigycorp wrote:
| Do you have a link to an issue, so I can know if I should be
| worried about this?
| the__alchemist wrote:
| Here: https://github.com/zed-industries/zed/issues/38109
| prodigycorp wrote:
| 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.
| nepthar wrote:
| 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. :(
| phaistra wrote:
| What is that library name? Sounds helpful.
| garrettr_ wrote:
| 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
| subarctic wrote:
| > 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?
| the__alchemist wrote:
| No, but I posted on the existing one. Sounds worth
| trying.
|
| edit: Done
| tarr11 wrote:
| What do you use instead?
| the__alchemist wrote:
| Jetbrains (PyCharm and RustRover) for projects; Sublime for
| one-off files.
| Hamuko wrote:
| The last time I checked out Jetbrains' IDEs, they felt
| heavy as hell to use. Has that changed?
| the__alchemist wrote:
| 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.
| rob74 wrote:
| 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.
| za3faran wrote:
| 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.
| njovin wrote:
| 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.
| etatester wrote:
| 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.
| mattm wrote:
| Don't they have an auto-save setting that you can turn off?
| etatester wrote:
| 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.
| everforward wrote:
| 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.
| FacelessJim wrote:
| > 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?
| prodigycorp wrote:
| 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.
| tyingq wrote:
| 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.
| acedTrex wrote:
| Wow that entire workflow looks absolutely hellish
| lucaprata wrote:
| 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.
| emerongi wrote:
| 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.
| manmal wrote:
| 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.
| FinnLobsien wrote:
| 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.
| dtkav wrote:
| 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.
| ssijak wrote:
| 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.
| ahknight wrote:
| 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.
| abeyer wrote:
| Including non-tracked files that land in your local directory
| even if they're never committed.
| ch71r22 wrote:
| 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
| melodyogonna wrote:
| 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
| ch71r22 wrote:
| 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
| inguz wrote:
| "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.
| RomanKornev wrote:
| 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?
| mhh__ wrote:
| 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.
| RomanKornev wrote:
| 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.
| pedalpete wrote:
| 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.
| bzmrgonz wrote:
| 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.
| Robdel12 wrote:
| 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"
| esperent wrote:
| Really? You don't want to share those messages at the end of a
| long day where where you found yourself typing "STOP! WHAT THE
| HELL ARE YOU DOING THAT FOR? I CLEARLY TOLD YOU..."
| aniceperson wrote:
| github pull requests are not performant. Alternatives that are
| not JavaScript based are welcome. Many projects still use mail
| lists for a reason.
___________________________________________________________________
(page generated 2026-09-19 13:02 UTC)