ソフトウェアはコミットの合間で作られる

• DeltaDB は、エージェントとの対話と、エージェントが編集したワークツリーをあわせてバージョン管理する新しい形のバージョン管理システムである
• Git は個々の コミット を中心に構成されており、コードが継続的に変化しているあいだに続く対話とコード変更を一緒に扱うようには設計されていない
• DeltaDB はコミットだけでなく、作業中に発生するすべての操作を細かな デルタ のストリームとして記録し、各デルタに安定した識別子を付与する
• メッセージと、そのメッセージが生み出した編集が並んで記録され、複数の人やエージェントが別々のマシンから同じファイルを同時に編集できる
• コラボレーションは、コミットやプッシュ後のレビュー手順よりも、コードが作られている最中の 対話 とワークツリーの中で、より直接的に行える

---

背景と問題意識

• Zed チームはプルリクエスト方式に馴染みがなく、同じワークツリーで一緒に作業しながら、コードを書いている最中に議論するやり方で信頼と共通理解を築いてきた
• GitHub ではコミットしてプッシュした後でなければコードについて話せないが、Zed チームの重要な対話はたいていその時点より前にすでに終わっていた
• Zed は 2021 年にコミットの制約を超えるために始まり、まず世界最高の開発者にふさわしいエディタを作り、その中でより良いコラボレーションの方法を提供しようとしてきた
• 人間同士の協業という文脈で長く考えてきたこの問題は、エージェントと協業する際にはさらに重要になった
• コードを生成する 対話 が、ますますソフトウェアの実際の源泉になりつつあり、その対話は継続的に展開し変化するコードと相互参照されなければならない
• Git は個々のコミットを中心に構成されているため、このような継続的な対話とコード変化の結び付きを支えるようには設計されていない

DeltaDB と次のステップ

• すべてのコミットではなく、すべての操作

  • DeltaDB は作業を細かな デルタ のストリームに分解し、Git がコミットごとにスナップショットを保存するのとは異なり、コミットの合間にあるすべての操作を記録する
  • 各デルタは安定した識別子を持つため、コードが変化し続けている最中でも、その進化過程の特定の瞬間を指し示せる
  • ワークツリーは変化していく過程そのものがバージョン管理され、その変化を導く対話とともに扱われる
  • メッセージと、そのメッセージが生み出した編集は並んで記録され、互いに切り離されない
  • DeltaDB には競合のない複製ワークツリーが組み込まれており、複数の人やエージェントが別々のマシンから同じファイルを同時に編集できる
  • ファイルは実際のファイルであり、エージェントはターミナル経由でファイルを操作し、ユーザーは必要に応じてワークツリー全体をディスクにマウントして自分のツールを使える

• ソースコードは今やソース対話

  • 参照は行番号ではなく デルタ に固定されるため、コードが下方へ移動しても参照は維持される
  • 過去の対話のどの行からでも、現在のコードの状態や、エージェントがその当時に書いていたコードへ移動できる
  • どのコード行からでも、そのコードを生んだ対話と、その後そのコードに触れたすべての対話をたどれる
  • エージェントもこの情報を活用し、自分が触っているコードの背景コンテキストを取り込める
  • エージェントは、以前そのコードで作業したエージェントを呼び出し、なぜそのような書き方になったのかを尋ねられる

• コラボレーションのためにコミットする必要はない

  • エージェントとの対話が、協業に必要な唯一の対話になることが目標である
  • チームメンバーは作業がまだ進行中の段階で参加し、作業を行ったエージェントと対話しながら、進行中にコメントを付けられる
  • 参加のために、まずコミットやプッシュを待つ必要はない
  • プルリクエスト、レビュー スレッド、インラインコメントは、コードと議論が別々の場所にあったため、後から議論をコードに結び付け直すための手順だった
  • コードと議論が同じ場所にあれば、そのような手順はなくなる
  • Git や CI は、チェックを実行し外部世界と接続する役割にとどまり、コラボレーションが強制的に起こる場所ではなくなる

• 次のステップ

  • ソフトウェアはもはやコミットではなく 対話 の中で形を成していく
  • DeltaDB はそのためのバージョン管理システムであり、数週間以内に初期ユーザーへ提供される予定である
  • 先に試してみたい場合は、ウェイトリスト に登録できる

[GN⁺]

Hacker Newsの意見

• コミット間の作業物は雑然としたスープなので、のぞいても誰の役にも立たない。git rebaseで履歴を書き直して各コミットを小さく原子的にし、コミットが作る物語によって、なぜ今の形になったのかを説明する
  実際にどんな時系列で進んだかは重要ではない。プルリクエストのレビューが遅すぎることには同意するが、問題はプルリクエストがブランチ全体の結果を一度にレビューするよう設計されていて、個々のコミットレビューが難しいことだ。解決策はすべてのノイズを共有することではなく、機能や修正が終わる前に初期段階の作業をレビューできるよう、小さく原子的なコミットを奨励する方向であるべきだ

  • ここのコメントや自分の職業ネットワークを見ると、人々はだいたい二つの陣営に分かれる。一つはGitを雑な自動保存のように使ってマージ時にまとめる側、もう一つはきれいに整理された完全動作する原子的コミットを好む側だ
    私の経験では1番のほうが一般的だが、GitHubが自然にその方式をよりよく支援していて、累積コミットが2番の一部の問題を解決できるからかもしれない。選べと言われたら、1番のほうがずっと理にかなっていると思う
  • それはPhabricatorやGerritのようなツールの問題ではなく、ただのGitHubの問題ではないか？
  • 雑然としたスープであろうとなかろうと、ディスクやコストが問題でないなら、誰か—おそらくエージェント—が自分のやったことを見ること自体は構わない
    強い確信があるわけではないが、エージェントは一部の人にはノイズでもある追加情報を好むと思う
  • こういう反応が出るだろうとは思っていた。この記事を読みながら、バージョン管理の話になるたびに同じ感情を見て落胆した記憶がよみがえった
    あまりに多くの人が、記録を「きれいに」見せるために簡単に捨ててしまう。理にかなっていないが、妙にありがちな特定のプログラマー的ロジックには合っているように見える
    私のやり方は、一日に何十回も頻繁にコミットすることだ。コミットは起きたことの記録であり、その記録はできるだけ多く残しておきたい。git bisectが一見何の問題もなさそうな1行だけの小さなコミットを指し示し、ずっと後になって見つかった微妙なバグを見つけてくれたことが何度もある
    私の考えでは、ソース管理とはそういうものを見つけるためにある。大きなコミットのすべての行を掘り返さなければならなかったなら、こうした問題はずっとつらいものになっていただろう
    だから、人々がPR全体の分量のコミットをわざとひとまとめにしてマージし、バージョン管理の唯一役に立つ部分だと私が思うものを捨てているのを見ると、本当に理解できない。親コメントのような陣営も多いので、筆者のより細かな記録計画は簡単な戦いにはならなそうだ
  • あなたのコミットの使い方は、私が会社でスタック型PRを使うやり方に似ているように聞こえる
    良いコミット衛生はチーム単位で強制しにくいが、不思議なことにPRレベルでは人々は良い説明を書き、変更のまとまりをきれいに保つことにはかなり協力的だ

• これはGitへの信頼がやや低い頻繁な自動コミットのように聞こえる。Gitは頻繁な自動コミットを十分うまく扱える
  頻繁な自動コミットをより「きれいな」上位コミットへと巻き上げつつ、時点ごとの自動コミットの「会話」を保存したいなら、ときどき git merge --no-ff を使い、--first-parent のようなツールで「会話」コミットより上位コミットに注目すればよい
  GitバックエンドにはすでにGit packや他のツールにデルタDB最適化が多く入っており、実際に少し手を入れるべきなのはGitフロントエンド—主に --first-parent —と、数多くの「路線図優先／専用」のGit UIだ。多くの人はその路線図を醜く、混乱し、不快に感じるので、--first-parent に対応するドリルダウンUIがもっと必要だ

  • 私もそうしている。ブランチのコミットは普段は見ないが、必要なら残っている。git blame も --first-parent を使うよう設定できる

• 「ソフトウェアはコミットの間で作られる」には同意するが、「DeltaDBが各コミット間のすべての作業をキャプチャする」には同意しない
  まず、侵襲的に感じる。作業中ずっと24時間動いている画面録画機も欲しくない。自分のミスが見えること自体が悪いわけではないが、きちんと仕事をしているなら、自分が生み出した価値はコミットに含まれており、そのほうがずっと侵襲性が低く感じられる
  次に、私は複数のツールを使っており、そのすべてを変なDBに統合したくない。ある時点で「外部プロセスが何かをした」で終わるなら、すべてをキャプチャする意味は何なのか？ Zedが多くのものを統合できるのは良いことだが、Zedに統合されたものを全部使うという意味ではない。最後に確認したとき、ZedでACP経由でClaude Codeを使うと、以前のメッセージを巻き戻して修正することすらできなかった
  最後に、個人的には私たちはすでにコミットの本質を見失っていると思う。大半の人は任意の無制限な変更の塊を作ってから git commit を実行し、その変更の塊は巨大なひとかたまりとしてレビューされ、その後コミットは潰される。世界の終わりというほどではないが、手で丁寧に作られたコミットは本当に素晴らしい。こういうやり方を強制するプロジェクトで git blame を実行してみれば、言いたいことはすぐわかるはずだ
  DeltaDBのようなものは、コミットを雑にまとめる慣行をさらに強め、固定化するだけだ。何が起きたのか知りたければ、今度はユーザーがLLMと交わした会話を覗き見るように再生すればよい、という話になる
  最後の点は興味深いが、いら立ちもする。チームメイトの助けになる良い工学的実践だという理由だけでは、変更内容や動機を文書化するよう説得できなかったのに、誰もがLLMには喜んで説明する。LLMが仕事をしてくれるにはそれが必要だからという面が大きいが、以前ならやらなかったことをLLMを満足させるためにどれほど多くやるようになったのかは興味深い。突然、妙に文書化されていなかったものがCLAUDE.mdに文書化されるようになる

• コミット間で書くコードは自分の思考過程そのものだ。コードを書いて、消して、また書きながら考える
  コミットとして運ばれていくコードは他人が理解できるように書いたものであり、考えるために書く過程の成果物だ。自分の思考がシリアライズされ、バージョン管理され、公開でアクセス可能になることは望まない
  https://www.nature.com/articles/s44222-025-00323-4

  • JJについても同じ問題があった。コミット間のすべてがバージョン管理されることは望まない
    コミット間のすべての中間状態が本当に関係があるのか、有用なのかも確信がない。ただ、自分が少数派のようには感じる
  • だからPR前にrebaseを使うし、squashは嫌いだ。2年後にはなぜそのコードをそう書いたのか覚えていないだろうし、バグを理解してチェスタトンの柵の状況を見分けるには、デルタとコミット履歴しかない
    squashしてしまうと、あなたが「一度に」書いた400行のコードと、そのコードに割り当てられた機能リクエストだけが文脈として残る。何の助けにもならない
    最悪だった人は、新しいモジュールを書きながら、ある程度動くまで何もチェックインしなかった。自分のコードのバグを先に言わずにこっそり直していた、その脆い自尊心ともつながっていた気がする。彼はKernighanの法則が表れる難解なコードを書いていて、そんなことをするには10年は余計に経験があった。自分のコードが「強力だ」と自慢していたが、それは褒め言葉ではなく前兆だ。初期コミットのコードからバグを何度も見つけた。頼むから何かしら残してほしいという気持ちだ
    問題を見つけるまで何でも試したからといって、それを告白する必要はない。B地点に到達できると分かった後で、AからBへ進む望ましい物語を作ればいい。最初から正確に何をすべきか分かっていたならこう書いただろう、という形でコミットを並べ替えればいい。書いてすぐ消したコードの90%や、その筋書きを支えないものは捨てればよい
    法執行には並行構成というものがある。法廷で許容されない事実によって容疑者が有罪だと分かっていても、同じ事実を手続きに従ってもう一度発見しなければならない。ごみ収集日にごみを確保し、近隣住民に聞き取りを行い、捜索令状を取るのに十分な状況証拠を集めたうえで、その証拠を再発見するようなものだ
  • 主にAIエージェントを念頭に置いているように見える。以前見たことのある面白いアイデアで、みんながAIのために何かを再発明しようとしている空気は面白い
    ただ、単にテキストファイルを作ってコミット参照を入れればよいのではと思っていて懐疑的だ。Fossilを使ってはいけない理由も分からない。SQLiteデータベースなので、すでに欲しいものをひとまとめにできるし、コミットを参照できるありとあらゆる機能が組み込まれている
  • コラボレーションの部分には懐疑的だが、企業顧客向けの機能のように聞こえるので意図は理解できる
  • 完全に同意する。監視の感じが非常に不快だ。特に「DeltaDBは作業を細かなデルタストリームに分解する。Gitが各コミットのスナップショットをキャプチャするのに対し、DeltaDBはその間のすべての作業をキャプチャし、それぞれに安定した識別子を付与する」という部分がそうだ
    Zedにemacsキーマップができたと聞いて一度使ってみようかと思ったが、もうない。これはあまりにもひどく侵襲的な機能で、レビューのために公開したコミットに至るまでのすべての中間編集を、同僚がキーストローク単位で検査するのはまったく望まない
    PRを出す前には、magitでコミット履歴を少し整えて、より線形で消化しやすくすることがある。説明を書き直したり、隣接するコミットをまとめたりする感じだ。ところがこの機能は、そうした仕事の一側面を丸ごと投げ捨てて、「同僚よ、このデルタの消防ホースを吸い込んで楽しんでくれ」と言っているようなものだ
    「私たちが本当に望んでいるのは単純だ。エージェントとの会話が、あなたに必要な唯一の会話になることだ」という文は、いったいどういう意味なのか。いや、違う

• AnthropicやOpenAIがZedを買収するのは避けられないように感じられて気分が悪い。アイデアが良すぎるし、ソフトウェアも良すぎる

  • ZedのコーディングハーネスはClaude Codeよりずっと良いが、Claude APIを直接使うのでずっと高い。同じ製品群の中に入れば、製品カテゴリを定義するレベルになり得る
  • なぜZedで止まるのか。AI企業が集めた1兆ドルの投資資金は名目上はデータセンター向けだったが、コストが上がり、完成スケジュールが一般的な事業計画の範囲を超えるなら、その金を別の場所に使うほうが効率的だ。1兆ドルあれば欲しいものは何でも買える
  • AnthropicやOpenAIが向かおうとしている先には、もはやエディタはないように見える。個人的には、より良い読み取り専用コードツール、あるいはUMLの復活を望む

• 今この分野で競争している初期スタートアップは本当に多い。ここ数週間で面接を受ける中で、少なくとも2社と話した
  こうしたツールが大規模に成功するだけの地位を築くには、競争は非常に激しいだろう。ただ、このすべてが、自分には非常に不快に感じられるレベルの開発者監視を可能にしているように思えてならない

  • 管理者が自分の配下にいるすべての開発者のキーストロークを全部監視することに時間を使い切るなら、本来やるべき仕事や気にすべき事業上の問題がなさすぎるということだ

• コミットは先に整理してあるから有用だ。その間の試行錯誤は、何かを試して行き止まりを消す場所であり、ほとんどは捨てられるべきだ
  すべての変更とエージェントメッセージを保存すると、そのゴミが残り続けるだけだ

• Googleはcitcでおそらく10年ほど前からこれをやっていた。Geminiが実際にいつこれを活用するのかは分からないが、Googleは少なくとも10年間、ほぼすべての開発者の履歴をCtrl-S単位で事実上完全に持っている
  今Geminiが間抜けに見えるなら、それは計算資源の割り当てを節約しているからにすぎない
  0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

• ここでの価値提案が何なのか分からない。複数の会社がだいたいこうした機能を提案しているのは見てきたが、この技術が存在すべき説得力のある理由を示したところは一つもなかった

  • あなたの経験やワークフローが私のものとこれほど違うのは興味深い。これは、私が毎日直面している現実の問題を解決すると主張する機能だ。
    私たちの会社は完全リモートで、同僚のほとんどは私の近くには住んでいない。1日に数回ビデオチャットはするが、主なコミュニケーションは Slack だ。
    私たちは、良いコードを書くためのLLMエージェントを導入する流れの中でもかなり先行している。優れたモデルと特定のコーディングハーネスの非常に優秀なセーフガードのおかげで、最近では LLM が私たちのコードの大半を書いている。
    普通の一日は、チケットを一つ取って LLM に向け、一緒に問題を解き始めるところから始まる。アーキテクチャの決定を行い、計画を立て、実行する。直近でデプロイした機能のトークンコストは 19 ドルで、佳境では LLM が私の入力なしで 30 分ほど作業を続けていた。
    どの方向がより良いのか確信が持てないときだけ、チームチャットに質問を投げて同僚の意見を求めることもある。だが、多くのチケットは完全に自律的に終わる。
    その後 PR を開き、Slack に PR リンクを貼ってレビューを依頼すると、同僚はその時点で初めて実装を見ることになる。同僚が質問することもある。素早いリアルタイムの会話には GitHub のコメントはあまり向いていないので、PR コメントより Slack スレッドに質問を投稿することが多い。
    その質問への答えは私のノートPCにある LLM とのチャットログの中にあるが、同僚に簡単に見せる方法がない。だから、同僚の質問を Slack から LLM チャットへコピーし、返答をまた貼り戻すという伝言ゲームをすることになる。
    同僚と LLM と私の全員が、同じ会話にもっと簡単に参加できるというアイデアは非常に魅力的だ。
    だからといって Zed チームの方向性が正しいという意味ではないし、私たちのチームが別のやり方で働いた方が良いのかもしれない。だが、現在のアプローチがあまりにも「成功」しているので、組織として変える圧力はほとんどない

• ソフトウェアチームの仕事とは、あるドメインで効果的に機能するモデルを協力して学習することだ。そのモデルと学びを、コード、テスト、関連ドキュメントとして表現する。
  だから一方では、プルリクエストとコードレビューがこのプロセスを致命的に損なっているという点に完全に同意する一方で、すぐに別の副次的な手続きや成果物を作って私たちを散漫にさせるという発想には身構えてしまう。こうしたものはすべてコードベースの中に現れるべきだ。
  別の何かであってはならない。コミットメッセージの束でも、ADR の束でもない。コードベースが人間と AI の双方に対して、何を、そしてなぜを完全にそれ自体で説明できないなら失敗であり、その失敗を管理するために一生さらに多くの手続きを作ることになる。

  • 機能や実験のための安価なブランチ作成、特定のコミットを素早く取り消せる能力、ある1行のコードが最後に変更されたときのコミットメッセージを読むことは、どれも非常に重要であり、分散バージョン管理システムが可能にしたものだ。
    現在のコードの状態だけでは、現代のソフトウェア開発には十分ではない