ジェネレーティブAIはソフトウェア開発に3つの幻想をもたらす：高速、高品質、そしてより少ない人員

著者 |張開峰

ソフトウェア業界は長い間、コスト削減と効率性向上に取り組んできました。長期にわたる開発サイクル、絶望的な発売時間、そして絶えず発生する欠陥は、このエリートチームにはまったくふさわしくありません。生成AIは希望をもたらすようで、そのパフォーマンスは爽快であり、多くの人がそう思っている。クラウドリソースのように低コスト、繰り返し性、使い捨て機能を備えたコードを自動的に生成できます。このコードは不適切でしょうか?それを捨てて新しいものを生成するだけです。エリート兵士や将軍はそんなに多くは必要ないと考えるのは当然であり、プログラマーもこれを懸念しています。

生成 AI が私たちの質問に答えるとき、時には真面目な答えを返すこともありますが、ちょっと検索してみると、その答えは見せかけだけのものであることがわかります。つまり、その答えは存在しないか、ナンセンスであり、人工知能の評判とは矛盾しています。これは、生成 AI のいわゆる幻覚です。実際の信頼できるコーパスがないため、恣意的に誤った答えを組み立ててしまいます。

大型模型の技術は現在も更新中であり、人が知覚できる錯覚の度合いは徐々に減少しています。しかし、特定の分野や使用シナリオに適用すると、錯覚効果は依然として発生します。この記事では、ソフトウェア開発分野でのその応用について説明します。

錯覚1: スピードが速くなる

さまざまなソフトウェアツールベンダーが、コードアシスタント製品を繰り返し更新しています。最も有名なのは、GitHub の Copilot です。同社は、プログラマーのタスク完了を 55% 以上高速化できると主張しており、その明瞭で高速なデモビデオはまるで飛んでいるようです。

（画像出典：https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/）

しかし、これはソフトウェア配信を 50% 加速できることを意味するのでしょうか?

デモコードには疑問があり、独自のプロジェクトで Copilot を採用しているプログラマーからのフィードバックによると、基本的に高速化はいくつかのよく使用される関数の実装でのみ現れるようです。配列のソート、データ構造の初期化、または非常に単純なテンプレートコード。

繰り返し可能なツールコードを AI に引き継げば問題ありません。しかし、開発中のソフトウェアの場合、類似のコードを何回繰り返して開発する必要があるのでしょうか? これはおそらく議論する価値があります。言うまでもなく、ほとんどの場合、一度形成して後で使用するためにパッケージ化するだけで済みます。

業務コードも相当量あります。プログラマーはどのくらいのスピードで進めるのでしょうか？ AI に十分な量のビジネスコードを生成させることはできますが、それが安全かどうかの方がおそらく大きな問題です。

ここで注目すべき問題が 2 つあります。

1つは、AIにコードを提供するプログラマーの選択です。

AI は複数の実装方法のセットを簡単に提供できるため、プログラマーは必然的にその中から最適なオプションを見つけようとします。

これは良いですか？それともどちらが良いでしょうか?すごいですね、5つの異なる実装があります。次のコードに切り替える前に、各コードの実装を理解する必要があります。これはエレガントな方法ですが、残念ながら単体テストに失敗します。次のものに変更します。

コードアシスタントによってプログラマーの好奇心が十分に刺激されます。私の心はさまよい、直線的な思考習慣は崩壊しました。プログラマーが忘れているのは開発規律だけでなく時間もです。

2つ目はソフトウェア自体のライフサイクルです。

明らかに、プログラマーがコードを書き始めるまでに多くのことが起こっており、システムが稼働するまでさらに多くのことが起こり続けるでしょう。これらには、要件の収集、要件の理解 (要件仕様からユーザーストーリーまで)、テスト、インフラストラクチャの維持、そして終わりのない修正などが含まれますが、これらに限定されません。

つまり、AI がプログラマーのプログラミング速度の向上に貢献したとしても、この段階はソフトウェアライフサイクルの一部にすぎないということです。関連する統計によると、プログラマーは日常業務でコードの記述に費やす時間は 30% に過ぎず、実現したい機能の理解や、新しいスキルの設計や学習に多くの時間を費やしています。

（画像出典：https://github.blog/2023-06-13-survey-reveals-ais-impact-on-the-developer-experience/）

幻想2: バグが少ない

人間が書いたコードには必ず欠陥があるというのは、ソフトウェアの品質に関する基本的な合意です。そして、プログラマーの経験が豊富であればあるほど、発見されるまでに長い時間がかかる微妙な問題を生み出す可能性が高くなるようです。オンライン上の問題はさらに心配ですが、そのような懸念を避けるのは困難です。

AI によって生成されたコードは非常に高度に思えます。完璧な結果が得られるでしょうか?残念ながら、答えは期待外れになるかもしれません。

生成AIを支えるビッグモデルは、インターネット上の大量のコーパスをデータソースとして利用しています。ビッグモデル技術は向上していますが、インターネット上にすでに存在する偏ったデータの量は相当なものです。これにはバグだらけのコードも多数含まれています。

つまり、プログラマーがコードアシスタントで慎重に選択したコードにも欠陥が含まれている可能性があるということです。なぜなら、この欠陥のあるコードは地球の反対側の誰かから来た可能性があり、たまたま地球のこちら側で選択されただけだからです。

問題は、生成 AI が増幅効果を持つことです。簡単に言えば、プログラマーが生成された欠陥のあるコードを使用した場合、Copilot はそのような動作を記録し、将来同様のシナリオで欠陥のあるコードや類似のコードを提案し続けます。 AI はそのようなコードを読み取ることができないため、コードを提供し続けるように促されるだけです。最終的な結果を予測することができます。

（プロンプト：プログラマーがコンピューターのデスクに座って、困惑してイライラしている様子です。コンピューターの画面には、コードエディターと、赤いエラーインジケーターとコード内の取り消し線で象徴される間違ったコードを提案する GitHub Copilot のポップアップウィンドウが表示されています。プログラマーは、何度も失敗したことを示すくしゃくしゃの紙に囲まれて頭を掻いています。このシーンは、AI が生成した誤ったコード提案に依存し、ソフトウェア開発の品質問題につながることによる課題と混乱の感覚を伝えています。部屋は散らかっており、混沌とした状況を反映しています。）

プログラマーはチームの開発規律を厳守し、統一されたコード標準を維持する必要があります。こうすることで他の人が理解しやすくなり、潜在的な問題を見つけて修正しやすくなります。しかし、コードアシスタントによって提供されるさまざまなコードは、さらに混乱を招くようです。

コードの欠陥は、ソフトウェアが最終的に遭遇する可能性のある、解決が困難な問題の原因の 1 つ、さらにはごく一部にすぎません。ソフトウェアを構築するプロセスは、実際には知識の生産と創造のプロセスです。ソフトウェアライフサイクルのさまざまな段階で参加するさまざまな役割が連携して、ソフトウェア要件を理解、分析し、コードに変換します。チームや人員の変更の過程で、要件やコードのように見えても実際には知識であるこれらの情報も伝達されます。

しかし、通常、知識資産の移転においては、知識の劣化やエラーは避けられません。コードが理解できない、ドキュメントを最新の状態に維持できない、チーム全体が入れ替わる、などさまざまな可能性があります。これが、ソフトウェアにバグや問題が引き続き発生する理由です。人工知能は、少なくとも短期的には、ソフトウェアエンジニアリングにおけるこれらの厄介な問題を解決することができていません。

幻想3：人が減る

AI コードアシスタントは、知識豊富なプログラマーのように見えます。ペアプログラミングの練習のパートナーとして使う人もいます。人件費は、常に IT チームにとって頭痛の種でした。優秀な人材は高すぎるし、適任者を採用するのは難しく、熟練したプログラマーを一から育成するには時間がかかりすぎます。人工知能やコードアシスタントのサポートがあれば、人数を半分に減らせるということでしょうか？

AI やコードアシスタントは、前述のような高速性と高品質保証を提供できないだけでなく、その利点を最大限に活用するには、ユーザーが十分な経験を積んだプログラマーである必要があります。この経験豊富なプログラマーは、コードの品質を判断し、既存の製品コードへの影響を判断し、プロンプトの言葉を慎重に調整する忍耐力とスキルを持っている必要があります。

この記事では、著者がコードアシスタントを使用する際に注意すべき多くの問題について語り、彼女の細心の注意を払った内面の考えも見ることができます。コードアシスタントによってもたらされる不確実性により、コードの品質に影響を与えるリスクと、時間を浪費するリスクという 2 種類のリスクが発生する可能性があります。ここで実際に示されているのは、十分な経験を積んだプログラマーの自己反省能力です。

この方法でのみ、コードアシスタントは知識豊富な初心者の役割を安心して果たすことができ、経験豊富なプログラマーはゲートキーパーとして機能し、コードを送信する責任を負います。このように、AI はプログラミング体験を変えます。

(画像出典: https://martinfowler.com/articles/exploring-gen-ai.html、著者はコードアシスタントを、助けることに熱心で、頑固で、はっきりと話すが経験不足のキャラクターとして想像し、AI を使用してこの漫画画像を描きました)

AI とコードアシスタントは、単純で反復的な問題を解決するのに非常に効果的です。しかし、ソフトウェアを構築するプロセスでは、複雑な問題を解決するために人材と専門的な経験を必要とするシナリオが増えます。たとえば、ソフトウェアシステムのアーキテクチャの複雑さと範囲の拡大、市場とビジネスのニーズへの対応、役割を超えたコミュニケーションとコラボレーション、コード倫理とセキュリティに関する最新の問題などです。

プログラマーがプロフェッショナルで十分なスキルを持っているかどうかを判断するのは数えるほど簡単ではありませんが、AIやコードアシスタントを導入して開発チームの数を減らすことの有効性は不確かであり、現状ではデメリットがメリットを上回っているとも言えます。

最後に

生成 AI の本質はパターン変換、つまりある形式のテキストを別の形式に変換することであり、高度なコードアシスタントもこれに劣らない機能を備えています。ソフトウェア構築に関与する AI コードアシスタントを、多くのソフトウェアエンジニアリングの問題に対する万能薬とみなすと、複雑な問題を単純化しすぎているだけになる可能性があります。

ここまで書いてきて、何について話してきたのでしょうか?

私たちが実際に話しているのは、ソフトウェア開発における AI への投資の有効性をどのように測定するかということです。 AI への投資は、コードアシスタントライセンスを購入して、あとは座ってコスト削減と効率向上のメリットを享受するほど簡単ではありません。「AI やコーディングアシスタントへの投資の影響をどのように測定するのか」と常に自問するのではなく、「具体的に何を測定したいのか」と自問する必要があります。 DORA によって定義された 4 つの主要な指標 (変更リードタイム、展開頻度、平均復旧時間 (MTTR)、変更失敗率) から始めるのが賢明です。

推奨される基本的な測定原則は次のとおりです。