HN

Comments (110)

• Menu

  tomjakubowski
  I really don't like this. The code I write between commits is my thinking. I think by writing some code out, deleting it, writing again. The code I write that's shipped in commits is written for others to understand, and is a product of that writing for thinking process.I don't want my thoughts to be serialized, version controlled and publicly accessible.https://www.nature.com/articles/s44222-025-00323-4
• Lindby
  All the things in between my commits is a messy soup. Looking there is not useful to anyone. I rewrite my history with git rebase so each commit is small and atomic. The story I create with my commits is what explains why things are as they are, it doesn't matter if it's the true chronological story on how it actually happened.I agree with the author that reviewing pull requests is too late. The problem with pull request is that they make it hard to review individual commits since they are geared towards reviewing the result of an entire branch at once. But the answer is not to share all the noise, it should be to encourage small atomic commits so you can review the early work before the entire feature/fix is complete.
• WorldMaker
  This just sounds to me like "frequent auto-commits" with less trust in git. git can handle frequent auto-commits just fine. If you want to "rollup" frequent auto-commits into "cleaner" top-level commits but also keep all the point-in-time "conversation" of your auto-commits, then `git merge --no-ff` from time to time and use tools like `--first-parent` to focus in on "top-level" commits over "conversation" commits.The git backend already has a ton of "delta DB optimizations" (in git packs and other tools) and it's really just the git frontend that needs a little massaging (`--first-parent`, primarily) and the vast world of "subway-diagram-first/only" Git UIs that should have more "drill down" `--first-parent` counterparts simply because so many people find the subway diagrams ugly/confusing/distasteful.
• thom
  A software team’s job is to collaboratively learn an effective model for operating in a domain. They express that model and those learnings in code, tests and associated documentation. So on the one hand I wholeheartedly agree that pull requests and code reviews fatally undermine this process, but immediately recoil that we’re creating yet more secondary processes and artefacts to distract ourselves. This stuff should all be evident from your codebase. It’s not an extra thing. It’s not a bunch of commit messages or ADRs. If your codebase isn’t entirely self explanatory (both the what and the why) to both humans and AIs you’ve failed and will spend your whole life creating more and more process to manage that failure.
• Menu

  prodigycorp
  I have an uneasy feeling in my stomach because i know anthropic or openai acquiring zed is inevitable. They have too many good ideas and their software is too good.
• mplanchard
  There are so many early-stage startups also competing in this space right now. I’ve been on the interview circuit the past few weeks and talked to at least two. It’s going to be stiff competition for any of these tools to get well-established enough to be successful at a large scale.I can’t help but feel like it is all enabling a level of developer surveillance with which I am deeply uncomfortable, though.
• Xotic007
  A commit is useful because you cleaned it up first. The messing around in between is where you try things and delete the dead ends and most of it is meant to be thrown away. Saving every change and every agent message keeps all that junk around instead.
• jmole
  Google has been doing this for maybe a decade now with citc [0]. I don't know when Gemini is actually going to be taking advantage of this, but I do know that google has essentially a full history at "Ctrl-S" granularity, from ~every developer that works there, for at least 10 years now.If Gemini seems stupid nowadays, it's only because they're being stingy with compute allocation.0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)
• ericyd
  Where are these developers who are willing to talk to you about your code and hash out ideas? Everyone I’ve ever worked with is always too busy, too many other priorities. Sounds nice though.Unrelated: I started using Zed a few weeks ago and really love it, it is everything it promises to be.
• flerchin
  If that works for someone, great. I would never pay for it, and would run not walk away from any shop that asked me to use it. The mess in-between working software is not something I care to have version controlled.
• Menu

  OtherShrezzing
  I don’t see the value proposition here. I’ve seen roughly this feature proposed by multiple companies, and absolutely none of the have given a convincing reason for the technology to exist.
• Menu

  chrishill89
  Many years ago I helped a friend with some draft that had to do with him finishing his doctorate. It ended up being maybe 50-60 between three of us and as fine grained as possible.That agents need something "beyond git" is lost on me but it keeps coming up. For one subject the tool doesn't matter -- in fact it can be obtuse like git or bash and it's fine because agents will handle it. Then for another thing the story is opposite.
• overgard
  I'd have to see the implementation in the editor to really know if I'd want it or not, but my initial impression is that I don't think it's something I would use. I've worked on a couple of products with in-editor collaboration built in (not text editors, but, content creation tools). For the most part collaboration just wasn't something users wanted that much. The problem was that the in-editor collaboration was only really useful for things that were 100% on the web, it never caught on with the more file-centric workflows. It works in something like Google Docs because it's natural that your data is in the cloud there, but for something that lives on your filesystem it feels like it takes extra steps that most people aren't going to be willing to do (especially if they have to use an editor different from their normal one)
• coneonthefloor
  Zed are doing a great job at making the exact things developers don’t want. It’s clear that their focus is on raising funding rather than making a great text editor.
• Menu

  localhoster
  Sad to see zed going the same route everybody is screaming them not to. Altough, I never expected otherwise.
• Menu

  pjm331
  so i think the thing that everyone building these git alternatives is missing is a multi-repo story - unless the expectation is that everyone is going to start operating out of monoreposi've settled on all of this context attached to issues in a project management system and referenced from commitsit works just fine - its not like your agent cannot read your issue tracker
• tengbretson
  This is going to have so many api keys stored in it.
• vitally3643
  Like most/all engineers (I assume), I have entire notebooks that are filled front to back and in the margins with scratch. Random calculations and notes, equations running into each other, any piece of information that was too fleeting to stay in my head or overspill from an already full working memory.Most engineers I know keep such notebooks when they're full, because it's kind of neat to open a random page and see a brain dump scrawled out. Nobody has ever looked at another engineer's scratch notes and drawn useful insight. Frankly, I wouldn't even want to other than for novelty.
• cbovis
  The approach sounds interesting but perhaps still too focused on current development paradigms.Where shared collaboration I think becomes much more interesting is when agents start behaving like a member of your team. Not someone you delegate to, but someone that actively seeks out conversations and interacts with others as though they're just another member of the team.You shouldn't be aware that version control is happening behind the scenes, you're just interacting with a persistent persona through Slack/teams/notion/figma/linear/etc with something that's logging issues, fixing bugs, writing PRDs, designing mockups, etc. The only point at which you know there's version control is when you're asked to review something before it's integrated.
• bison_fan
  Like others, I really like Zed as a text editor. I was a Sublime user before but I switched to Zed because it was even faster and cleaner than Sublime. The multi-buffer editing is a nice step up of multi-cursor editing. I just want a fast text editor with a few conveniences for development.I don't care about any of the collaboration or AI tools that they are working on and I hope that these efforts don't detract from the text editor. At the very least I hope I can hide these features in the UI and continue to ignore them. I also hope that these features don't lead to a bloated, sluggish text editor like VSCode and IntelliJ.
• seanclayton
  > What we're really after is simple: the conversation with the agent becomes the only conversation you need to have.This benefits those who make the machines you have conversations with and those that invest in them.
• jerf
  I would be interested in a clear statement about how this scales. I've not used this workflow myself, but I've seen teams that did it. Whether they got huge benefits out of it I don't know, but I do know that watching them, I was not jealous of what I saw. If I make a change, and I run some tests that were passing a moment ago, and they fail, and the reason why they failed is that Bob hit "save" on his editor (or his editor autosaves) and he made a syntax error in a shared library, and this happened often... I would go insane. I cause enough problems for myself without other people's problems actively intruding at uncontrolled times into my tests.AI's code writing velocity makes this even worse, there's no way I can be simultaneously working on a code base while an AI agent is running around it doing something else.It feels like maybe there's a ghost of an idea here about how to get the best of both worlds, but I'm not sure I follow the throughline on it.
• these
  This seems like a great way to facilitate data gathering for improving LLMs coding performance.If previously you needed to take action 1, 2, 3 to go from state A to B, all you saw was the change from A, B. Now you see intermediates 1, 2, 3 and can train the models to skip straight to B with the added context of the intermediate states.
• amichayg
  This seems like such a weird article. Software is made at build time, which is usually due to a cicd process in place, which is dependent on committing code. It works. There’s no magical way of avoiding the idea that code usually exists in a commit someplace without proper justification.
• Menu

  timuthang
  Music is the silence between notes
• fridder
  Well shoot, they beat me to the punch. I’d been circling around something like this, just not collaborative and obviously more thought out than my random experiments. Minus the collab portions I’m interested to see how it compares to jujutsu
• BigTTYGothGF
  Sounds like "google docs with code formatting".I didn't see anything in there about branching which seems like a big thing not to have.
• abahgat
  I can see how this is a great building block for what Zed is doing around collaboration.One thing I would really love to see, however, is a way to better attach code review comments to the specific version of code they were left on. I find it quite difficult to do with git and github, considering that commit hashes change every time one is forced to rebase (say, for example, to handle a merge conflict).Do you expect DeltaDB to help address this problem?
• shibel
  A bit O/T but:> I have never been a big fan of pull requests.I guess this partly explains why Zed (still) lacks a PR review flow, let alone a coherent one, despite some interest [1]. Pretty much the only reason I’m still with JetBrains.[1]: https://github.com/zed-industries/zed/discussions/34759
• sangeeth96
  This is what I’ve been thinking of ever since coming across Ramp’s agent[1] and other orgs trying to build their own remote dev envs with agents at the center. Makes so much more sense in this kind of a dev spree to not wait for a PR. Because all actors end up repeating the same thing with their own agents which can be totally avoided. Conversations and code to jump in and out of, to collaborate etc seems like the right way to go.Excited to see what Zed team comes up with! :)[1]: https://builders.ramp.com/post/why-we-built-our-background-a...
• ivanjermakov
  Just a stream of thoughts: if git commits were a list of sequential primitive changes instead of diff snapshots, conflict resolution would be trivial in most cases.Not without cons of course: commit byte size, public WIP work and leaked secrets/unwanted edits.
• _pdp_
  What is apparent to me is that we are moving towards dark factories if the promise of LLMs writing most of the code is fulfilled. So this means that it is less about conversations and it is more about iteration.
• opem
  > DeltaDB captures every operation in between and gives each one a stable identityGives jj vibes, interesting!
• Menu

  hyperhello
  I hate software tools now. I really do. A hammer would never ask you to think about it constantly. If you think about your hammer it’s because something is wrong with it.
• lijok
  I swear a lot in my chats with Claude..
• wxw
  Agents can certainly use a new substrate as they can eat dense information quickly.Not convinced DeltaDB is useful for humans directly but assume new and interesting interfaces can arise from the abstractions it provides.Agree that PRs/snapshots is an antiquated way of sharing information.
• gnunicorn
  I totally see where they are coming from, jitsu, too is making every change its own artifact. And it plays hard to the "faster shipping" that especially AI-driven teams are pushing hard, and find the review process to be the next big bottleneck now (as I just saw with my last client as well).There has also been a lot of discussion about the value of the peer review process recently, in in general. But I wonder if this isn't all going into the wrong direction. Quite honestly, even with the previous review and discussion system of (squashed) commits how often did you really use git blame and opened up the original PR discussion of that changed line that caused the bug? And how often did it help you beyond learning it was done by that rockstar developer who has left long ago? And that the discussion on that PR was a point in time and the code around it has evolves beyond that and it would need looking at another 10 PR discussion to get the entire context.What I am saying is that git (and before that Subversion and CVS) has a full history is so that it can resolve the latest state. Period. We made that commit ritual somewhat of a hallmark in putting more supposed meaning into recording ever more in that history. But we rarely stopped to check if that is all that useful. Recording even more, all the time, reminds me of these work group meetings that have minute records of every bike shedding meeting word said by everyone, that, honestly, no one ever looks at after the next meeting ever again. I don't think there is value in minute record keeping, it becomes too much noise that just makes it harder to parse. Now also adding all AI conversation and agent thinking to that tree? What's the value of that in like 3 months down the line? I don't see it.
• Menu

  thesurlydev
  I'm glad to see this feature and looking forward to see how it evolves.Many of the product decisions that Zed's made caused me to switch to Zed for my daily driver IDE (previously JetBrains). The recent AI agent threads and improvements around diffs really solidified the move.
• messh
  Technically, this is true
• bronlund
  Just what we need, a new kind of version control %]
• csours
  The work product is not the work.
• Menu

  axegon_
  I'll probably get more hate for saying this but fine: I use Zed 50% of the time (the other 50% dedicated to vim) for two reasons:1. It is fast and snappy. Nothing comes even close besides vim (and I don't mind going full time to it if I have to)2. The ability to completely shut off and block any slop machine features from interfering with my workflow or leak code back to sloppenai, sloppus or any other self-installed-worst-security-practice-backdoor garbage.Having said that, I hope they don't remove that ability in the future and enforce the "slop is so good man, you should try it" philosophy.
• skydhash
  > Before agents, it was easier to believe that the ceremony of trading comments on snapshots was an effective way to collaborate on software,I’m highly skeptical of this claim. For any complicated feature, there’s always a design doc (or an RFC, or a wireframe) and that’s what people used for discussion. Discussion in a PR are mostly about whether to accept the code, reject the feature, or provide feedback about alternate implementations. It’s not for pair programming or directing design.Collaborating together in a research lab (brainstorm session) is not the same as asking feedback for a journal article (PR). What is described in the article is pair programming with extra steps.
• slopinthebag
  I really like Zed. It's customisable enough for me to make it look how I want, it's faster than every other editor I've tried (scrolling is silk, zero lag anywhere), it has enough features that I don't need an IDE (debugger, refactoring tools), and it generally gets out of my way.I also like the AI tools, the inline assistant is good and the agent is also pretty nice and well integrated into the editor without it being the focus point. I'm not against using AI but I certainly don't use it as much as a lot of people do.That being said, I really dislike this recent push towards becoming more like a cursor wannabe. They have a new (for now) opt-in default layout that almost hides the editor panel in favour of the agent threads and agent panels. And now this. I don't want to switch editors, but if they keep pushing a different workflow from what I use it might send me back to Jetbrains...
• ukprogrammer
  With LLMs now being responsible for the physical typing of code and mundane plumbing tasks, this is a wise direction to go intoOur human ability is not defined by our _absolute_ output, but, by the quality of the _delta_ applied to an engineering artefactGreat engineers obsess over every keystrokeWith LLMs, a much smaller number of keystrokes can create a much larger and more positively impactful deltaEvery delta to the codebase can tell us some informational property about the behaviour of the system and storing that information WILL prove to be useful in the future
• gib444
  Next up: a kit to wire up a developer's brain activity direct to the AI companies, so not a single part of their thought process remains in control of the developer, in order to feed the models. You must brainsignalmaxx 8 hours a day or be fired.Your boss will also demand that you narrate your thought process 8 hours a day. Speakmaxxing will be required to keep your job. There will be a "silence" wall of shame for the non-compliers.
• fHr
  Lmao an ad
• hmokiguess
  [dead]
• yaodub
  [dead]
• yurlyCLOCLOCK
  [dead]