ZedがPull Requestを廃止、Deltaでエージェントと共同開発へ

最初に思ったのは、自分のエージェントと会話することで感じている燃え尽きに加えて、今度はチームメイトとエージェントの会話まで消費して理解しなければならないのか、ということだ。完成した作業を蒸留し、なぜそれが求められたのかを説明する優れたPR説明文よりも、これが優れているのはなぜなのか？

Zedの革新性には拍手を送りたい。

動画で提示されたワークフローは気に入っている。ただし協調的な部分にはあまり関心がない。私は同僚からは洗練された結果を見たいのであって、途中のごちゃごちゃしたものは見たくない。しかし、明らかに非常に有用なのは、レビュアーとしてそのスレッドを持っていればフィードバックループを短縮できることだ。「なぜこうやったのか？」と同僚に聞いて、その同僚がそれをAIに伝えて、返答を待つ、という代わりに、自分で直接確かめて、本当に重要なコメントだけを残せる。これでは学習の機会が失われると言う人もいるだろうし、ある程度は確かにそうだが、それはジュニアの育て方を変える必要があるというだけのことだ。PRのコメントで育てる代わりに、短い通話やオフィスでの雑談に移行するのかもしれない。それはむしろ結構いいかもしれない。

否定的なコメントもあるが、真実はこの業界が変化しており、Zedという会社はそれを活用しなければならないということだ。彼らはお金を稼ぐ必要があり、普通のコードエディタが将来お金を生むと期待するのは自殺行為だろう。

彼らが持ち込む革新は刺激的で新しい。すべてがどうなるかは分からないとしても。

これは現在のPRプロセスに対するクールな拡張に思えるが、根本的にコードを読まなくて済む方法は見当たらないのでは？レビューはそこに最適化されるべきだ。エージェントのおかげで、人間が消化しやすく、理解しやすくテスト可能な論理的な作業の塊を簡単に作れる。開発者としてのあなたの仕事は、チームメイト（そして未来の自分）があなたの変更が何をしているのかを簡単に理解できるようにすることだ――Claudeは10語で済むところを1000語使うのは誰もが知っているからね。

もう一方の側面として、私が一緒に働いてきた高性能なチームはPRレビューを実際には必要としていない。作業は事前に議論されるので、PRレビューの時点ではハンコを押すだけだ。エージェントはそこを何も変えていない――繰り返すが、コードを読んでいない場合を除いて。PRレビューは主に新しい開発者がキャッチアップするためのものだ。信頼があれば本当に速く動ける。

> しかしコードの背後にある意思決定は依然としてレビューが必要だ。小さなdiffではその文脈は提供されない

たぶんこれが単に間違っていると思える部分では？いや、提供される。レビュアーの時間のためにPRを最適化する一環として、その小さな変更が何に向かっているのかを書き出すのだ。単なるテキストかもしれないし、ドキュメントへのリンク、プロトタイプへのリンクなどかもしれない。

いや、人のLLMとの会話なんて見たくもないよ。それは成果物じゃない。変更こそが成果物だ。チームメイトとのSlackの会話を「PR」として添付するようなものだ。

Deltaのベータ版を2週間ほど使っているが、レビューに使うとPR上で直接レビューするよりはるかに改善される。チームメイトのスレッドに飛び込んで、何かがどう作られたかの文脈を見て、それについて質問できるのはとても良い。製品にはまだ粗い部分もあるが、彼らが向かっている方向はかなり面白い。

「イエス・キリスト、Claude、一体なぜそんなことをしたんだ？今すぐ元に戻して代わりにxをやれ」というやり取りも全部公開されるのか？

つまり、存在するものに至るまでの意味のない経路の一部は刈り込まれるのか？彼らが実際に何をレビューできるのか、想像しにくい。

慎ましやかなPRは、このソフトウェアの時代には間違いなく作られていないと思う。

かつては完成した仕事の一部であり、「これが私がこのエンジニアリング課題を解決した方法だ」という意味だった。

チームメイトは通常、そのPRについて、なぜ他の方法ではなくこうやったのか、捨てたアプローチは何かなどを説明できた。

今ではその推論の多くがAIコーディングエージェントの中で行われる。だからたとえアプローチの選択がなされたとしても、PRを提示する人間が各トレードオフやコードの行について同じ深さの理解を持っていることは稀だ。

それ（そして大量のコードを瞬時に生成できる容易さ）が、各PRの意味を薄れさせている。

同僚のAIチャット履歴が欲しいかというとよく分からない（誰がそんなものを全部読む時間がある？）が、革新が起きているのは良いことだ。