Baidu で 1 年半にわたり昇進を成功させたこの AI プログラマーが、昇進の秘訣を披露しました。

Wenxin Quick Code はコードの 27% 以上に参加し、エンジニアの 80% 以上を支援したとされています。

最近の Cloud Intelligence Conference では、コード アーキテクチャの説明とコード レビューという新しいスキルを習得しました。

自動プログラミングを測定するための重要な指標は何でしょうか？理想的なAIプログラミング製品を実現するための技術的な道筋は何でしょうか？AIプログラミング製品の製品市場適合性（PMF）はいつ実現するのでしょうか？

QuantumBit の「365 AI 実装ソリューション」では、百度スマートクラウド技術委員会の会長である孫克博士を招き、 Wenxin QuickCode の最近のアップグレードと、プログラミング自動化の時代がどれだけ遠いのかについて話し合いました。

ハイライトの概要

• 今では、仕事が終わった後、全員が自分のコードを大規模なモデルに送信して一括レビューを行い、翌日には提案に基づいて修正を加えることができるため、効率と品質の両方が向上します。
• 私たちがもっと関心を持っているのは、1000 行のコードのうち、実際に大規模モデルによって処理される行数です。
• 現在のアプリケーション モデルは、2 つの主なトレンドに分かれます。1つはアシスタントまたは副操縦士のロジックを指し、プログラムの最終的な実行と配信はプログラマーが主導します。もう 1 つはコード インタープリターのようなもので、プログラム全体の最終的な実行と配信は大規模なモデル自体が主導します。
• 大規模モデルによって完全に駆動される、完全に自動化されたアプリケーションが安定的に動作し、実用的かつ商業的に実現可能な日が来ることを、私はむしろ楽しみにしています。このアプリケーションは、製品機能モデリング（PMF）を実現した最初の製品の誕生を象徴するものになると信じています。
• 将来的には、ウェブサイトに次に何をすべきかを指示するダイアログボックスさえあれば、大きなモデルがボタンを生成し、クリックするだけでタスクが完了するようになるかもしれません。
• …

（以下の内容は生放送での会話に基づいています）

会議を開く代わりに、大規模なモデルにコードを直接レビューしてもらいます。

QuantumBit ：先日のCloud Intelligence Conferenceで、Wenxin QuickCodeがコードアーキテクチャの説明とコードレビューという2つの機能をアップグレードしたことをお伝えしました。この2つの機能と、それらがエンタープライズ開発ワークフローにどのように役立つのか、ご紹介いただけますか？

Baiduの孫克氏：Wenxin QuickCodeのポジショニングは、エンタープライズプログラマーの開発ワークフロー全体を支援することです。この観点から見ると、プログラマーの日々の仕事はコーディングだけではないことがわかります。実際、新しいプロジェクトチームに参加したり、プロジェクトを開始したりするなど、ワークフローの初期段階では、プロジェクトのコードアーキテクチャを包括的に理解する必要があります。

私は20年近くプログラマーをしていますが、特に他人の何万行、何十万行ものコードを突然引き継ぐのは大嫌いです。コード全体のロジックを理解するには、PRDとコメントを丹念に読み込まなければなりません。以前は、このような作業は本当に苦痛でした。

大規模コードモデルの登場後、コードの読み取りやコメント付けなど、その有用性に気づきました。単にコードを記述するだけでなく、プロジェクトの早い段階から大規模コードモデルを活用すれば、コードアーキテクチャを迅速に明確化できるのではないでしょうか。私たちのエンタープライズクライアントの多くのプログラマーが、私と同じような苦い経験を​​抱えていると考えています。こうした考察に基づき、最初のアップグレードポイントとして、コードアーキテクチャの解釈機能を提供しました。

もう一つのアップグレードはコードレビューです。これも私たちの標準化された日常開発プロセスの一部であり、一般的かつ重要なものです。プログラマーがコードの開発とデバッグを終えた後、正式リリース前に、社内のシニアプログラマーを招いてレビューチームを編成し、最終コードをレビューし、コードが標準に準拠しているかどうかなどを確認します。主な目的は、コード品質の向上です。

企業のR&Dリーダーとのコミュニケーションの中で、この非常に一般的なR&Dステップは開発プロセスの終盤に位置し、完了までに多大な労力を要することがわかりました。また、大規模モデルは実のところこの点において非常に優れていることにも気づきました。大規模モデルは、社内の開発基準を直接読み取り、その基準に基づいてコードをレビューし、違反があればマークして修正を提案することができます。

考えられる解決策は次のとおりです。仕事が終わった後、全員が自分のコードを大規模なモデルに送信して一括レビューを行い、翌日、提案された修正に基づいてコードを修正することで、効率と品質の両方を向上させます。

QuantumBit ：では、Wenxin Quick Code はすでに Baidu や他のサービス プロバイダー内で何らかの効率改善を達成していますか?

Baiduの孫克氏：Baiduは多数のプログラマーと研究開発スタッフを擁する企業です。当社の製品の高度な機能は、Baidu内で優先的に利用されます。

実際、Wenxin QuickCodeはBaidu社内で約2年間にわたり導入が進められています。現在、コードの27%以上がWenxin QuickCodeによって生成または作成支援されており、Baidu社内のエンジニアの80%以上がWenxin QuickCodeを使用しています。Baidu社内では、Wenxin QuickCodeは非常に強力な効率向上ツールであり、研究開発全体の効率を10%以上向上させることが可能です。

さらに、Himalayaのような企業もWenxin Quick Codeを活用しています。同社のプログラマーがWenxin Quick Codeを使用して開発したコードは、同社の新規コード全体の約3分の1を占めています。さらに、エンジニアのカバー率も約90%と非常に高くなっています。そのため、 Wenxin Quick Codeは、集中的なコーディング環境を持つ企業にとって非常に効果的な効率化ツールであることがわかります。

Qubit ：開発者からは、開発効率を向上させるために、既に日常のワークフローで大規模モデルを活用しているというフィードバックが増えています。以前、第三者機関による調査で、5年後にはエンジニアの75%がAIコードアシスタントを利用する可能性があると示唆されています。AIプログラミングの発展は、開発者の能力にどのような新たな要求を突きつけていると思いますか？

Baiduの孫克氏：非常に興味深い質問ですね。大規模モデリング技術は、私たちを日々の煩雑な作業から徐々に解放してくれています。例えば、コードアシスタントはコードの読み書きやレビューを支援し、コメントやユニットテストの作成もサポートしてくれます。これらは全て、すべてのプログラマーにとって基本的なスキルです。大規模モデリングは、これらの作業を徐々に代替していくと考えています。

また、数行のforループを慣れた手つきで簡単に入力するといった反復的な操作もあります。大規模モデルによって、数百回、数千回も入力されるこれらのコマンドを徐々に削減できれば、非常に大きなメリットとなります。したがって、大規模モデルがプログラマーにもたらす主なメリットは、作業負荷の軽減です。

私の考えでは、将来プログラマーにとってより重要なスキルは、アーキテクチャに関するスキルになるでしょう。これはシニアプログラマーの肩書きである「アーキテクト」に相当します。

これは、基本的なタスクがより大きなモデルによって徐々に合理化され、プログラマーがプログラムアーキテクチャの設計、関数間の呼び出し関係、機能の分解といった、いずれも重要かつ決定的なタスクである本質的な側面に集中できるようになることを意味します。これはまた、将来のプログラマーに求められるスキルの進化を反映しています。

QuantumBit ：Wenxin Kuaima氏は昨年AIプログラマーとしてBaiduに入社し、1年後にはAIアーキテクトに昇進しましたね。Baiduはこの職位昇進をどのように定義していますか？

Baiduの孫克氏：社内では、エンジニアには複数のファイルやプロジェクトに関わるタスクなど、よりマクロレベルのタスクを処理できる能力が求められています。Wenxin Quick Codeでも同様の定義を採用しています。

当初、Wenxin QuickCode は、通常の R&D エンジニアのように、現在のページのコードの継続のみを処理し、日々のコードの継続とコーディングを支援するだけでした。その後、大規模モデル機能が向上するにつれて、Wenxin QuickCode はよりプロジェクトレベルのファイル間の依存関係の管理にも役立つようになりました。

タスク処理中、Wenxin QuickCodeは現在のページを表示するだけでなく、プロジェクト内、さらには会社内における関連するすべての知識とファイルの依存関係も表示します。まるで建築家の仕事をしているかのような感覚になるでしょう。

QuantumBit : Wenxin Quick Code が企業全体のプライベート ドメインの知識を統合し、いくつかのプロジェクト レベルのタスクを処理するようなものです。

Baiduの孫克氏：はい。これも今回の私たちにとって非常に重要なアップグレードです。Wenxin Quick Codeは、企業のナレッジ全体を読み取り、活用する能力を強化します。Wenxin Quick Codeのような製品を企業に適用すると、コード生成が容易になり、企業の使用習慣に沿ったものになることがお分かりいただけるでしょう。

QuantumBit ：製品のアップグレードに関しては、企業のニーズをより重視していくのでしょうか、それとも既存の大規模言語モデルの機能をより重視していくのでしょうか？両者の優先順位は？

Baidu の孫克氏：正直に言うと、私たちは意思決定をする際に、顧客のニーズをより重視します。

多くのクライアントから、コード支援ツールは優れているものの、生成されるコードは社内の既存のナレッジベースや開発プロセスと密接に関連していないという報告を受けています。つまり、公開されているコード支援製品を社内利用に推奨する場合、APIなどの機能を含め、社内の既存のコードナレッジベースと統合する必要があるということです。

QuantumBit ：企業でも使えるようにするというこの位置づけが、Wenxin Quick Code の強みであり、独自性だと言えるでしょうか。

Baiduの孫克氏：Wenxin Quick Codeのポジショニングは非常にシンプルです。企業のお客様に活用していただきたいと考えています。R&Dのバックグラウンドを持つ私自身も、非常にシンプルに考えがちです。企業のお客様に最も直接的かつ即時のメリットを提供したいと考えています。実際、当社製品の強みは、企業の知識、R&Dプロセス、そしてR&Dエンジニアと深く連携する将来の機能との統合性にあると考えています。

QuantumBit : 私たちの経験に基づいて、エンタープライズとして位置付けられるプログラミング製品をどのように構築すべきだとお考えですか?

Baiduの孫克氏：まず、境界を明確に定義する必要があります。当社の製品は、機能を過度に多くの役割に拡張することはありません。例えば、当面はプロダクトマネージャー関連のPRD（製品要件定義書）機能を過度に扱うことはありません。主な焦点はR&Dの役割に置かれ、R&Dワークフローに沿って機能を計画し、プロジェクトの作成、開発、デバッグ、テストまで、あらゆる段階で展開を実施します。もちろん、実際の導入においては、手順や技術の成熟度といった問題が出てきます。

現時点では、Wenxin QuickCodeはまだ補助的なツールとして位置付けられていると評価しています。今後は、開発のあらゆる段階でプログラマーにとって価値のある機能を追求し、エンジニアがすぐに使えるようにしたいと考えています。また、将来的には、プロジェクト作成とプログラミングの自動化にさらに注力していくことも検討しています。

QuantumBit ：Wenxin QuickCode は AI プログラマーから AI アーキテクトに昇進しましたが、次にどのような役職に就くのでしょうか。

Baiduの孫克氏：アーキテクトの役職は既にかなり上位なので（笑）。これ以上の役職はおそらく与えられないでしょう。そうでなければCTOになってしまうでしょう。

ただし、機能面ではさらに多くの変更が行われます。例えば、継続的なコーディングからコード生成支援へとアップグレードされ、大規模なモデルの結果とプログラマーが記述しているコードを組み合わせることができます。レビュー機能に関しては、コードスタイルチェックだけでなくセキュリティチェックも含め、さらに強化されます。

さらに最近のアップグレードでは、ユニット テストを含むテスト機能の強化が行われ、今後 1 ～ 2 か月以内にリリースされる予定です。

したがって、彼らを「アーキテクト」と呼ぶことはもはやなくなり、 「フルスタックエンジニア」、つまり多くの問題を最初から最後まで解決できる人を指すようになるかもしれません。これが私たちの期待です。

重要な指標は、大規模モデルコード生成の普及率です。

QuantumBit ：将来的には、テキストからアプリケーションまで、エンドツーエンドでの生成を実現することも計画しています。エンドツーエンドは現在非常に重要なトレンドですが、これがいつ実現されるのでしょうか？

Baiduの孫克氏：その通りです。大規模モデルとは、大規模な言語生成モデルのことです。現在見られる大規模モデルの主流の応用や生成方法は、すべてテキストを直接生成するものであり、これはCエンド製品の主流の利用方法でもあります。また、大規模モデルはタスク計画やコード関連コンテンツの生成にも利用できます。このプロセスは、前述のエンドツーエンドのテキスト生成アプリケーションや、現在議論しているコードアシスタントなど、多くの応用形態を生み出しています。

もう一つのアプローチは、大規模モデルが現在備えているコードインタープリタ機能を利用することです。これは、まず大規模モデルからコードを生成し、そのコード実行をソリューション内でさらにラップすることで機能します。コードを生成するだけでなく、ランタイム環境で実行してから結果を返します。このステップの後、結果が直接返される場合もあれば、大規模モデルのリフレクション機能やデバッグ機能を利用して結果をさらに改良する場合もあります。

これは、現在のアプリケーション フォームに 2 つの大きな傾向があることを意味します。1つの傾向はアシスタントまたは副操縦士のロジックを指し、プログラムの最終的な操作と配信は依然としてプログラマーによって支配されています。もう 1 つの傾向はコード インタープリターのようなタイプで、プログラム全体の最終的な操作と配信は大規模なモデル自体によって支配されています。

これら2つのトレンドの興味深い違いは、プログラマ主導のアプローチでは、アーキテクチャ全体の安定性、スケーラビリティ、そして制御性が求められる正式な商用アプリケーションを開発できる点です。一方、大規模モデルのみから生成されたアプリケーションでは、比較的安定したパフォーマンスで、通常50～100行程度のコードで構成される小規模なアプリケーションを容易に開発できます。

したがって、これら2つのトレンドは徐々に収束していくと考えています。つまり、プログラマー主導のヘルパーアプリケーションは、1行か2行のコードを提供するものから、関数全体を推奨するものへと進化し、プログラマーはそれらを簡単に確認して確実に実行できるようになるでしょう。一方、より大規模なモデル駆動型アプリケーションでは、より複雑なエンドツーエンドのタスクを生成するために、ますます多くのコードを記述する必要があり、プログラムの自動実行が可能になります。将来的には、これら2つのアプローチが交差する日が来るかもしれません。

多くのスタートアップが既にこのコンバージェンスアプローチを実験しているのを見てきました。しかし、この道を進むには、プログラム全体と構造の安定性を確保するための数多くの計画上の課題に対処するとともに、綿密な検討を行う必要があります。実際には、前進するごとに、関連する問題の解決にこれまで使用されていたトークンの数倍が必要になる場合があります。

最初のトレンドに従うと、製品はユーザーと深くインタラクションできる設計が必要となり、インタラクションプロセスにおけるユーザーからの真のフィードバックや人間による確認行動を収集することで、大規模モデルにおけるますます複雑化するコード生成機能の最適化を支援する必要があります。一方、2つ目のトレンドは、製品の形態を探求するための良い道筋を示しています。

私が本当に楽しみにしているのは、大規模なモデルによって完全に駆動され、自動生成され、安定的で実用的、そして商業的に実現可能なアプリケーションが登場する時です。このアプリケーションは、プロダクト・マーケット・フィット（PMF）を達成した最初の製品の誕生を示すものであり、そこから後続の製品開発が加速していくと信じています。

この製品は最長3年以内に登場する予定です。製品形態については多くのアイデアがあり、まずは実際に製品化できるか試してみたいと思っています。その段階に到達すれば、ユーザーからの検証と商業的なフィードバックを得て、効率的かつ綿密なイテレーションを実施できるようになります。これにより、この方向への急速な成長も大きく促進されるでしょう。

もしかしたら将来、ウェブサイトにボタンやあらかじめ用意された関数が不要になる日が来るかもしれません。ウェブサイトに次に何をするかを伝えるダイアログボックスさえあれば、あとは大きなモデルがボタンを生成してくれるのです。ボタンをクリックするだけで、タスクは完了します。その日が来るのが本当に楽しみです。(笑)

QuantumBit ：Karpathy氏はかつて、自動プログラミングも自動運転と同様にL1からL4の開発段階に分けられると述べていました。コード生成におけるL1からL4の段階をどのようにお考えですか？

Baiduの孫克氏：L2とL4は念頭に置いていますが、中間のL3はまだ定義していません。L4は必ず到達すると信じており、その日もそう遠くないと思っています。

これは先ほど述べたことと似ています。プログラマー主導型の製品は、データ収集という課題に対処する必要があります。人間の行動、特に問題解決における人間の判断に関するデータを、優れた製品設計とインタラクションを通して収集する必要があります。一方、モデル駆動型の製品は、理想的なエンドツーエンドの製品形態の構築と、以前に収集されたデータに大きく依存するモデルの徹底的な改良に重点を置いています。したがって、両方の道筋を同時に追求する必要があり、どちらか一方が不可欠というわけではありません。

現在の自動運転と同様に、すべての新エネルギー車はレベル2を搭載していますが、レベル4はすでに開発が進められています。レベル2はレベル4技術に貢献する可能性があります。私たちは、この2つの道が融合し、真に私たちの手を自由にできる日が来ることを期待しています。

QuantumBit : Wenxin Quick Code チームも 2 つの並行した道を追求しているのでしょうか、それともより重点を置いている道があるのでしょうか?

孫克（百度） ：AIを高度に活用する企業として、百度は今後も多くの技術展開の可能性を追求していきます。同時に、これらの技術を迅速に実装し、すべてのユーザーに提供することにも注力しています。そのため、両方の道が存在すると想定しており、理想的な道を模索し、前進するために日夜努力する優秀なエンジニアが不足することはありません。

QuantumBit ：市場にはすでに多くのプログラミング製品が存在します。これらの製品を評価する際に役立つ重要な指標は何だと思いますか？

Baiduの孫克氏：素晴らしいお話ですね。プログラミング支援製品に対する業界の現状の理解は、「カーソルをここに置いたので、書き始めましょう」という程度にとどまっています。そのため、非常に一般的で頻繁に用いられる指標として、コードが書かれた後に採用されるかどうかがあります。私たちはこれを「採用率」と呼んでいます。私たちもこの指標を活用し、最適化に取り組んでいます。

しかし、長年戦略部門に携わってきた者として、この指標はR&Dプロセス全体の効率をどれだけ向上させたかを測る完璧な指標ではないと感じています。そのため、様々な機能に応じて様々なロジックを持つ、非常に断片的な指標も数多く開発してきました。

エンドツーエンドの指標にも取り組んでいます。プログラマーがどれだけコードを書いても、必ずチェックイン、つまりコミットが行われることに気づきました。現在測定しているのは、プログラマーが単位時間あたりに生成するコードの量が増加したかどうか、そして単位時間あたり1000行のコードのうち何パーセントが機械によって生成または修正されているかです。

このデータは、大規模モデルがプログラマーの開発プロセスのあらゆる側面にどの程度浸透しているかを示しています。したがって、私たちがより関心を持つのは、1000行のコードのうち、大規模モデルがどの程度影響しているかということです。

QuantumBit : この機能の有効性を表す、たとえば大規模モデルの浸透率の何パーセントといった理想的な数値はありますか?

Baiduの孫克氏：実のところ、浸透の度合いはどれも私の期待通りです。先ほども申し上げたように、Baiduのコードの20～30%はすでに大規模モデルによって生成されており、これが私の基準値と言えるでしょう。短期的には、1～2年で50～70%が適切なレベルだと考えています。

しかし、私の意見では、この比率は高ければ高いほど良いでしょう。将来的には、すべてのコード実装が大規模なモデルから生成され、プログラマーは大規模なモデルに要件を提供するだけで済むようになるかもしれません。そのため、この比率に上限はありません。

企業ユーザーと個人ユーザーの両方に一貫したエクスペリエンスを提供することが重要です。

QuantumBit : Wenxin Quick Code に関して、企業のプログラマーと個人の開発者では重点やニーズが異なりますか?

Baiduの孫克氏：非常に興味深い質問ですね。実は、今申し上げた指標は、企業が非常に懸念している点なのです。

個々のプログラマーは、自分の効率を詳細に測ることはありません。むしろ、日常のエンドユーザーのように、機能が使いやすく機能的かどうかを気にします。例えば、機能のクリックパスが最小限であるか、最もシンプルな方法で操作できるかなどを考慮します。中には、コードを書く際にマウスを使わず、両手をキーボードに置いて、キーボードショートカットのみで問題を解決するなど、オタク的なこだわりを持つプログラマーもいます。

ユーザーが実際に関心を持っているのは、各機能をより効率的にし、より少ないクリック数と操作で問題を解決するという目標を達成できるかどうかです。開発プロセスをそこまで詳細に定義する人はいないかもしれませんが、彼らは日々似たような作業に取り組んでいます。大規模なモデルを使えば、日常業務の80～90%を処理でき、最終的にはすべての操作が大規模なモデルによって支援されることになるかもしれません。これは、個々のプログラマーユーザーが最も期待していることだと思います。

QuantumBit : 個人プログラマーと企業プログラマーのさまざまなニーズのバランスを取り、満たすにはどうすればよいでしょうか?

Baiduの孫克：文心クイックコードには2つのバージョンがあります。1つはパブリッククラウド向けで、baidu.comを通じてパブリックドメインで直接検索・無料でダウンロードでき、高度な機能のための無料ポリシーもいくつか用意されています。もう1つはエンタープライズ向けで、関連する販売サービスとエンタープライズ展開を提供します。

個人ユーザーと企業ユーザーの違いは、彼らが真に関心を持っている問題が何であるかにあります。企業においては、企業知識のより深い統合と、関連する企業標準や研究開発プロセスなどとの緊密な連携に重点を置く必要があります。

パブリック クラウド バージョンの個々のユーザーにとって、オープンソース Web サイトからサンプル コードをすばやく取得して自分のプログラムに適用できるかどうか、また、プログラミング プロセスで発生した問題を Wenxin Quick Code フレームワーク内で解決できるかどうかの方が重要です。

需要の違い、つまりコーディング言語の分布にも違いが見られます。例えば、企業ではJavaなどの言語がより多く使用されていますが、パブリックドメインではJavaに加えて、PythonなどのAI関連言語の需要が高まっています。しかし、実際には両者の間に矛盾はありません。

両方のニーズを同時に満たすことができれば、企業のプログラマーが社員バッジを外して自宅で好きなことをしているときに、パブリッククラウドのユーザーになる可能性が高まります。全体的なエクスペリエンスの一貫性が非常に重要です。

QuantumBit ：企業をターゲットとする場合、企業エコシステムを構築するための対応策はありますか？

Baiduの孫克氏：より多くの企業がサービスエコシステム全体に参加することを期待しています。一部の配送会社は、Wenxin Quick Codeを自社の社内システムに深く統合したいと考えており、サーバー側とプラグイン側のみを残し、残りは自社のIDに合わせて再構築する必要があります。私たちは、こうした要望をエンタープライズエコシステムを通じて構築し、推進していきます。

例えば、エコシステム企業には、プラグインを含まず、バックエンドサービス機能のみを提供するバージョンとインターフェースを提供します。エコシステム企業は、関連するプラグインコードと外部プロモーションサービスを担当できます。さらに、製品をオールインワンのフォームファクターにパッケージ化した、より柔軟なバージョンも用意しており、エコシステム企業はこれを外部プロモーションや販売にも活用できます。

プログラマー教育のためのエコシステムも構築しています。中国には700万～800万人の正式雇用プログラマーがおり、その約10倍の人数がプログラミングを学んでいます。私たちは多くの教育機関と連携していきます。このユーザーグループへのアプローチは、いくつかの点で異なります。例えば、コードの作成やプロジェクトの理解を継続する支援だけでなく、デバッグなどの補助的な機能も提供します。これが、私たちのエコシステム開発の概要です。

QuantumBit : 最後に、視聴者に伝えたいことはありますか?

Baiduの孫克氏：本日は非常に楽しいお話でした。主な話題は、Wenxin Quick Code製品について、その製品化、具体的な機能、そして今後の開発計画まで、幅広く議論できたことです。当社の製品イテレーションスピードは非常に速く、今後1～2ヶ月で2回のメジャーバージョンアップを予定しています。パフォーマンスと機能の両面で大幅な改善が見られ、きっと皆様に驚かれることでしょう。どうぞご注目ください。

365業種におけるAI導入計画について

AI技術の応用はテクノロジー分野にとどまらず、あらゆる分野に浸透し、産業高度化を推進する重要な原動力となっています。そこで、「365業種向けAI導入ソリューション」プロジェクトを立ち上げました。様々な業界におけるAI技術の適用事例やソリューションを発掘し、より多くの業界関係者と共有していきます。