AIコード生成への過信は禁物
AIによるコード生成は朗報か
What improves developer productivity at google? code qualityというESEC/FSE採択のGoogleの論文があります。Google社内で開発生産性を上げる施策を行なったもののうち最も有効だったのがコード品質を上げることだったというものです。
ここ数年GitHub CopilotなどAIコードアシスタントを使用している企業が増えてきていますが、GitClearというDiff Deltaという非公開のコード品質指標を開発している企業がAIコードアシスタントの適用によりコード品質が下がったというホワイトペーパーを発表しました。
ホワイトペーパー自体は非公開情報なのでメールを登録して読んでねという感じなのですが、周辺情報は公開されていたので調べたことをメモしておきます。
Diff Deltaとは
GItClearはDiff Deltaという指標を作っている企業なのでまず彼らの主張を見てみます。
彼らの研究によるとsoftware effortというストーリーポイントベースの工数との相関において、変更行数、コミット数よりDiff Deltaのほうが良い指標でした。
- 変更行数: 25% (大きなリポジトリだと13-31%)
- コミット数: 27% (大きなリポジトリだと17-49%)
- 行への影響(= Diff Delta): 38% (大きなリポジトリだと: 26-61%)
個人的には、コミット数だと人によってばらつきがあって変更行数より悪い指標だと思ったのですが、ならせばそうでもないみたいですね。Diff Deltaでも相関が38%なのでgit logだけをみて工数予測するのは難しいとも言えそうです。
コードを削除するのは足すより大変
GitClearはDiff Deltaで商売しているので詳細の計算式は非公開のようですが、公開されている部分もあります。変更行数比でDiff Deltaは13ポイント良い指標なわけですが強さはどこにあるのでしょうか？
Diff Deltaでは変更の種類ごとにポイントを振っています。
- 追加: 最大10ポイント
- 削除: 最大25ポイント
- 移動: 0ポイント
- 更新: 最大10ポイント
- 一括置換: 3ポイント
- コピペ: 0ポイント
- 変更なし(フォーマットなど): 0ポイント
一括置換やコピペ、移動は頑張ったと認めず追加より削除するのが大変という仮定のようです。
他にも近傍の変更は楽、言語によるウェイト(CSSの変更はPythonより楽)などいくつか工夫されています。
企業ごとのDiff Deltaの目安
公式ページにいくつかDiff Deltaのベンチマークがのっています。
- エンタープライズ企業のエンジニア: 70 DD/day
- Googleのエンジニア: 72 DD/day
- 中規模企業のエンジニア: 88 DD/day
- スタートアップのエンジニア: 97 DD/day
- Microsoftのエンジニア: 105 DD/day
- Facebookのエンジニア: 105 DD/day
別のベンチマークによるとGoogleのTensorflowのエンジニアはとある一日に10行追加、20行削除、5行変更、5行コピペ、10行一括置換したそうです(50行/日)。変更行数 x 1.46 = 1デルタくらいでしょうか。
スタートアップのエンジニアのとある1日だと350行追加、200行削除、10行更新、300行移動(860行/日)です。変更行数 x 0.13 = 1デルタくらいでしょうか。churnが高いと低く出るみたいですね。
プログラマーが一日に書くコードの量は言語によらず一定という言説も聞いたことがありますが、Diff Deltaの良いコードで比較すると企業ごとのばらつきは思っているほどない印象。
AIコードアシスタントが出てからはchurnが上がった
ようやく本題。
こういったDiff Deltaの変更行数を分解できる能力のバックグラウンドがある前提でホワイトペーパーではAIコードアシスタント登場前後で指標を比較しています。
Generative AIの名のとおりいうかコードの追加は増えて、逆に移動は減りました(詳細はホワイトペーパーをご確認ください)。コードチャーンも上がって(寿命が下がって)います。
ここら辺は今後改善される部分だと思いますが、現状AIコードアシスタントはコードの追加は得意でもリファクタリングは苦手と言えるかもしれないですね。スマートコピペで重複したコードを産むのは得意でもDRYで共通化は苦手というか。
所感
GitHubによるとCopilotの適用によって55%速くタスクが解消されるとのことです。大きなアドバンテージですね。
一方で以前読んだMicrosoft Researchの論文だとCode Churnはバグ発生を予測する指標としてかなり精度の高い指標でした。
ソフトウェアは作るよりメンテナンスするのが大変と言う言説も聞いたことがあるのですが、例えば納品して終わりの受託の開発のようなものだとAIコード生成の旨みが現状大きく、継続して改善していくような保守フェーズのコードほどどちらかというと向いていないのかもしれません。