Zed、AIエージェントと共同開発する新環境「Delta」を発表

AIによるコードの要約を読むのを嫌う人は他にもいるだろうか？コードは簡潔であることがあるが、少なくとも散文に比べれば簡潔だ。LLMがどれほど冗長になり得るかを考えると、数行を説明するために段落を読むことになることがよくある。あるいは逆に、要約が重要なエッジケースや基準を省略してしまうこともある。「その通り、XはYも行う。最初の分析ではそれを見落としていた」というフレーズはあまりにもよくある。

LLMを使ってコードをより読みやすいものに変換し、その逆も行うというアイデアは気に入っている。だが、だらだらとした段落や直線的なリストが最良のターゲットかどうかは確信が持てない。

これは興味深い。関連する2つの機能は、1）リアルタイムのコラボレーションによるマルチプレイヤー会話、2）会話をドキュメントとして扱うこと、つまりエージェントの会話にインラインでコメントできるようにすることのようだ。

（1）については、主な価値はチーム内のジュニアエンジニアや技術に詳しくない貢献者を指導することにあると思う。誰かが雑な結果でPRを出した場合、そのPRを生成したスレッドに実際に飛び込んで、結果がどうやって生まれたかを見たり、次回はどう改善するかをその貢献者にコーチしたりできる。また、作業をある人から別の人に引き継ぐのが簡単になるかもしれない。現在、ほとんどのコーディングエージェントセッションはユーザーごとにローカルだからだ。

（2）については、エージェントの巨大なテキスト応答を消費し、彼らを導くために8つの箇条書きの応答を根気よく書いている自分に気づくことがよくある。それはかなり疲れる。インラインコメントがはるかに良い人間工学を提供するだろう。

とはいえ、Zedは「エージェント型コーディングツール」の議論からほとんど外れており、これはCursor Agents Window、Codex、Claude Codeのようなものを作ろうとする試みのように感じられる。これらの2つの機能は魅力的に思え、他のコーディングハーネスとも互換性があると理解している。しかし、守れる製品になるだけの十分な内容があるかどうかはわからない。これらの機能が優れていれば、他の人がやがてクローンするだろう。

いずれにせよ、これを試してみたい！

本題から外れます：

すみません、投稿を読もうとして頭が沸騰しました。

H1とH2のヘッダーを除いて、ページ上のほぼすべてが超低コントラストです。

暗めのグレーのテキストと色あせたグレーの背景、そして（ほぼ）認識できないハイライトが組み合わさって、読むのがひどく苦痛です。すみませんが、誰かが言わなければなりません。

画像やその中の小さなテキストを見るために目を細めているのは私だけではないはずです。ページデザイン自体はかなりミニマルで、大胆な青いテーマです。タイポグラフィにもう少しコントラストを加えるのは害になるでしょうか？

ありがとうございます

/本題から外れました

1年前にはこれは素晴らしいアイデアに見えたに違いない（彼らはシリーズBで最初に言及した）。

しかし、この12ヶ月で多くのことが変わった。

フロンティアモデルとコーディングエージェントが大幅に進歩し、これにあまり価値を感じなくなった。

DeltaDBベースの機能が、代替手段と比較して本当に何か重要なものを追加するとは思えない。

ここでのゲームは、データを保存し、エージェントセッションを実行するサービスを追加することにあると思う。

これは本当にエキサイティングに見える。エージェント作業をする際の驚くほど大きな痛点は、大きな計画文書の何かにコメントすることだった。コメントをしたいだけで、周囲のテキストを要約して文脈を提供しなければならないことがよくある。ハイライトして「コメントを追加」をクリックしたいだけなのに。

関係ないが、私はZedを使って$jobでのエージェント作業を一元化することを検討している。そこではプロジェクトごとに異なるAPIキーを使用して、支出を属性付けし、プロジェクトごとのデータ保護制御に基づいてモデルの可用性を制御している。試した標準的なUIはどれもあまり機能しなかったが、CLIはほとんど機能する。ZedでACPを使用することで、それをUIの世界に橋渡しでき、かなり満足している。

ベータ版にサインアップしたので、試すのを楽しみにしている。

私はあまり理解できない。これは意思決定の場としてSlackを使うことを思い出させる。詳細を詰めるには確かに機能するが、意思決定の記録を保存する場所としてはあまり良くない。コードが絶えず変化するのに、コードがどのように生まれたかについての何百行もの会話を保存することに何の価値があるのかわからない。5年後にはどうなるのか？何が起こっているのかを理解するために、全トランスクリプトを読まなければならないのか？AIが要約してくれるのか？

これは、プログラミング言語コミュニティに初めて関わり、「これは以前にカバーされた。IRCのチャット履歴を読め」という基本的な質問への答えを受けるような感じだ。

プルリクエストが完璧というわけではないし、規律を持って使えば仕事はうまくいく。しかし、これは間違った方向への一歩のように見える。

LLMに対する個人的な嫌悪はさておき、「会話を保存する」というのが信じられないほど素朴で役に立たないアプローチだと思うのは私だけだろうか？

会話は正当な理由で長く曲がりくねったものかもしれないが、重要なのは最終的に到達した決定と、その選択の理由だ。

プロジェクトがそれらを気にかけるなら、仕様書やドキュメント、ADRに、読者の時間を尊重する簡潔な形で記録されるべきだ。

選択がなぜ行われたかを気にしないのであれば、なぜ派手なデータベースに議論を保存するのか？

みんな、今はちゃんとしたドキュメントを書くのがかっこ悪いと思っているのだろうか？

（最近、LLMチャットに基づいて仕様を自動生成するツール、OpenSpecや社内の同等品などに出会ったが、それらについては言いたいことがたくさんある。明確さがほとんどないのに、冗長さが多すぎる...）