ZedがPull Requestを廃止、Deltaでエージェントと共同開発へ
Replacing Pull Requests with Delta
Zedは、エージェントとのコーディングとレビューを同じ場所で行うマルチプレイヤー環境「Delta」のパブリックベータを公開した。Deltaはコミットやプッシュに依存せず、スレッド単位で共同作業を進める。Zed自身のリポジトリではPull Requestを無効化し、33人が570件の変更をDelta上でmainにマージ済みだ。DeltaDBはGitと互換性があり、既存のワークフローとも併用できる。
私たちは、スレッドがソフトウェア開発の新たな基本単位になると信じており、その状態を最もよくモデル化する方法がデルタなのです。
HNでの議論
52- the__alchemist
私は彼らのエディタとGPUIへの信頼を失った――Zed、君が本命だったのに！ 彼らはこういうのでAIに全振りしている。この記事はgitの一般的な代替についてだと思っていたのに、LLM中心のコーディングの話で、私には意味が通らない。人間が書いたコードとLLMが書いたコードの間に線を引いているが、そんなものは意味のある形では存在しない。
彼らの主力製品であるZedエディタは、ディスク上のファイル同期を誤って管理するため、私や他の人にとって使えない――外部で編集が起きると、エディタは特定のファイルを閉じて開き直さない限り古い状態を保持する（エディタを開き直しても同期されない）。変更が黙って上書きされたりコンフリクトしたりする重大なリスクがある。笑えることに、このリスクはファイルが非同期に変更されたときに高まるが、私の場合それはほとんどpullやLLMの編集によるものだ！
「コーディングが変わってLLM中心のソース管理ツールを使うべきなら、なぜLLMは閉形式の解があるソフトウェアの重大なバグを修正できないのか？」といった疑問が湧く。
- pipes
最初に思ったのは、自分のエージェントと話すことで感じている燃え尽きに加えて、今度はチームメイトのエージェントとの会話を消費して理解しなければならないのか？ということ。完了した作業を蒸留し、なぜそれが要求されたかを説明する良いPR説明より、これが優れているのはなぜか？
- kettlez
私はDeltaのベータ版を数週間使っているが、レビューに使うとPR上で直接レビューするよりはるかに改善される。チームメイトのスレッドに飛び込んで、何かがどう作られたかの文脈を見て、それについて質問できるのはとても良い。製品にはいくつか粗い部分があるが、彼らが向かっている方向はかなり面白い。
- tyingq
私の「イエス・キリスト・クロード、一体なぜそんなことをしたんだ？ 今すぐそれを元に戻して代わりにxをやれ」というすべてを公開するのか？
つまり、存在するものへの意味のない経路の一部を刈り取るのか？ 彼らが実際に何をレビューするのかを可視化するのは難しい。
- zndbzbz
これは現在のPRプロセスへのクールな拡張のように思えるが、根本的にコードを読まなくて済む方法は見えない？ レビューはそのために最適化されるべきだ。エージェントは、人間が消化しやすく、理解しやすく、テストしやすい論理的な作業の塊を非常に簡単に作る。開発者としてのあなたの仕事は、チームメイト（そして未来の自分）があなたの変更が何をしているかを理解しやすくすることだ――なぜなら、クロードは10語で済むところを1000語使うと誰もが知っているから。
もう一方の端は、私が働いてきた高性能チームはPRレビューをほとんど必要としない。作業は事前に議論されるので、PRレビューの時点ではゴム印になる。エージェントはそれを何も変えなかった――繰り返すが、コードを読んでいない場合を除いて。PRレビューは主に新しい開発者が追いつくためのものだ。信頼があれば本当に速く動ける。
> しかしコードの背後にある決定は依然としてレビューが必要だ。小さな差分はその文脈を提供しない
多分これが単に間違っていると思える部分？ いや、提供する。小さな変更が何に向かっているかを、レビュアーの時間のためにPRを最適化する一環として書き出す。それは単なるテキストかもしれないし、ドキュメントへのリンク、プロトタイプへのリンクなどかもしれない。