[Scrap] mizchi さんの Copilot に優しくするプロンプターになる方法の記事を読む
へぶんmizchi さんが書かれた Copilot に関する考察記事が、読めば読むほど参考になりすぎる内容だった。今のうちに、再読しつつどのような点が参考になったかメモを残そうと思う。
へぶん自分の事前知識として、先日 GitHub Copilot の中の人が Copilot がどのように動いているか解説してくれるイベントに参加して内部について概要を知っていた。
それもあって、mizchi さんの考察が合理的、かつ、的を射ていることが明確に感じられた。
へぶん実際どれぐらい使ってるかというと、昔はドメイン非依存な場所でたまに使って1割ほど Copilot が生成、という塩梅だったが、今自分が書くコードはおよそ半分ぐらいが Copilot にさせた結果になっている。
この変化によって、労力や精神面での負担がどのように変化したのか気になる。
へぶん生成モデルは本質的に穴埋めソルバーなので、事前に埋まってる箇所が多ければ多いほどいい。
外壕を埋めると生成コードの品質がわかりやすく上がっていく。そのヒントとしてわかりやすく効くのが型シグネチャ、型アノテーション、型ヒントであり、動的型付けだとこのヒントを書けないがかなりのハンデキャップになってると思う。
AI リーダビリティの基本は人間向けのリーダブルコードと肝は同じだと思っていたが、引用の箇所の型を充実させる手法はその現代版だな、と感じた。
へぶんこのとき、意図せず同じファイルの Item 型を転用して filter 関数を引数として書かなかったのだが、勝手に flag を使っていた。これが正しいか挙動かどうか判断するのは、プログラマの役目。
情報を充実させた上で、その情報から Copilot に実装を導出してもらい、それをプログラマが何らかの知識なり能力で修正していくのは新しいプログラミングの形だし、腑に落ちる。
へぶんおそらく、実装とコードが離れていることも理由の一つなので、自分は vitest の in-source testing を使って、実装コードの隣にテストコードを置くようにしている。
これは神がかっている洞察で、先日イベントで Copilot の挙動を知った身からすると鳥肌がたった。
ドキュメントを読んだ限り vitest の in-source test suites は、例えば関数を実装している場合にその関数の付近にテストを書くもののようだが、これは GitHub Copilot が読み込む情報のうち「兄弟関数」として Prompt に加えられるはず。
よって、Test の情報を Prompt に載せたい場合のベストプラクティスであると考えられる。
へぶんまた、命名やモジュールの抽象のメタファでデザパタも大事で、なにか書いてもコードが補完されなくなってるときは、自分がモデリングに失敗していることが多い。その時はコードレビューを受けてる気持ちになって、モジュール構成の変更や、命名、コメントを書き直している。
最高of最高。これだ。
へぶんプロンプトだけで価値になるわけではなく、何かのプロダクトがあり、その利用例としてもっとも精通した理解者としての、プロンプトエンジニアリング。
ここに関しては、痛いほど最近感じているところであり、プロンプトエンジニアリングでより良い性能を出そうとするほど、そのドメインに関する理解が重要だと思う。
へぶんそのドメイン不足を補うためのハックとして、自分は VSCode の OpenFiles がプロンプトに使われてそうなのを利用して、 typescript.d.ts の型定義ファイルをピン止めしてコードを書いてる。
これは実際使われているらしい。隣接したタブから優先して Prompt に挿入されるそう。
へぶんまた、今のCopilotの出力の癖で、括弧の対応をとるのが苦手で、haskell や python のオフサイドルールのほうが書きやすいかもしれない？という気持ちがある。
括弧が苦手なのは、現在修正中とイベントで言っていました。