--- title: "Software Is Made Between Commits — Zed's Blog" url: https://daily.dev/posts/software-is-made-between-commits-zed-s-blog-85az94983 source_url: https://zed.dev/blog/introducing-deltadb type: article source: "Zed" published: 2026-06-11T15:04:26.338Z updated: 2026-08-16T23:50:54.746Z tags: ["ai-agents", "version-control", "zed"] reading_time: 4 upvotes: 43 comments: 5 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Software Is Made Between Commits — Zed's Blog **[Zed](https://daily.dev/sources/zed)** · 4 min read · 43 upvotes · 5 comments ## Summary Nathan Sobo, founder of Zed, argues that AI agents have made the conversation around code the true source of software, rendering Git's commit-centric model insufficient for modern collaboration. Zed is building DeltaDB, a new version control system that captures every fine-grained operation (not just commits) as addressable 'deltas', and co-locates agent conversations with the code they produce. This allows teammates and agents to collaborate in real-time on evolving worktrees, cross-reference any line of code to the conversation that generated it, and eliminate the need for pull requests as a post-hoc discussion mechanism. A beta is expected in a few weeks with a waitlist open. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 430 comments across lobsters, hackernews (as of 2026-08-16). **TL;DR:** The concept of DeltaDB's keystroke-level versioning and agent-conversation co-location drew heavy skepticism, with many calling it invasive surveillance of a private thinking process, while a smaller group saw genuine value for AI code provenance and auditing; a long tangent about commit hygiene (rebase/squash vs. atomic commits) dominated much of the thread. **Sentiment:** 15% positive · 25% mixed · 60% skeptical **The case for** - Some see clear value in tracking AI-generated code provenance for audits, compliance, and review purposes. - A few think capturing fine-grained history could help forensic debugging (e.g. bisecting into exactly how a bug was introduced). - Some neurodivergent commenters welcomed the idea of not having to mask/polish their thought process before sharing it. **The pushback** - Many feel the messy, in-between code they write is private thinking that shouldn't be surveilled, versioned, or shared with colleagues. - Concern that recording every keystroke/delta could expose secrets, unkind rants about coworkers, or unpolished confusion best avoided. - Skepticism that fine-grained deltas add real value since most of the job is reading/understanding code, not producing it. - Worry the feature is more about employee monitoring, performance review, and layoff justification than genuine collaboration. - Several argue curated, rebased/squashed commit histories are more useful than raw chronological noise. - A similar objection was raised previously about jj's snapshotting granularity, suggesting this isn't a new concern. **By community** - lobsters (skeptical): The single comment notes this idea was previously floated as a joke, implying doubt about the concept's novelty or seriousness. - hackernews (heated): A large, contentious thread split between people who see fine-grained delta tracking as invasive surveillance of private thought and others debating commit hygiene, provenance auditing, and whether messy intermediate work has any value at all. **Hottest debate:** Whether the messy, in-between process of writing code is private 'thinking' that shouldn't be captured and shared, versus something that should be transparent and auditable for colleagues, agents, and employers. **Open questions** - Would DeltaDB's delta-tracking be local-only/private or shared with teammates and employers by default? - How would sensitive information (secrets, rants about colleagues, private thought) be filtered out of the captured deltas? - Is there enough real value in fine-grained delta history to outweigh the noise and privacy concerns, compared to well-curated atomic commits? **Highlights** > Fully agree, very icky surveillance vibes. In particular: > DeltaDB breaks your work into a stream of fine-grained deltas. Where Git captures a snapshot at each commit, DeltaDB captures every operation in between and gives each one a stable identity. I was curious about giving Zed a try, now that it has an emacs keymap. Not anymore. This is such a horribly invasive feature, I absolutely do not want my colleagues reviewing every single intermediate edit, down to the keystroke, that went into the commits I publish for review. Before I put a PR up for review, I'll sometimes edit my commit history a little bit in magit to make it more linear and digestible--maybe update descriptions, squash some adjacent commits together, etc. This just throws that whole aspect of the job out the window and says "hey, colleague, hoover up this firehose of deltas and enjoy it". And what the hell does this even mean? > What we're really after is simple: the conversation with the agent becomes the only conversation you need to have. Lmao. No. Wrong. > — [jcgrillo on hackernews · 2 comments](https://news.ycombinator.com/item?id=48494445) > This sounds like it is more aligned with what I have created which is "We need to capture your conversations with AI". If you look at https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r... you can see that every file has a code block header with a UUID and the AI that was attributed to it. With the UUID, I can tell exactly how the code came about. What they are working on will be more useful for AI code provenance. It is only a matter of time before you are expected to show your chats with AI as part of the code review and for performance reviews. So I don't see human collaboration being the main use case. I see tracking, studying and improving the Human-AI relationship...and seeing if somebody should be promoted or not. An interesting take I've heard is, we will have a token/impact stat where if you spent a shitload of tokens to produce the same impact as somebody else who spent a lot less, you will be the prime candidate for layoffs and/or less pay. This is why I think AI code provenance will become a serious thing in the future. > — [sdesol on hackernews · 2 comments](https://news.ycombinator.com/item?id=48494669) > 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. > — [Lindby on hackernews · 6 comments](https://news.ycombinator.com/item?id=48495593) > This is the response I expected to see here. Reading through the article, I'm reminded of my dismay reading this exact sentiment every time version control is discussed. So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common. My style is to commit often. Like dozens of times per day. Commits are the record of what happened, and I want as much of that record to exist as possible. I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later. That's what source control is for, in my opinion. Finding stuff like that. So many of these things would have been really painful to find if I'd had to sift through every line of a big commit. So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling. But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle. > — [jasonkester on hackernews · 6 comments](https://news.ycombinator.com/item?id=48500874) > This was my problem with JJ as well. I don't want everything in between to be versioned. I'm not even sure, every intermediary state between a commit is relevant or useful. but feels like, I'm in the minority. > — [subygan on hackernews · 2 comments](https://news.ycombinator.com/item?id=48496029) **Source threads** - [lobsters](https://lobste.rs/s/zrntog/software_is_made_between_commits) · 13 points · 2 comments - [hackernews](https://news.ycombinator.com/item?id=48492533) · 319 points · 428 comments ## Community discussion Top comments from developers on daily.dev. **@sarcasmorex** · 1 upvotes > Very interesting stuff! I wonder how merges will be managed. **@andradei** · 0 upvotes > That's quite the task to undertake. Can't wait to see more of it. **@khauma** · 0 upvotes > You love to see it **@rayhanmahmuud** · 0 upvotes > This would be very useful stuff! **@georgesimwanza** · 0 upvotes > cant wait --- Tags: [#ai-agents](https://daily.dev/tags/ai-agents), [#version-control](https://daily.dev/tags/version-control), [#zed](https://daily.dev/tags/zed) [View this post on daily.dev](https://daily.dev/posts/software-is-made-between-commits-zed-s-blog-85az94983)