GitHub Copilotを使った私の最近の開発の話をゆるゆると書きます。
GitHub Copilotがいいな、と思っているのは、自動でコードを提案してくれるところですが、それ以上に、前後の文脈を読んでくれるところです。
以前、GitHub Copilotの仕組みを中の人が解説している動画を見ました。 4ヶ月前の動画なので少し古くはありますが。
この中で印象的だったのは以下のような話です。
- 当時、中で使っていたのはGPT-3.5の派生モデル
- 読み込ませている情報は何か（開いているファイル、ファイル名、言語など）
- GitHub Copilotで重要なのは、UIであり、そこは非公開
GTP-3.5を使っている理由は、速度との話が出ていたと記憶してます。 今は、GPT-4.0-turboがあるので、そちらを使っている、もしくはGPT-3.5との組み合わせでは？と推測しています。
GitHub Copilotの動きがイメージできてくると、無意識に普段のプログラミングはそれを意識した動きに変わってきます。
例えば、私は無意識に以下のような動きをしています。
- 読んで欲しいファイルを先に開いてから書き始める。それにより提案精度を上げようとする。特に、クラス名や関数名の提案精度をあげようとする。
- フレームワークを使っていても、まずは一つのファイルに一連のコードを処理を書く。一通り動く流れが確かめられたら、動作確認・適切なファイルへのコピペ・整理を進める。
- 別に設計情報があって、それをコードに落としていく場合、解釈されやすい（と予想する）形式のテキストにして編集ファイルに貼り付ける。それを読ませて、コードを提案させる。
こういう動きは、コードを書かないソフトウェアエンジニアだと想像もつかないし、実践もできないと思いますので「コードを書く人ならでは」なんだろうな、と思っております。
また、このような動きをしていて良いのは「既存のファイルやテキストを見て考えたら分かるコード」を作るときに、コードの具現化速度が爆速化することです。慣れてくると、「数文字入れる→提案待ち→確認→OK→カーソル移動→数文字入れる→提案待ち→確認→OK... 」みたいな繰り返しになってくるところがあるのですが、どう考えても自分が個別にタイピングするより速い。
GitHub Copilotがいいなと思うのは、あくまで道具である点です。仕組みではなくて道具。道具いいですね。UNIX的な文脈というか考え方なのかもしれないですが。
ちなみに、最近、テキストベースのモデリングツール、mermaidやplantUMLにも興味がありますが、この流れの影響を受けています。
詳細はまた気が向いた頃に。
なお、余談ですが、私は、NeoVimを介してGitHub Copilotを使っているので、GitHub Copilot Chatは使えてません。気になる...と思い間ながら登場から少し日が経ってしまってます。
ではでは
