HN Debrief

Software is made between commits

  • AI
  • Developer Tools
  • Programming
  • Open Source
  • Privacy

Zed’s post argues that Git commits and pull requests are too coarse for AI-assisted development. DeltaDB is their answer: a system that tracks operations between commits, gives those deltas stable identities, and aims to make live collaboration with teammates and coding agents the primary workflow instead of reviewing finished snapshots after the fact. The pitch is not just finer version control. It is a shift in where software history lives, from curated commits to the full stream of edits and agent conversation that produced them.

If you are evaluating AI-native dev tools, separate the genuine need for earlier collaboration and audit trails from the much bigger question of whether you want to retain and expose raw working state at all. Teams that like this direction should define strict boundaries around locality, sharing, and secrets before the tooling makes that decision for them.

Discussion mood

Mostly negative and uneasy. People liked Zed as a fast editor, but saw DeltaDB as invasive, noisy, and security-sensitive, with a weak case for human collaboration and a much clearer case for employer oversight, AI audit trails, or model training.

Key insights

  1. 01

    Agent chat already holds review context

    For teams that let LLM agents do most of the implementation work, the missing context often lives in the chat that produced the code, not in the diff itself. That makes review clumsy because teammates ask questions in Slack or on the PR, then someone manually relays those questions back to the model and pastes answers out again. In that workflow, a shared record tying code, agent conversation, and reviewer questions together is not surveillance theater. It removes a real handoff problem created by agent-heavy development.

    If your team already ships through long agent sessions, measure how much review time is wasted reconstructing those sessions from memory or chat fragments. A tool like this only earns its keep if it replaces that manual relay loop, not if it simply records more exhaust.

      Attribution:
    • teach #1
    • jimbokun #1
  2. 02

    The strongest fit is AI provenance

    The clearest practical use is proving how AI-generated code came to exist. Several commenters connected DeltaDB to audit trails, prompt capture, referenced documents, reproducibility, and even legal or performance-review uses. That changes the product category. It stops being a nicer way for humans to collaborate in an editor and starts looking like governance infrastructure for agentic software teams.

    If you are buying into AI-heavy delivery, expect provenance requirements to show up from security, legal, or management before developers ask for replayable edit history. Plan for retention, access control, and review policy now, because those constraints will shape the tool choice more than editor UX.

      Attribution:
    • sdesol #1
    • selicos #1 #2
    • fridder #1
    • these #1
  3. 03

    Curated commit history still does real work

    Several experienced Git users pushed back on the idea that the space between commits should become the main artifact. Their point was sharper than simple nostalgia. Small atomic commits, rebasing, and preserved branch history already give teams a way to expose useful reasoning while stripping out dead ends. That curation is not cosmetic. It is the mechanism that turns messy exploration into history future maintainers can actually navigate with `git blame` and targeted log views.

    Before adopting a new history substrate, test whether your real issue is poor commit hygiene and squash-heavy workflow. Better commit structure may recover most of the explanatory value you want without creating a permanent record of noise.

      Attribution:
    • WorldMaker #1
    • Lindby #1
    • hinkley #1 #2
    • sharts #1
  4. 04

    Per-repo history misses cross-repo work

    A concrete limitation surfaced around multi-repo changes. Many real features span several repositories plus issue trackers, chat, and agent config. If the new source of truth is still scoped to one repo at a time, it optimizes the wrong boundary. The work trace people actually need is often attached to the issue or project workflow, not just the local code history.

    If your organization regularly lands changes across services or repos, ask for the cross-repo story first. A tool that captures only one repository’s edit stream will not replace the systems where the actual coordination already happens.

      Attribution:
    • jackxlau #1
    • pjm331 #1
    • QuercusMax #1
  5. 05

    Semantic checkpoints beat raw edit streams

    A better abstraction emerged than keystroke history. What humans and agents often need is not every intermediate move, but named checkpoints like "this approach failed" or "this version restored performance" plus durable markdown context next to the code. That preserves intent without forcing reviewers to sift through rabbit holes that no longer represent the final solution.

    Favor workflows that let developers promote moments of real significance into persistent context. If a system cannot compress raw exploration into semantic milestones, it will drown people in history that only a model has time to read.

      Attribution:
    • softwareseko #1
    • jumploops #1
    • jcgrillo #1
  6. 06

    Google already proved the storage side

    Google was cited as having near save-level source history for years through its internal tooling. That undercuts any claim that fine-grained version capture is a radical technical breakthrough. The hard part is not storing the data. It is deciding what value to extract from it, who gets to see it, and how to keep it from becoming another giant unread archive.

    Treat fine-grained history as a product and policy question, not a database novelty. Ask what workflows improve on day one, because "we can record everything" is the easy part.

      Attribution:
    • jmole #1

Against the grain

  1. 01

    Stable identities could fix review drift

    One practical pro-DeltaDB argument focused on code review comments that break when rebases rewrite commit hashes. If edits had stable identities independent of Git hashes, review discussion could stay attached to the exact code it referred to even as history is cleaned up. That is a real pain point in today's review tooling, especially on long-lived branches.

    Even if you reject full edit-stream capture, watch for ideas that decouple review context from Git object identity. Better anchoring of comments to evolving code could be valuable on its own.

      Attribution:
    • abahgat #1
  2. 02

    Engineering sometimes needs the process record

    A minority view held that hidden process is exactly the problem with software engineering. If teams are making architecture, latency, and capacity decisions, they should be able to show how they reasoned about them, much like other engineering disciplines keep more explicit records of assumptions and checks. From that angle, the mess is not embarrassment to hide. It is evidence that standards were or were not followed.

    For safety-critical or compliance-heavy systems, do not dismiss process capture outright. You may need a structured way to preserve design reasoning even if keystroke-level history is the wrong format.

      Attribution:
    • skydhash #1
    • 8note #1
  3. 03

    Agents may benefit more than humans

    Some supporters accepted that people may never want to read raw deltas, but argued that agents can. A dense stream of edits, plans, and reversals might help models collaborate earlier, avoid duplicated work, and learn from the path between states rather than only the before and after snapshots. In that framing, DeltaDB is a machine-native substrate first and a human interface problem second.

    If you are building agent-first workflows, evaluate these systems by whether they improve agent coordination and handoffs, not whether they look elegant to human reviewers. The winning interface for people may sit on top of a history format they never inspect directly.

      Attribution:
    • sangeeth96 #1
    • wxw #1
    • ukprogrammer #1

In plain english

--first-parent
A Git log option that follows only the main line of merges, hiding detailed side-branch history unless you drill down.
agentic
Describing AI systems that act with some autonomy by planning and carrying out multi-step tasks.
DeltaDB
A Zed system described in the post that records fine-grained editing operations and agent interactions between Git commits.
git
A version control system that tracks changes to code and keeps history such as commits and earlier versions.
git blame
A Git command that shows which commit last changed each line of a file.
Jujutsu
A version control tool, often shortened to jj, that keeps more granular local history and works alongside Git.
LLM
Large language model, a type of AI system trained on large amounts of text to generate and analyze language.
PR
Public relations, the practice of managing a company's public image and media coverage.
provenance
A record of where something came from and how it was produced.
Slack
A workplace messaging tool commonly used for team chat.

Reference links

Version control and development tooling

  • Piper source control system
    Referenced as background for Google’s long-running fine-grained internal source history.
  • Jumploops chum
    Shared as an example of markdown-based context hierarchy and live documentation alongside code.
  • Gram editor
    Mentioned as a Zed fork positioned against AI integration.
  • Module Collective moe
    Offered as a personal-use alternative for storing conversations and notes in a separate Git repo under user control.
  • Zed PR review discussion
    Linked as evidence of user interest in pull request review support inside Zed.

AI provenance and agent workflows

Related reading

  • Nature article
    Linked while arguing that intermediate coding work is private thinking and should not be broadly serialized or shared.