おれきゅー
102.2K posts
整理ありがとうございます。「AIに指示を出す人が、結果をレビューすべきである」という前提については完全に同意です。ただ、最近の肌感としては一気に生成してから結果をレビューしていると漏れが結構でてしまうなーと感じることはありますね。
1に関しては自分の経験からの感覚では手直しの多さからまだ人間の中央値を超えるような精度の高さはないのではないかと思いますが、将来に期待ですね。
2については指示を出す人間が気付いていない仕様があった、もしくは理解のミスのケースだと考えていて、たしかにこれは人間であってもレビューで弾くのは難しいですね…。
別軸の話にはなりますが、AIにレビューをしてもらうことで見つけられる可能性が上がるという点で良いパートナーになってくれるかなと期待していたりします
話はそれてしまいましたが、これまでの品質を上手く保ちつつレビューコストを下げる方法を確立していかないといけないとは思うのでお話できて面白かったです。
AIによって開発のボトルネックがコードレビューに移動しただけで、受け入れなければならないという思想だったので別の意見が聞けて新鮮でした
日本語
その話は分解して抽象化していくと、2つの問題に整理できると思います。
1. AIに明示的に指定したものが漏れなく実現されているか？
2. AIに必要な情報がすべて漏れなく・正しく渡されたか？
またAIを使うにあたって、私は一つの前提を持っています。
- AIに指示を出す人が、結果をレビューすべきである
指示だけ出して、レビューしない人は、育成対象を除き、今後チームに不要になっていくでしょう。
#1について
さてこの時、1に対する担保は、今後どんどん人よりAIの方が高い精度の評価ができるようになると思います。
言葉を選ばず言えば、現時点でさえ、人の中央値を超えていると感じています。
#2について
端的に言うと、指示を出し漏れた当人がレビューしても、発見される可能性は低いと考えています。
指示A⇒指示B⇒AI⇒レビューB⇒レビューA
とあったとき、2をフックするのに適切なフェーズはレビューAだと考えています。
もちろん、これは極端な話であって、完全に不要という訳ではないので、非効率でもコストを書けるべきとう経済的な正当性があるなら、やればいいと思います。私は
- 経済的正当性が今後は得られないと考えているという事
- レビューできる人材は今後どんどん育てられなくなる事
から、別の手段で対処すべきだと考えています。手段は色々ありますが、例えば指示BをAIが実行する前に、指示Aに対するトレーサビリティチェックをするなどです。
というので回答になりましたかね？ちょっと発散してしまったかも？
日本語
なるほどです。コードレビューで見ている部分が自分とは違うので、そこで意見が分かれるのかもしれないです。
コードレビューの観点として求める仕様が網羅されているかは重く見ているので、そこを別のレイヤーに移動すれば良いよねということですかね（例えばAIに渡すpromptや仕様書、会議の議事録など）
疑問に思っているのは、promptや仕様書などをレビューしていてもコードにする時点でそれを網羅できているかに関してはどうチェックするべきなのかというところで、指示を満たすコードが生成されているかはどう担保すれば良いんでしょう？テストケースだけガッツリコードレビューするのか、人間がテストケースだけを書くようになるイメージですかね？
日本語
まず例の記事の趣旨は、現在のコードレビューのスタイルをそのまま全て継承し続けてたら淘汰されるよと言う話で、ゼロにしなければ淘汰されると言う意図はありません。
またコードレビューに置ける、仕様の網羅性の担保は、元々副次的なモノで主目的ではないと言うのが一般論と認識しています。したがってコードレビューの主目的の多くは人が介在しなくても評価可能と考えています。
そして多層的な評価レイヤーの最下層であるコードレビューへの関与が薄まっても、上位層の評価レイヤーへの関与は可能で有り、コードを直接見ないと人間がコードへ関与できない訳ではないと思います。
人間がAIに対して優位なのは、最終的に言語化されていない暗黙的なコンテキストの認知で、そこを担保する事へウェイトを絞って行く必要が有ると思っています。
最後に、その暗黙的コンテキストも、会議を全て取り込む事で、減らして行く事も可能と考えています。
長文失礼しました。
日本語
jetbrains.com/help/qodana/do…
ほーん？Qodana Cloudでレポート見ないならQODANA_TOKENを渡さなければ良いのか
日本語
