Claude Code のリリースから 18 か月後に書かれたこの投稿は、日々のプロジェクト作業と顧客向けトレーニングにおける著者の エージェント型コーディング の経験をまとめたものである。その前提は、AI バブルの外では、多くのチームがこうしたツールをそもそもどう効率的に使うかをいまだ模索しているということ、そして以前の投稿で著者が出した結論 — コーディングはボトルネックではない — が、その後のモデル能力の向上を経ても変わらずに通用しているということである。
投稿を組み立てる区別は、AI 支援のソフトウェア開発はエージェント型コーディングではない、というものである。エージェントはタスクを自律的にやり遂げることを目指す。著者の主張によれば、実際に違いを生むのはモデルにより良い質問をすることではなく、望ましい最終状態を、それが達成されるまで自分がその場にいなくてもよいほど正確に記述することである。続く 5 つの節が、それに何が必要かを引き出していく — エージェントをペアプログラミングの相手として扱わないこと、暗黙の決定を明示すること、フィードバック、レビュー、そして非決定性との折り合い — そして各節は一行の「Learning」で締めくくられる。
要点
- エージェント型のシステムは、モデルとハーネスから成るものとして説明される。ハーネスとは、リクエストを送信してレスポンスを受け取り、ツールを提供し、結果に対して反復するエージェント的ループを実装するソフトウェア環境であり、ガードレールや
AGENTS.md、CLAUDE.mdといった指示ファイルもハーネスの一部に数えられる。 - コーディングエージェントを IDE に統合されたチャットボットとして扱っても大きな効率向上は得られないと論じられる。絶え間ないやり取りによって、開発者の注意が会話に縛りつけられるからである。効率向上は、開発者が別のことをしている間にエージェントが自力で作業することから生まれる。この節の著者の Learning は、AI の子守をするな、というものである。
- 期待する結果を得るには、まずそれが何であるかを明確にしなければならない。記述はいくつかの抽象度で示される。システムとその機能が置かれるコンテキストについての情報、ユーザーペルソナと対象読者、ユーザーストーリーに基づく正確な機能定義、受け入れ基準、技術的な制約、さらには必要なクラス名やメソッド名までである。
- エージェントの出力に対する不満は、モデルの能力ではなくコンテキストの不足に帰せられる。著者によれば、モデルの能力はほとんどのコーディングタスクにとって十分である。
- 中心的な主張は、開発者が実装中に暗黙のうちに下している決定 — クラスをどこに置くか、メソッドを何と呼ぶか、テストをどう構成するか — は、明示的かつ事前に下されなければならないというものである。それを一度も告げられていないモデルにとっては自明ではないからである。数十行に及ぶプロンプトも珍しくないとされ、開発者の仕事は、作業の最中に自分が必要とされないほど正確にタスクを記述することとして捉え直される。
- それらの決定の置き場所は 3 つに分けられる。一部は、エージェントに既存の特定のクラスを示すことで既存のコードベースから導き出せる。一部はプロジェクト全体に当てはまるもので、
AGENTS.mdファイルに置くべきである。そして現在のタスクに固有のものはプロンプトに置くか、ユーザーストーリーへのアクセスのように、他の手段で到達可能にしなければならない。 - フィードバックとは、次のプロンプトでエージェントを修正することと、エージェントが自らをチェックできるもの — 静的解析、リンター、そして何よりも良好なテストカバレッジ — を与えることの両方を意味し、それによってコードが構文的にだけでなく意味的にも正しくなる。著者は、エンドツーエンドテストが依然として最も価値のある種類のテストであり、手で書くには手間がかかりすぎたであろう良いテストを、エージェントは実装と並行して生成できると考えている。
- レビューについて、著者は問いを、人間がレビューするかどうかではなくいつレビューするかとして捉え直す。コードレビューを省略すれば、レビューはステージングや本番環境でプロダクトオーナーによって行われることになり、そこで欠陥が見つかればパイプライン全体をもう一度回すことになる。欠陥は早く見つかるほど修正が安く済むというおなじみの原則は、エージェント型コーディングの下でも変わらず成り立つと主張される。
- AI が生成したコードのレビューの難しさは、AI ではなくレビューの扱い方に起因するとされ、AI はそれを増幅するにすぎないとされる。明確な筋道なしに数十のファイルに手を入れる大きなプルリクエストは、そもそもレビュー可能ではない。推奨されるのは、ストーリーを小さく切り分けること、それを実装可能なタスクに分解すること、プルリクエストごとに 1 つのことだけを変更すること、同僚と同期的にレビューすること、そしてプルリクエストを放置せず迅速にまとめてレビューすることである。同期的なレビューの副次的な利点として、より多くの人がコードを読み、プロジェクトの知識が広まることが挙げられている。
- 非決定性は、バグではなく言語モデルの特徴として提示され、温度によって制御される。著者の議論は、開発プロセスもまた決定論的であったことはない — 異なる人が、また同じ人でも異なる時点では、異なる解決策を生み出す — というものであり、その変動は時に開発者が思いつかなかったアプローチを生み出す一方で、生成されたコード自体は一度生成されれば決定論的である。
背景
これは実務者によるまとめとして提示されたものである。素材は約 18 か月にわたる著者自身のプロジェクト経験と顧客向けトレーニングであり、測定結果は示されていない。ハーネス — モデル、ツール、エージェント的ループ、ガードレール、指示ファイル — についての説明は著者自身の言葉で述べられており、この語自体はハーネスエンジニアリングに関する他所の文章にリンクされている。エージェントハーネス と ハーネスエンジニアリング を参照のこと。
助言の多くは、意図的に AI 以前の実践と連続している。小さなストーリー、小さなプルリクエスト、欠陥の早期発見、テストファーストの開発は、新しい知見としてではなく、今も通用する道具として提示されており、投稿が繰り返し用いる論法は、エージェント型コーディングはそれらが何であるかを変えるのではなく、それらをまずく行うことのコストを高めるのだ、というものである。