HN 日本語サマリー

← 一覧へ戻る
AI・機械学習

知識のチップカッター:エージェントによるコーディングの物語

The Knowledge Chipper: An Agentic Coding Story (jg.gg)

9 pointsby jgbbrd1 コメント

要約

AIエージェントがコード変更を行う際、問題解決のために大量の知識(ファイルスキャン、APIドキュメント検索など)を構築しますが、その知識の多くはセッション終了とともに失われてしまいます。これは、開発者が詳細なメンタルモデルを構築しても、その知識が消えてしまうのと似ています。この知識の喪失は、コードレビューの困難さ、チーム間のコンテキスト共有の非効率性、そしてLLMのポータビリティの重要性を浮き彫りにしています。

全文翻訳

私の日常の開発作業では、エージェントが設定した問題について信じられないほどの量の知識を構築する必要があることに気づきます。彼らはファイルをスキャンし、APIドキュメントを検索します。実際のコード変更に使われる比較的少量の最終トークンを吐き出すために、かなりの作業を行います。これは、開発者が多くのコードを読み、システムの動作について非常に詳細なメンタルモデルを構築し、その後必要なファイルだけを編集するのと似ています。そして(ほぼ)すべての知識は…消えてしまいます。私がここで書いていること(特にミーム)は、このカートゥーンストリップに触発されています。今日の世界との違いは、プログラマーが中断されるというよりも、LLMが行った作業の大部分が実質的に失われてしまうことです。確かに、賢いプログラマーはしばしばLLMにコミットメッセージを書かせます。それは良いことです。そしてはい…あなたは自分のマシンでセッションを再開できます。しかし、これはLLMが構築した状態の完全性を捉えるには、まだほど遠いです。そして、その作業をどこから引き継ぐかという点で、それは制度的知識、セッションの再開可能性、そして効率性の大きな損失です。私は最近、「The Session You Cannot Take With You」(HNでの議論はこちら)を読み、それが私の心に深く響きました。これを読む前は、仕事の助けにプロプライエタリなAIツールが関わることに特に反対していませんでした。しかし、この記事は、エージェントがブラックボックスであることが実際にどれほど有害であるかを本当に明確にしています。真剣に考えてみてください。たとえば、あるチームメイトがCodexを好み、別のチームメイトがClaudeを使用しているという単純なこと。一方のLLMは豊かなロジックの絵を描くために懸命に働きます。次に別のLLMが同じコードに取り組む必要があり…完全にゼロから始めます。私はこの方法で燃え尽きる数百万のトークンを推定できません。「LLMポータビリティ」という概念は、正直言って少し大げさに聞こえました。モノモルフィズムのように。あるいはグルテン不耐症のように。しかし、偶然にも、今週初めにドバイにいる技術系の友人と電話で話していました。彼はAWSのバーレーンデータセンターでの大惨事について説明していました。彼が指摘した興味深い点は、その地域の多くの企業が、AIの使用を別の地域で実行させることを絶対に許可できないということです…まあ、戦争のためです。それで、あるサービスの地域全体がその戦争のために大規模に混乱したとき…突然、LLMのポータビリティははるかに現実的で緊急のものになります。私のチーム全体はほとんどClaudeを使用しています。私は、さまざまなLLMを互いに、また連携して試す熱心な導入者だと思います。Googleのエージェントが私がコミットする前にClaudeの作業をレビューしてくれるのは、何かが正しいと感じます。しかし、LLMが協力して作業することも、新しいセッションを開始したり「git commit」を実行したりするたびに、どれだけのコンテキストを捨てているかを実感させてくれます。そして今、最先端の話題について話しましょう。Claudeがオフラインになったので、CodexにClaudeが開始した場所を引き継いでほしい場合はどうなりますか?あるいは、Claudeと私がすでに多くの作業を行ったコードベースの領域で、他のモデルの1つを試したい場合はどうなりますか?トークンを何度も燃やすことなく、中断したところから再開できることを本当に望んでいます。この問題は、大規模なチームではさらに深く広がります。コードレビュー担当者(人間であれ、そうでなくても)は、コード変更の背後にあるすべてのニュアンスにどのように追いつくことができるでしょうか?OpenAIで働いていた私の友人Philipは、AIが人間の能力をはるかに超える時代におけるコードレビューについて、非常に興味深い記事を書きました。これはここで非常に適切だと感じます。今日現在、十分にニュアンスがあり、十分に大規模なコード変更を提示することが可能であり、それらをレビューするのは非常に困難です。そして、コンテキストの多くが開発者のマシンに残されているため、トークン燃焼の唯一の痕跡はコミットメッセージと、LLMが適切だと判断したコードコメントの量だけです。LLMが登場する前でさえ、急速に変化するプロジェクトのテックリードであることは困難な仕事でした。今では、すべてのPRは、(半)文書化されていない複雑さの、新たに鋳造された小包です。大量の新しいプライバシーロジックをバイブコーディングしたジュニア開発者はラップトップを閉じ、家に帰ります。一方、プライバシーレイヤーの仕組みを実際に知っているシニアエンジニアは、コンテキストなしでこの山を乗り越えなければなりません。彼は決して開始しなかったセッションを再開できません。では、彼は…すでに一度生成されたコンテキストを理解するために、そのコンテキストを生成するためにLLMに依頼すべきなのでしょうか?これは狂っているように感じます。昨日25万トークンが費やされたコードベースの領域に今日戻ってきた場合…コンテキストウィンドウを再びロードするために、さらに数万トークンを費やすことになるのでしょうか?はい…はい、そうです。