AI分野の権威であるアンドリュー・ンがマルチエージェントシステムの構築について語る講演である。AIスタックの構造からエージェント型AIの重要性、コーディング支援から視覚AI、音声技術、データエンジニアリングまで、現在のAI技術の主要なトレンドを包括的に解説している。特にエージェント型ワークフローによる反復的アプローチがAIの性能を大幅に向上させること、プロトタイピングコストの劇的な削減、PDF文書処理などの実用的応用について詳述している。
エージェント型AIとAIスタックの構造
これが私が考えるAIスタックです。半導体があって、その上にクラウドやハイパースケーラーがあり、その上に基盤モデル企業があります。AI分野では技術レイヤーに多くの話題が集中していますが、定義上、最大の機会はアプリケーション層にあるはずです。なぜなら、アプリケーションがより多くの収益を生み出して、技術プロバイダー層に支払いができるようになる必要があるからです。
私の焦点の多くは実際にアプリケーション層にあり、現在手にしているこれらの素晴らしいツールを活用してアプリケーションを構築することです。ただし、下位のすべての層も重要です。AIにおける最も重要なトレンドを一つ挙げるとすれば、それはエージェント型AIまたはAIエージェントだと言えるでしょう。
1年半前にエージェントに注目する価値があることを人々に説得するために講演を始めた時、昨年夏頃にマーケターたちがこの用語を手に入れて、ほとんど目に見えるすべてのものにこのステッカーを貼り付け、誇大宣伝を急上昇させるとは予想していませんでした。
エージェント型ワークフローの技術的視点
技術的な観点から、私がエージェント型ワークフローについてどう考えているかをお話しします。私たちの多くが大規模言語モデルを使用する方法は、応答を生成するようにプロンプトすることです。これは人間に、あるいはこの場合はAIに、最初の単語から最後の単語まで直線的に、一度にバックスペースを使ったり立ち止まって考えたりすることなく、エッセイを書いてほしいと頼むのと似ています。
人間はこのような書き方では最高の文章を書きません。AIも同様です。しかし、この単語の後に単語という直線的な書き方を強制される制約にもかかわらず、AIは驚くほど良い成果を出しています。
エージェント型ワークフローでは、はるかに反復的なアプローチを取ることができます。まずAIシステムにエッセイの概要を書いてもらい、必要に応じてウェブ検索を行い、ウェブページを取得してコンテキストに貼り付け、最初の草稿を書いてから、修正が必要な部分があるかどうかを確認するなどのプロセスです。
この反復的なワークフローにより、モデルは考える時間を持ち、修正を行い、さらに考えることができます。このループを何度も回ることで時間はかかりますが、はるかに高品質な成果物が得られます。この多段階ワークフローが今日のエージェント型システムの中核にあると思います。多くのビジネスプロセスを見直して、これらを自動化されたエージェント型ワークフローに実装する方法を考える作業が、私たちの前に多く横たわっています。
新しいAIスタック構造とオーケストレーション層
このAIスタックの図を次のように更新します。新しく登場するエージェント型オーケストレーション層があり、これにより基盤モデルやクラウド、その他のサービスへの複数の呼び出しを行うアプリケーションの構築がより簡単になります。良いニュースは、エージェント型オーケストレーション層により、以前よりもさらに簡単にアプリケーションを構築できることです。
結論として、アプリケーション層が依然として最も価値のある場所でなければならないということは、私には非常に明確に思えます。
興味深い動的要因の一つは、基盤モデルのスイッチングコストが非常に低いことです。実際、私は多くのワークロードを意図的にモデルの切り替えを容易にするように設計しています。新しいモデルが出ると評価を実行し、新しいモデルの方が良ければ2、3日でモデルを切り替えます。
エージェント型オーケストレーション層のスイッチングコストははるかに高く、これはこれらのオファリングを構築する企業やそれらを使用する企業の両方にとって、興味深い新しい動的要因を生み出します。興味のある方がいらっしゃれば、後でこれらについてもっと詳しく話し合えればと思います。
AIにおける5つの重要なトレンド
この講演の準備をしている時、もしあなたが一つの技術トレンドに注目するなら、エージェント型AIが最も重要なトレンドだと感じましたが、AIには非常に多くのことが起こっています。私たちの多くのビジネスに本当に影響を与えている、私が見ている他のいくつかのトレンドについて触れたいと思います。
実際に10のトレンドをブレインストーミングしましたが、この聴衆にとって最も重要だと思われる5つに絞りました。それは、コーディング支援、高速プロトタイピング、視覚AI、音声スタック、データエンジニアリングです。これらそれぞれについて比較的素早く説明していきます。
コーディング支援とプログラミングの未来
今日でも、一部の人々は、AIが自動化するからコードを学ぶなと他の人にアドバイスしています。これは今までに与えられた最悪のキャリアアドバイスの一つとして振り返られると思います。
コーディングが簡単になった時、パンチカードからキーボードとターミナルに移行した時のように、コーディングが簡単になったのでより多くの人がコードを書くようになりました。アセンブリ言語からCOBOLやより高級な言語に移行した時も、コーディングが簡単になったのでより多くの人がコーディングに参入しました。
ちなみに、COBOLが展開されている時に人々が書いた論文を実際に調べてみたところ、COBOLがあるので今やコーディングはとても簡単で、もうプログラマーは必要ないと主張する人々がいました。明らかに正反対のことが起こりました。
統合開発環境（IDE）から現在のAI支援コーディングに至るまで、各段階でコーディングは簡単になっており、これはより多くの人がコードを学ぶべきだということを意味します。
プロフェッショナルエンジニアにとって、これは本当に前例のないレベルの高速エンジニアリングを可能にしています。開発ツールはAIの中で最も急速に変化するセクターの一つです。Anthropic、Google、OpenAI などが大量のリソースをこれに注いでいるため、開発ツールは実際に非常に急速に変化します。
GitHub Copilotは2022年にリリースされたと思います。コード自動補完は素晴らしいものでした。その後、Windsurf、Cursorの世代のツールがあり、最近ではさらに高度にエージェント化されたコーディング環境があります。Claude Codeが2週間半前に登場しました。これは実際に素晴らしいと思います。私は個人的にClaude Codeを広範囲に使用しています。
これらのツールの改善レベルが猛烈なスピードになることを私はかなり確信しています。
非エンジニアにとってのコーディングスキル
プロフェッショナルソフトウェアエンジニアにとって、これは既に生産性に大幅な向上をもたらしています。また、非ソフトウェアエンジニアにとっては、将来、あらゆる知識労働者の最も重要なスキルの一つは、コンピューターにやりたいことを正確に伝えて、それをやってもらう能力だと思います。
マーケター、HR専門家、ファイナンシャルアナリスト、法務の分野で、コードを書く方法を知っている人が知らない人を上回るパフォーマンスを示しているのを実際に見ています。これは彼らが自分でコードを書いているという意味ではありません。AIにコードを書かせるよう指示しているという意味です。
私にとってこのことが明確になった経験の一つは、Courseraの「みんなのための生成AI」オンラインコースに取り組んでいた時でした。これはCourseraで開講年に最も急速に成長したコースでした。私たちはMidjourneyを使用してこのような背景アートをAIで生成する必要がありました。
私は美術史を理解している協力者のTommy Nelsonと一緒に仕事をしていました。Tommyは芸術の言語を理解していたため、パレット、芸術的インスピレーション、ジャンルといった芸術の言語でMidjourneyの画像生成システムにプロンプトを送ることができました。そのため、彼は本当に素敵なアートワークを生成するために細かい制御を行うことができ、私たちは結局彼の画像を使用しました。
対照的に、私は美術史を知らないので、「ロボットの綺麗な絵を作ってください」のようなプロンプトしか送れず、Tommyが示せるような制御を決して示すことができませんでした。私たちは結局Tommyの画像をすべて使用しました。
コンピューターにあなたのためのことをやらせる際も同様で、コンピューターについてより深い理解を持つ人々は、コンピューターにやりたいことをやらせるためのより正確な指示を与えることができます。
私のチームでは、コードの書き方を知っているマーケターがより興味深い実験を実行し、カスタムユーザーフィードバック調査を開始し、カスタムメールキャンペーンを実行できることがわかっています。そして、そうでない人々を圧倒的に上回るパフォーマンスを示すことが増えています。
ソフトウェア開発の二つの領域
ソフトウェア開発に関して具体的に言うと、私が行う作業の多くを、アイデアをテストするための迅速で雑なプロトタイプの構築と、本格的なソフトウェアの作成や従来のソフトウェアの保守という大まかな二つのカテゴリーに分けています。
どのアナリストレポートを信じるかにもよりますが、非常に厳密な研究を見つけるのは難しいですが、本格的なソフトウェアの作成や従来のコードベースの保守では、AI支援により30から50％の生産性向上が得られているかもしれません。これは巨大です。素晴らしいことです。その数字は実際には少し疑問視されるものだと思いますが、確実に大きな効果があります。
しかし、プロトタイプの構築では30や50％の生産性向上ではないことが判明しました。1000％や10倍の生産性向上、あるいはそれ以上です。
これにはいくつかの理由があります。プロトタイプや小さなスタンドアロンアプリの構築は、従来のソフトウェアインフラとの統合が少なくて済むことが判明しました。また、新しいアイデアをテストする場合、要件がはるかに低くなります。
私は本来言うべきではないのですが、私は定期的に自分のチームに行って「セキュアでないソフトウェアを書いても構わない」と言います。これは私を悩ませません。なぜなら、自分のラップトップでのみソフトウェアをテストしており、悪意を持って自分のラップトップをハッキングする意図がなければ、自分のラップトップでセキュアでないソフトウェアを実行しても問題ないからです。
迅速で雑なプロトタイピングでは、信頼性、セキュリティ、さらには使いやすさの要件も低いことがわかります。これにより、私個人や私のエンジニアの一部が文字通り午後一つで構築するプロトタイプが非常に多くあり、2年前なら3人のエンジニアが6ヶ月かけて行っていた作業です。
つまり、ソフトウェアエンジニアリングのコストは大幅に下がっています。プロトタイピングのコストは急落しました。これが意味することは、革新を追求するために、何が機能するかを確認するために大量のプロトタイプを構築することが経済的に実行可能になったということです。
経済学では、何かがはるかに安くなったら、それをたくさん購入すべきだということがわかっています。多くの概念実証が本格運用に至らないことに不安を感じている組織があることを知っています。私は実際には違う見方をしています。
概念実証の構築コストを十分に低く抑えることができれば、迅速で安価な死を遂げる18のPoCを構築することが、本当に価値のある2つを見つけるための代償であるなら、それは実際には素晴らしいトレードオフです。
高速で責任ある開発
「高速に動いて物を壊す」というフレーズは、物を壊したためにシリコンバレーで悪い評判を得ました。一部の人はこれを高速に動くべきでないという意味に解釈しました。私は代わりに自分のチームに「高速に動いて責任を持つ」ように言います。
賢いチームは、サンドボックス内や安全な環境で迅速にプロトタイプを作成し、配布し、テストするための多くのメカニズムを持っており、重大な不利益のリスクを冒さないことがよくあります。
大企業では失うものがあります。単一のエンジニアがクレイジーなプロトタイプを構築して配布し、個人情報を漏洩させたり、ブランドを傷つけたり、収益を損なったりすることは許せません。私たちには失うものがあります。
そのため、多くの企業には保護メカニズムがあります。何かを配布する前に、プライバシーレビュー、HRレビュー、法的レビュー、ブランド・マーケティングレビュー、コンプライアンスレビューが必要で、何かを配布する前に5人のVPのサインオフが必要になると、すべてが停止してしまいます。
しかし、エンジニアがそのサンドボックス内で自由に活動できるようにサンドボックス環境を事前に割り当てることができれば、それが下振れリスクを制限するため、チームが革新を行い、何がうまくいくかを確認するために大量のプロトタイプを構築することを可能にし、有望に見えるもののみがセキュリティ、信頼性などに投資してスケールアップするプロセスに進むことができます。
ビルディングブロックの急増
これを活用するためのビジネスの再設計が、プロトタイプをはるかに速く構築できる理由の一つは、はるかに優れたビルディングブロックがあるためです。過去数年間で起こったことは、AIのビルディングブロックの数が急増したことです。つまり、説得力のあるアプリケーションを迅速に組み立てることができるソフトウェアツールです。
視覚AIの可能性
まだ広く評価されていないビルディングブロックのカテゴリの一つは視覚AIだと思います。ChatGPTなどのテキスト処理革命が起こるのを見てきましたが、単なる生成ではなく視覚処理、つまり視覚分析も以前よりもはるかに良く機能しています。
エージェント型ワークフローでは、画像が与えられると、多くの視覚AIがこの入力を受け取って「これはコーヒーマグです」のような出力を生成します。多くの教師あり学習は画像を入力して「これは何ですか」と教えますが、エージェント型ビジョンでは画像を受け取って調べ、解釈し、再び調べに戻ることができます。少し考える時間を取ることで、おそらく数秒かかりますが、はるかに優れた分析結果が得られます。
私たちのビジネスで最も重要で価値のある単一のタイプの画像は、実際にはPDF文書の画像です。実際のところ、私たち全員のラップトップやデータウェアハウスには非常に多くのPDF文書があり、最近まで私たちのアルゴリズムには不透明でした。なぜなら、私たちのソフトウェアはこれらの文書の内部を覗いて情報を取得し、価値を得る方法がなかったからです。
私の親しい友人の一人であるDan Maloneyと私は密接に協力しており、Danと私はエージェント型文書抽出について多くのことを考えています。例として、医療フォームを見て、患者情報を抽出し、患者IDを抽出するなど、私たちのデータウェアハウスに閉じ込められているこれらすべてのフォームを処理できます。
こちらは金融レポートを読む例です。その画像から表形式のデータや数値を抽出します。こちらはグラフで、このグラフに何が含まれているかを示すためにこのグラフをキャプチャできます。
大量の文書を持つ多くの大企業や国家からの関心を実際に見ており、ついにその価値を引き出すことができるようになりました。
実用的なアプリケーション：請求書照合システム
エージェント文書抽出とAIコーディング支援のビルディングブロックを組み合わせると、これは私のエンジニアの一人が半日足らずでコーディングしたものです。
多くのビジネスでの一つのアプリケーションは請求書照合です。Office Depot、Staplesなどからの予想請求書のリストがあるデータベースを保存します。Staplesから65ドル50セントの承認された金額を期待しています。
しかし請求書があります。多くの一般的なビジネスプロセスワークフローです。請求書をアップロードして照合する必要があります。実際にこれは120ドルの請求書で、予想金額と一致しないのでアップロードしました。
請求書からフィールドとデータを抽出し、65ドルを期待していたのに代わりに請求書をアップロードしたため、抽出結果が不一致であることを示します。
これは私のエンジニアの一人がAI支援を使って半日少々未満でコーディングしたもので、文書から情報を取り出すビルディングブロックを使用しています。この技術の採用が急上昇しているのを見つけています。
あなたのビジネスの一部でPDF文書がたくさんあるなら、視覚的に情報を抽出して非常に迅速に多くの価値を得ることができます。
音声スタックの進化
視覚AI、特にPDFファイルに加えて、音声スタックについても非常に興奮しています。音声アプリケーションの構築は1年前よりもはるかに簡単になりました。
デモをお見せしようと思いましたが、これは私のアバターが話しているものです。今日聞こえるかどうかわかりません。少し聞こえますか。
音声インタラクションは多くのユーザーにとって非常に自然です。テキスト革命から始まりましたが、多くの使用例では、ユーザーに大きなテキストボックスを与えると、それは彼らに作文障害を押し付けることになります。なぜなら、多くのことについて考えるのが難しく、表現するのが難しく、状況によってはユーザーが思慮深いことを書いて与えるのが非常に困難だからです。
一方、音声では、多くの人が他の人と話すことに慣れているため、話すことについてはるかに快適に感じます。ほとんどのユーザーは書くよりも話す方が上手です。書くことは非常に難しいスキルです。
音声の最大の課題の一つは、回答の知能や正確性と遅延の間の緊張関係です。多くのエージェント型ワークフローでは、アバターを構築した際、最初は最大9秒の遅延がありました。何かを言った時、多くの人間の社会的ダイナミクスにより迅速な応答を期待するようになり、9秒待つ必要があるとそれは本当に困難です。
しかし、多くのビジネスアプリケーションでは、思慮深い応答も提供したいものです。カスタマーサービスエージェントを構築する場合、ビジネスポリシーを確認し、本当にそれを行いたいかどうかマッチングする時間がない限り、「絶対に、全額返金いたします」などとカジュアルに言ってほしくありません。
音声アプリケーションでは、ユーザーの期待が低遅延に対して非常に高い遅延と、高リスクでは間違ったことを言わないように知能と正確性、ガードレールとの間に大きな緊張があります。
しかし、これを解決する技術があることがわかります。私のチームが使用することの一つは、人と話す時、考えている時は「それは良い質問ですね」や「ああ、それについてはおそらくお手伝いできます」などと言って時間を稼ぎ、その間に正しい答えを生成するために考える時間を稼ぎます。私たち人間は自然にそれらのことを言いながら時間を稼いでいます。私のチームは実際に低遅延と高精度を得るためにこれらの多くの技術を構築しています。
データエンジニアリングの新展開
最後の主要なトレンドはデータエンジニアリングです。多くの企業が長い間データエンジニアリングの重要性を認識していますが、私たちの多くの努力は構造化データ、つまりテーブルと数字、Excelスプレッドシートに向けられていました。
しかし、生成AIのおかげで、非構造化データ、テキスト、画像、動画、音声、PDFファイルを処理する能力が大幅に向上しました。多くの企業が、非構造化データアクセスをどのように構築するかについてより多く考えながらデータを再設計しているのを見ています。そのデータをAIで処理することは、そのようなデータをどう処理するかわからなかった2、3年前と比べて多くの価値があります。
これを容易にしているトレンドの一つは、データ重力が減少していることです。データ重力とは、一つのクラウドにデータを置くと、そのデータが他のデータとコンピュートを引き寄せる傾向があるという考えです。処理のために1テラバイトのデータを一つのクラウドから別のクラウドに転送することは考えられませんでした。遅すぎて、高すぎるからです。
しかし、生成AI のワークロードは異なります。概算で、1ギガバイトのデータがある場合、クラウド転送またはクラウド出力コストは約10セントです。しかし、GPT-4 miniのような安価なモデルでも1ギガバイトのデータを処理するコストは30から40ドルです。
生成AIは処理集約的であるため、転送コストはもはやほとんど問題になりません。これが意味することは、処理するのが非常に高価であるため、処理のために世界中にデータを送信することに全く問題がないということです。
これは、世界中のあらゆる場所のパケットが、非常に複雑なワークフローを調整するためにベストオブブリードサービスを求めてあちこちに移動する、はるかに分散されたソフトウェアアーキテクチャを見ているということを意味します。
ワークロードを置いた一つのデータセンターにそれほど束縛されることはなくなりました。この選択性を活用するためのソフトウェア設計も行っています。より良いモデルが常にリリースされることがわかります。私のチームの多くのワークロードは、新しい言語モデルが登場した時に、迅速に評価を実行し、それが気に入ればbasically2日で新しいモデルに切り替えるように設計されています。
動的性と新しいビルディングブロックのためのオプション性を活用するためのワークロードの調整も、重要な設計上の考慮事項だと思います。
まとめ
まとめると、エージェント型AIに加えて、これらが私たちが行う作業に影響を与える5つの非常に大きなトレンドだと感じました。AIで起こっているすべてのことを考えると、アプリケーションの機会が爆発的に増加しています。これは素晴らしい時代です。どうもありがとうございました。
あなたはデジタルアバターを見せましたが、音声アプリケーションについても話していました。アバター部分は、人間がAIをどのように知覚するかという行動的観点から、AIの未来にとって重要だと思いますか？そこに人間の顔が必要でしょうか？
それは実際にはアプリケーションに非常に依存すると思います。スペクトラムの一端には、SiriやOpenAIのChatGPTなどのような、実体のない光る球体タイプのデザインがあります。そして、動物のアバターのように高度に漫画化されたものから、人の漫画化されたバージョン、ほとんど写実的な人間のアバターまであります。異なる選択に対してスペクトラムに沿って異なるものを選択していると思います。
非常に人間らしいものは、より多くの関係性価値を持つかもしれませんが、これには良い面と時には倫理的な課題もあります。漫画化されたものは一部の使用例ではあまり気を散らせませんが、その人間らしい関係性価値も少なくなり、これには長所と短所があります。
漫画化されたアバターは、おそらく専門的なアプリケーションには向いていませんが、多くの子供向けアプリケーションでは実際によく機能します。漫画的な人間は実際に興味深いデザインで、少しの関係性と信頼構築メカニズムがありますが、誰もこれを非常に人間的だと間違えることはありません。
アプリケーションスキルに応じてスペクトラム上の異なる外観を選択しているチームを見つけています。
またお会いできて良かったです、アンドリュー。ありがとうございます。アンドリュー、データエンジニアリングについて言及されましたが、ほとんどの企業にとってまだ非常につかみどころのないもののひとつは、データ品質、データの忠実性です。この問題に本当に対処するAIツールをあまり見たことがありません。この問題は30年前、40年前にデータウェアハウジングで始まり、まだ解決されていません。企業がその問題に役立つ何か新しいものを見たことがありますか？
魔法のような一つの解決策があるとは思いません。実際のところ、基盤モデルトレーニングチームや大規模言語モデルトレーニングプロバイダーを見ると、努力の大部分を占めるものの、それほど広く話されていないことの一つがデータエンジニアリングです。
これは通常のデータ中心AI のようなものです。ワークフロー構築は、不足している部分を見つけ、評価を実行し、より多くのデータが必要かどうか、強化が必要かどうかを把握することです。時には合成的に生成されたデータ、時には強化学習用のデータ、時には単にラベルトレース、そしてデータプロバイダーを見つけることです。
実際に、複数の基盤モデルトレーニング会社の複数の友人と話すと、このデータループが実際にははるかに大きく、多くの責任者が「どうやって言語モデルを訓練するためのデータを得るか」と悩んでいます。これは実際に生成AI以前のデータ中心AIエンジニアリングの日々からの同じワークフローのように感じます。
いくつかの素晴らしいアイデアをお話しします。エージェント型データ生成が非常に興味深いものだったと思います。AIエージェントを使って長時間考えてデータを生成し、それを使ってモデルを訓練して同じことをもっと速くやろうとします。
これは刺激的でした。私のチームが常に行っている興味深いことの一つは、データラベリングツールを構築するのは面倒でしたが、今私のチームはエージェント的にデータラベリングツールを書いています。新しいタスクがあります。新しいデータラベラーを構築しましょう。問題ありません。生成AIによって構築されているからです。
それらが私が見ている新しいことかもしれません。また、多くのデータリビング企業の友人がいます。現在、推論トレースに多くの努力が注がれていることがわかります。推論モデルの構築に多くの作業があります。
音声スタックモデルにも多くの作業があり、実際に多くの資金がより良い音声データの購入に使われています。これが私が音声スタックについて興奮している理由の一つです。ロードマップなどを見てきたことを知っているからで、複数の企業から来年にわたってはるかに優れた音声モデルが登場するでしょう。
テキストから今どこに向かっているかのトレンドが見えています。そして私のチームは実際にPDFファイル用のデータに多くのお金を費やしており、私たちがLanding AIで見ているPDF抽出の採用は間違いなく今そのように進んでいます。
素晴らしい講演でした、アンドリュー。あなたがそれを切り分けた様々な方法が気に入りました。コーディング部分について質問があります。vimのスクリーンショットがあったのが良かったです。1年前まで、私はコアなvimユーザーでしたが、今では私のやり取りの95％がチャットウィンドウを通じて行われています。
そして、コードに手を出すのは5％の時間だけです。この進化が次にどこに向かうと思いますか？コードを編集する回数対エンドツーエンドフローを行う回数の比率はどうなるでしょうか？あなたの考えを聞かせてください。
よくご質問をいただく用語にバイブコーディングというものがありますが、残念ながらそれはそれについて考える良い方法ではないと思います。AI支援コーディングは非常に重要で、バイブコーディングという用語は人々に「ああ、私は雰囲気で行って、すべての変更を受け入れるんだ」と感じさせますが、そうではありません。
AIアシスタンスを使ったコーディングは深く知的な作業であり、半日または一日それを行った後、率直に言って私は疲れ果てます。なぜなら、それは非常に困難で、高度な思慮深さとスキルを必要とするからです。
私が見ているのは、高速エンジニアリングという新しい分野のようなもので、以前よりもはるかに速く物事を構築できます。Copilotの最初のバージョンからCursorやWindsurfの世代、そして現在のClaude CodeやおそらくOpenAIのCodexのようなさらに高度にエージェント化されたコーダーへと進むにつれて、これらのツールのエージェント性の度合いは増加していますが、これを操縦するアーキテクチャを理解することは依然として非常に重要です。
明確な製品センス、製品要件、AI製品管理を持って、到達したい製品の最終目標について明確な感覚を持つことは依然として本当に困難です。大規模な製品管理の改善は実際には見ていません。AIがより速くデザイン作業を行えることは知っていますが、何を構築すべきか、なぜ構築すべきかを考え抜くことは依然として非常に困難です。
言及したい素晴らしいトレンドの一つは、私たちはコードを非常に貴重な成果物として考えることに慣れていました。私のエンジニアがコードを書くのにそれほど多くの時間と労力をかけました。しかし、特定のタイプのワークロードでは、もはやコードは貴重な成果物ではありません。なぜなら、私は半日でコードを構築し、来週には「違うテキストスタックを使ってすべてのコードを最初から書き直そう」と言うからです。
かつてはテキストスタックを選択したら行き詰まっていましたが、今でもテキストスタックを選択することは重要ですが、一部のアプリケーションでは、すべてではありません。変更が非常に困難な従来のソフトウェアもありますが、プロトタイピングではコードはもはや貴重な成果物ではありません。毎週それを再設計しましょう。
ある程度の成熟度まで、その後それは実用的ではなくなります。あるいは、データベーススキーマを再設計して、AIにデータベースマイグレーションをやってもらいましょう。それは私を悩ませません。私が作業をしているのではありません。AIが作業をしています。
あなたの作業の安定した部分と、もはや毎週捨てることができない神聖なものではない部分を考え抜くことは、非常に興味深いダイナミクスでした。
コメント