プラグインであって、目的地ではない

Baidu Comate は Baidu 自社の言語モデルを土台にした AI コーディングアシスタントで、公開されたオープンソースコードだけでなく、同社が長年蓄積してきた実際の開発に関するデータでも訓練されています。決定的なのは届け方の選択です。人々がすでに使っている統合開発環境、すなわち Visual Studio Code、IntelliJ IDEA、PyCharm、GoLand、WebStorm、CLion、PhpStorm、Android Studio などへのプラグインとして届き、自前のエディタを抱えた独立アプリにはなっていません。

この選択は見た目の話ではありません。コーディングアシスタントは、コードが書かれている文脈が見えるときだけ役に立ち、独立したエディタはすべてを一から説明されなければなりません。既存の環境の中に住めば、開いているファイル、プロジェクト構造、カーソル位置をそのまま受け取れますし、開発者は自分のショートカットもデバッグ設定も癖も手放さずに済みます。

補完と生成は、二つの別の約束

この種の道具ができることは二つあり、しばしば混同されます。補完は次のトークン、行の残り、開いたばかりのブロックの中身を提案します。すでに書いているものの続きであり、価値は「近い未来」を当てることにあります。生成は記述から関数全体を作り、価値は「意図」を正しく理解することにあります。

どちらも同じ仕組み、文脈ウィンドウ上での予測に乗っており、同じ失敗を共有します。モデルは存在しないものについても流暢なのです。半分しか覚えていないライブラリのメソッド名をでっち上げる補完は、補完がないより悪い。読むのに注意力を使い、試すのに時間を使うからです。この種の道具を元が取れるものにする習慣は、提案をたくさん受け入れることではなく、ちゃんと読むことです。

先にコメントを書く

コメントからコードを生成するのは手品のように聞こえますが、実のところ、こうしたモデルを使う最も規律ある方法でしょう。関数が何をすべきか、何を受け取り、何を返すかを述べたコメントは、小さな仕様書です。先に書けば、普段は飛ばされる思考を強制され、生成された本体は、上の一文と突き合わせられる草稿になります。

もう一つの利点は見過ごされがちです。仕様が残ります。後から読む人は、意図を説明する一文を受け取ります。たまたまそれを実装したコードだけではありません。本体を人が書いたかモデルが提案したかは、上の一文が正しいかどうかよりずっと重要でありません。

単体テストは、生成の最良の標的

この種の道具が出すものの中で、テストは最も擁護できます。理由は技術的ではなく構造的です。テストは実行でき、判決があります。提案された関数はもっともらしくて間違っていても一か月誰も気づきませんが、提案されたテストは緑になるかならないかで、どちらでも数秒で何かを学べます。

単一の関数にも、モジュール全体にまとめてもテストを生成できることは、慢性的に飛ばされる作業の経済を変えます。テストは締め切りの圧力で最初に落とされるものです。面倒で、その不在はかなり後になるまで見えないからです。最初の草稿を出す道具は、明らかなケース、境界、意図的に扱いにくい入力を一つ二つ用意し、一時間の苦行を十分の見直しと補足に変えます。見直しは任意ではありません。生成されたテストは、あるべき振る舞いではなく今の振る舞いを検証しがちで、それはバグが存在した瞬間にバグの説明になるからです。

リファクタリングの提案と、等価性という難題

この道具は業界で言うところの悪い匂い、長くなりすぎた関数や、平坦にできる入れ子の条件を見つけ、再構成を提案します。たとえば長い関数を名前の明確な複数に分けること。問題の形を見る方法としては本当に有用です。長い関数が読みにくいのは、まさにその部分に名前がないからです。

危険ははっきり書くべきです。リファクタリングは振る舞いが変わらないときだけ正しく、モデルはそれを保証できません。見た目は美しく、境界条件を微妙に変えるコードを作れます。とくにエラー処理、null 値、副作用の起きる順序まわりで。だから機能する組み合わせはリファクタリングとテストです。大きな音で失敗するテスト群があれば、再構成は数秒で検証できる提案になります。なければ、片付けのふりをした書き直しです。

コードを読むことは仕事のもう半分

関数を、全体または選択範囲で説明させることは、過小評価されがちなコストに答えます。他人が書いたコード、あるいは半年前の自分のコードを理解することです。説明はプログラムの真実ではなく、それについての仮説であり、真実はプログラムの側にあります。ただ、普通の言葉で書かれた仮説は、どこを見るべきかを決める前に人が必要としているものそのものです。

技術的な質問応答も同じです。エラーメッセージや API について尋ねれば、すぐ読めるものが返ります。検索し、四つのタブを開き、答えを組み立てるという以前の循環より良い。慎重さは変わりません。ライブラリの振る舞いについての答えは、最も自信たっぷりに間違える種類の答えであり、文書が依然として権威です。

言語の広さは実務の話

百をはるかに超える言語への対応は、宣伝文句ではありません。バックエンドの C、C++、Java、Python、Go、PHP から Rust まで、フロントエンドの HTML、JavaScript、CSS から各種のスタイルシートやテンプレートの方言まで、モバイルの Objective-C、Kotlin、Swift まで。実際のプロジェクトのほとんどは単一言語ではありません。リポジトリにはアプリケーション、ビルドスクリプト、設定、データベースの移行、文書が、四つか五つの異なる構文で入っています。そのうち一つしか話せないアシスタントは、しょっちゅう消えるアシスタントです。

正直な但し書きは、広さと深さは競合するということです。最も一般的な言語で性能が最も高いのは、単に訓練データがそこで最も密だからで、珍しい方言での提案は Java での提案より疑って読むべきです。

どこに向いているか、何を直さないか

この道具が扱うのは、ソフトウェアを書く作業の機械的な部分です。最初の草稿を作る、定型コードを埋める、誰も書きたくないテストを書く、知らないものを説明する。プログラムが何をすべきかは決めませんし、出力したものの責任も負いません。そこから二つの帰結があります。出すものはすべて、他人が書いたものとして読む必要があります。実際に他人が書いたのだから。そしてモデルから来たコードは、同僚のコードがめったに受けない質問に値します。これはどこから来たのか、どんなライセンスを帯びているのか。由来を気にする組織では必ず問題になり、それはアシスタントが代わりに答えられない唯一のことです。