この動画は、Factory AIのCEOであるMatan氏が、AIエージェントを活用したソフトウェア開発の未来について語るインタビューである。従来のIDEから脱却し、エージェントに作業を並列委託する新しい開発パラダイムや、システム思考の重要性、そして5-10年後の展望について詳しく議論している。特に、少数の人間が大量のバーチャルエンジニアを指揮することで、従来では解決不可能だった大規模な問題にも取り組めるようになる未来を描いている。
Factory CEOが語るソフトウェアの未来
5年後はどのような世界になるでしょうか。私は、アイデアから問題解決に至るまでの過程で、実際にはるかに効率的になれると思います。以前は1000人必要だったところが、たった10人で済むようになるかもしれません。
解決すべきソフトウェアの問題の中には、地球上のすべてのエンジニアでも対処できないほど巨大なものが出てくるでしょう。
これらの個人が問題を抱えたとき、バーチャルエンジニアの軍団を使ってその問題を解決できるようになります。私たちは線形スケールで考えることに慣れています。しかし、多くのテクノロジーは指数的スケールで動作します。舞台裏で使われている技術には何があるでしょうか。最も重要な3つのことがあります。まず第一に…
Factory設立の背景
Matan、今日は参加していただき、ありがとうございます。Factoryについて、そしてソフトウェアエンジニアリングの未来についてお話しできることを楽しみにしています。
Factoryは従来のIDEとは非常に異なって構築されています。実際、従来のIDEではありませんし、それはおそらく、AIを使った今日のソフトウェアエンジニアリングがどこにあるかだけでなく、将来どこに向かうかについてのあなたの信念を反映しているのでしょう。まず、なぜFactoryを構築したのか、その背景を教えてください。
Factoryを構築し始めた理由についてお話しします。Factoryの前は、10年間理論物理学者として弦理論に取り組んでいました。様々な理由で、それが自分にとって正しいことだと思っているからではなく、非常に難しいからという理由で頑固に追求し続けていました。
結果的にバークレーでPhDを取得することになり、バークレーにいる間にAIの大学院コースを探求し、当時プログラム合成と呼ばれていた、今では単にコード生成と呼ぶものに恋に落ちました。それに完全に夢中になり、AI研究に完全に切り替えることになりました。
それはいつ頃のことでしたか、Matan？
2022年の非常に初期、2022年の始めでした。
コード生成が本当に興味深いと思った理由は、10年間の理論物理学、特に弦理論の経験を通じて、非常に基本的で汎用的なものを評価するよう訓練されたからです。コーディングやソフトウェア開発が人工知能全体の中で非常に汎用的な役割を果たしているのは、モデルがコーディングにおいて持つ能力と、他のあらゆる下流タスクでの能力との間に密接な関係があるからです。
詩を書くことであれ、研究質問に対する思慮深い回答を作成することであれ、一般的にモデルがソフトウェアエンジニアリングに優れているほど、ほぼすべての他のタスクでも優れているということです。これは一種の非常にコアな機能であり、これが数学者や物理学者を惹きつけるタイプのものです。だからこの分野には多くの数学者や物理学者がいるのです。
これが私をこの分野に興味を持たせた最初のきっかけでした。
新しいインタラクションパターンの必要性
IDEの外での新しいインタラクションパターンに特に興味を持った理由について、Factoryで大切にしているヘンリー・フォードの名言をお話ししたいと思います。「人々に何が欲しいか聞いたら、より速い馬と答えただろう」という言葉です。
私たちがソフトウェアエンジニアリングの未来を見る方法は、IDEが約20年間存在し、開発者は非常に馴染みがあり、IDEを使って構築する方法について非常に根深いパターンを持っているという既存のパラダイムがあるということです。そして誰もが、ソフトウェア開発は今後5年間で大きく異なる見た目になるという一般的なコンセンサス的見解を持っています。
開発者がIDEを使ってコードのすべての行を書いていた世界と、開発者が本質的にコードの0%を書くことになる世界との間には、少し不一致があります。
一つのアプローチは、開発者がすべてのコード行を書くこの世界から、彼らがコードの0%を書く最適なプラットフォームまで反復することです。
私たちの見解は、そのアプローチは馬から車への反復を試みるようなものだということです。歴史家である必要はありませんが、私たちは馬から車へと反復したわけではありません。私たちは車を一から構築しました。輸送の問題に対するこれらのアプローチの違いを理解する第一原理から構築したのです。
エージェントネイティブなソフトウェア開発
これは、エージェント的ソフトウェア開発や私たちがエージェントネイティブソフトウェア開発と呼ぶものへの異なるアプローチと幾分類似していると思います。
これらのアプローチはどう違うのでしょうか。開発者の理想は常に「この作業が何であるかを理解し、それを可能な限り速く、そして明らかに可能な限り信頼性高く実装するにはどうすればよいか」です。テストのようなことを行い、オートコンプリートのようなもので、より速くコードを書くでしょう。それがそこで推進されるパラダイムです。
一方、私たちがこのエージェントネイティブアプローチで取っているアプローチでは、ソフトウェア開発者の心の中での考え方が「これをより速く完了させるにはどうすればよいか」から「この大きなタスクがある場合、それを離散的で分離可能で検証可能なステップに分離し、それをエージェントに委託して並列で作業してもらい、より速く完了させるにはどうすればよいか」にシフトします。
ここでの違いは、何かをより速く連続で作業することと、何かを並列化することです。明らかに、同じ問題を4つのステップに並列化できる場合と、連続でわずかに速く作業する場合では、並列化できる場合のスピードアップはずっと劇的になります。
並列化の威力
AIプロダクトを使用している中で最大のワオモーメント、つまり最も印象的な瞬間は、それを並列化できるときです。それが本当に実感できた最初の瞬間は、ChatGPT OperatorやOpenAI Operatorを見たときでした。
タスクを開始すると、これは数分、数十分の長期間タスクになる可能性があります。そして2番目のタスクを開始し、複数のエージェントが私が連続的に行わなければならなかったことを実行していることを知るだけで、とても印象的でした。
だから私は、複数のエージェントが並列で実行してタスクを達成するというビジョンを信じています。
コード生成能力がこれらのモデルの他の強力な能力の上流にあるとおっしゃいましたが、週末に出たAppleの論文をご覧になりましたか？話題になりました。おそらくご覧になったと思います、笑っていらっしゃるので。基本的には「推論の錯覚」というものです。
彼らはモデルが自然言語で必ずしも推論していないかもしれないことを示す論文を発表しました。それを示すために、彼らはパズルを設定し、一定の複雑さを超えると、モデルは実際にパズルを解くことができませんでした。しかし、論文で欠けていたのは、エージェントやLLMがパズルを解くためのコードを書く能力で、これはどんな複雑さでも完璧に行えます。
LLMがコードを書いて論理を行い、推論してパズルを解く能力は、それが知能なのでしょうか？その論文についてどう思われますか？あなたがおっしゃったことと関連して、とても興味があります。
知能とコーディング能力
完全に開示しますが、私はその論文を読んでいません。要約を読んだだけで、全体を読む時間がありませんでした。しかし、そのタイミングはAppleの現在のAI市場での立場を考えると、かなり興味深いものでした。
コーディングは知能でしょうか？今の時代について本当に面白いと思うことの一つは、知能という概念自体が本当に疑問視されていることです。LLMが何かを行うたびに、私たち人間は「でも、それは知能ではない。それは単なる記憶化だ」とか「それは単にトレーニングデータからの摂取ですよね。単に補間しているだけだ」と言おうとします。
それが知能かどうかを判定する本当に良い簡潔で一貫した定義を見たことがあるかどうか分かりません。ARC prizeは知能の汎化やパターンマッチングなどについて、かなり興味深いことを行っていると思います。
一つ非常に明確なことは、モデルのトレーニングデータに特定のタイプの問題がより多く存在するほど、またはRLのようなポストトレーニングに存在するほど、それらのタスクでより良い性能を発揮するということです。これにより、私たちは自然に「実際には学習していない。勉強したもので良い成績を取るだけだ」と言いたくなりますが、それは人間でも同じです。
私たちはこの種の問題からその種の問題への汎化能力がより優れているかもしれません。Sarah Guoが先日言っていたと思いますが、人々がAGIや知能について話すとき、彼らが実際に暗示しているのは偶然にも意識だということです。これらのことは、私たちがそれについて話すとき、無意識のうちにかなり混同されていると思います。
より直接的にあなたの質問に答えると、特定のコーディング問題を解決するには知能が必要だと思います。その指標によれば、これらのモデルは確実に知能を持っています。彼らがトレーニングデータの外で最も汎化可能な知能を持っているか？いいえ。しかし、それは研究所が取り組んでいることです。
モデルがコードを書く能力は、自然言語で物事を解決するよりも、より多くの汎化を与えると思います。興味深いことですが、並列化に戻りたいと思います。
エージェントの並列作業
過去数十年間、人間のエンジニアチームは一緒に働いてきましたが、通常は同じコードの部分で作業することはありません。そこには多くの競合が生じるからです。私たちはそれらの競合を解決するためにgitを持っていました。エージェントが並列で一緒に働く方法は、人間のチームがやっていた方法とどう違うのでしょうか？
素晴らしい質問です。これは、より能力の高いソフトウェア開発エージェントが増えるにつれて人間の役割がどこに適合するかという答えにもつながります。
最も重要なことの一つは、機能1の実装と機能2の実装のような完全に異なるタスクであれば、明らかにそれらを並列化できることです。しかし、あなたが言及したように、類似したコア機能で変更を行っている場合は、マージ競合に対処する必要があります。
人間が本当に重要になると思うことは、例えば機能1内で、それをサブ問題に分離する最適な方法を理解することです。重要なのは、これらのサブ問題を並列で作業できるように分離可能にしたいということです。
人間のエンジニアがこれを最適な方法で行う能力を可能にするスキルは何でしょうか？それはシステム思考です。システム思考は、とにかく最高のエンジニアを作ってきたものです。
最高のエンジニアは、すべてのプログラミング言語のあらゆる細かいニュアンスの詳細を知っている人ではありません。最高のエンジニアは常に、システム思考が最も優れ、制約に関する推論を理解することが最も優れている人でした。
今、私たちには新しいインタラクションパターンとソフトウェア構築への新しいアプローチがあります。制約に関してシステム思考を行い、それから実装する必要があるのではなく、可能な限り早く到達したいのは、エージェントが行うためのステップの適切にパッケージ化されたセットと、これらのステップが達成されたかを知るための検証や妥当性確認基準のセットです。そのパッケージができたら、それをエージェントに投げて実装してもらうのです。
プログラミング学習の価値
システム思考について言及していただいて嬉しいです。私は私の立場でも、おそらくあなたもよく聞かれると思いますが、「まだプログラミングを学ぶ価値はあるのでしょうか？」という質問です。私にはまだ小さな子供が2人います。
私が今まで学んだ最も重要なスキルセットは、プログラミングを学ぶことでした。それにより、頭の中のアイデアを、他の誰かに頼ることなく、自分で構築できるようになりました。数年前なら、「はい、私の子供たち、これが最も重要なことです。プログラミングを学びに行きなさい」と言ったでしょう。
しかし、疑いを持った時期もありました。しかし、今はシステム思考に結び付けて考えてみましょう。私が今まで学んだ最も重要なスキルセットの一つは、プログラミングだけでなく、そのシステム思考の要素でもありました。エージェントがコードの大部分を書くことになっても、システム思考はワークフローとそして人生全般において依然として非常に重要です。それが私の意見です。あなたはどう思いますか？
まったく同感です。実際、少し議論を呼ぶかもしれない意見ですが、現在高校や大学にいる子供たちにとって、それがコンピューターサイエンスか数学か物理学か生物学かはそれほど重要ではないと思います。
重要なのは、膨大な量の密集した情報と数百年の歴史があり、現実的にすべての詳細を学ぶ時間がない問題空間のように見える分野に入ることができることです。そして、すでに多くの天才が生涯を費やして分野を前進させてきたこの分野に入り、数年以内に自分が立っている山を理解し、必要なものを引き出す能力を持ち、学ぶ時間がない細かいニュアンスの詳細があることに慣れながらも、少し地平線を押し進めることができる能力を持つことです。
物理学で10年間過ごしたので偏見があるかもしれませんが、類推として、黒板で作業し方程式を使用するたびに、使用するすべての定理を再導出することはしませんでした。それは非常に非効率的だからです。
しかし、人生のある時点でその導出を行い、頭の中でそれを行う必要があれば導出し直すことができることが本当に重要だと思います。ソフトウェア開発でも幾分似ていると思います。
大学の標準的なカリキュラムでは、ベアメタルから高水準プログラミング言語まで学びます。ソフトウェアエンジニアとして、実際に機械語を使うことはあるでしょうか？おそらくないでしょう。しかし、その理解を持つことは本当に役立ちます。
職業的な物理学者や数学者として、計算機を使うでしょう。その場で再証明しない定理を使うでしょう。しかし、ある時点でそのプロセスを学び、それを行う方法を理解することは依然として重要です。すべての定理を当然のものとして受け取ったり、コンピューターサイエンスで基礎の多くを無視したりできるからといって、それは後で問題になるからです。
これらの分野のこの情報の山を通り抜ける経験がないからです。そのどの詳細のニュアンスを知ることが重要で、どれについては曖昧な理解でも瞬間的には大丈夫かを理解し、前進し続けるスキルセットです。
抽象化レイヤーとエージェントオーケストレーション
あなたが説明しているのは抽象化レイヤーだと思います。ソフトウェアエンジニアリングとエンジニアリングエージェントに戻ると、多くの人が「エージェントをオーケストレーションするのか？エージェントの作業をチェックするのか？」と疑問に思っています。
いずれにしても、基礎を知ることは重要になるでしょう。実装するすべてのアルゴリズムを再導出したり使用したりしなくても、実際にその作業を行うエージェントをオーケストレーションし、エージェントの作業をチェックできるようになるためには、基礎を知ることが重要です。
エージェントについて続けたいと思います。過去2年間で、ソフトウェアエンジニアリングがどれほど変化したかは絶対に衝撃的でした。まず、ソフトウェアエンジニアリングがAIで最も変化したことが驚きでした。そして変化の速度も。
あなたは今後数年のビジョンを説明しました。エージェントをオーケストレーションし、IDEから抽象化するという。5年後はどのような世界になるでしょうか？10年後はどのような世界になるでしょうか？明らかに、そんなに先のことを予測するのは不可能または非常に困難ですが、あなたのビジョンを聞きたいです。
5年から10年後の展望
5年先を予測することは非常に分散が高いことに同意します。2020年に今の状況を予測できた人はおそらく少数だったと思います。各モデル世代とどの程度良くなるかの複合効果があり、それがその後の各年に影響を与えるからです。
このような予測に関して本当に重要だと思うのは、第一に、人間は複合について考えるのが本当に下手だということです。これは私が最初に言っているわけでも最後に言うわけでもありませんが、私たちは線形スケールで考えることに慣れており、現実は多くのテクノロジーが指数的スケールで動作しているということです。
これについてのミームがあります。Daniel Coco Tyloのブログからのものです。これは、私たちが指数について推論し、非線形性を理解することが本当に得意ではないことを強調しています。この例では、世界のGDPは最も馬鹿げた指数の一つです。
それでも、2010年から2020年まで、人々はそれほど狂った進歩があったとか、物事がそれほど良くなったとかは感じなかったと思います。一方で、それはほぼ垂直ですよね。
同様の程度で、今後5から10年について考えるとき、物事がどのようになるかについて高い信頼度で予測することは非常に難しいと思います。これらのことについて考えようとするときの指針として言えることは、私たちの最初の目標は何だったかということです。
ソフトウェアエンジニアリングは、ソフトウェアのためだけに開発されたわけではありません。コードを書くためだけにコーディングを始めたわけではありません。ポイントは特定のものを構築し、人間として行えるよりもはるかに速く計算を行えるこれらのコンピューターを使用したかったということです。しかし、それは目的への手段でした。
計算のためだけではありませんでした。世界中で非常に素早くコミュニケーションを取れるようになりたいとか、新薬を発見するために特定の科学現象をシミュレートできるようになりたいとか、ドライバーが迎えに来て場所に連れて行ってもらえるように調整でき、タクシーを呼ぶのに30分待つ必要がないといった、シンプルなことでもありました。これらがより効率的にできるようになりたかったのです。
これらが目的であり、手段がソフトウェアでした。なぜなら、人間のシステムだけでできるよりも効率的に、機械を使ってこれを行いたかったからです。機械とコミュニケーションを取るために、この非常に正確な言語を学ぶ必要がありました。
そして、徐々にその言語をより抽象的にしていきました。機械にバイトで話すのは非常に非効率的だからです。そして、これらの言語でより高いレベルの抽象化を持つ方がより効率的です。
この傾向は続くと思います。長い間、思考する機械の夢について、スティーブ・ジョブズが70年代後期または80年代前期に書いた素晴らしいエッセイがありました。私たちはこれらの機械とどう協力するかを理解するために、コーディングを深く掘り下げなければなりませんでした。
今、私たちは実際に成し遂げたいことの目的に再び焦点を当てることができる地点に戻ってきています。
長々と回り道をして質問に答えると、今後5から10年で、私たちははるかに多くの問題をはるかに速く解決できるようになると思います。
以前は1000人のエンジニアと10年かけて会社を築くのに必要だった問題も、アイデアから問題解決への過程で実際にはるかに効率的になり、1000人の代わりに10人だけ必要になるかもしれません。
しかし同時に、それだけを考えると、企業の人数は減り、1万人の企業はもうないという軌道になりそうですが、実際には競合する力があると思います。数百のエージェントにタスクを委託できる1万人のエンジニアがいれば、ソフトウェアの規模と範囲の観点で可能になることも劇的に増加します。
今でも10万人のソフトウェアエンジニアの組織をどう調整するかを考えるのは難しいですが、Microsoftのようにそれを行う組織があります。問題はどれだけ効率的かです。確実に非効率性はありますが、5から10年後のこの世界では、100万人のソフトウェアエンジニアの出力のような、私たちが本当に理解することさえできない複雑さのソフトウェアを持つことができます。100万人のソフトウェアエンジニアの出力がどのようなものかは想像するのさえ難しいです。
楽観的な未来への展望
私が正しく理解していれば、あなたは実際に非常に整合した、非常に楽観的な未来への見解を持っているようですね。私は数日前に動画を出しました。それは将来の就職市場、経済、未来がどのようになるかについてのものでした。
多くの人は、あなたが言ったように、製品を構築するのに1000人のエンジニアが必要だったのが今は10人で済むなら、企業は990人を解雇するだろうと考えています。
しかし、私には反例があり、はるかに楽観的な見解を持っています。対処可能な問題の総宇宙が劇的に増加するからです。問題Xを解決するのに10人しか必要でなくなったが、今度は問題Y、Z、アルファなどがあり、それらすべてのエンジニアをそれに向けることができ、彼らは超強化されるのです。
長期的には、上に一人がいて、エージェントの軍団に満ちた一人会社が10社だけあるとは思いません。そうはならないと思います。ロングテールの問題の経済学、価値の低い問題ではなく、その問題を解決するための知能投資の数学的採算が取れなかったが、もうすぐ採算が取れるようになるかもしれない問題があると思います。
100%そうです。一般的に、特定の問題の総取り扱い可能市場は、それを解決するために投入されるエンジニアの数やお金の量を大まかに決定します。世界中の20万人にのみ適用される問題があるとします。明らかに、その20万人の支出力がその特定の問題のTAMを決定します。
以前の世界では、それは数百人のエンジニア分の作業を解決することを意味するかもしれません。しかし今では、数千人にのみ適用される問題があっても、10万人のエンジニアに相当する作業をその解決に向けることができます。それは本当にクールだと思います。
つまり、2000人の問題があっても、理想的な世界では彼らが問題を抱えていないので、解決する価値があると思います。今では、その問題を解決するためにこの火力を向けることができます。
そして、それは一人の問題のセットまで範囲が縮小されるかもしれませんよね。その時点で、ソフトウェアを作成することが非常に安価になり、一人の人の問題への解決策のROIが収益性のあるものになります。
それは本当に興味深いです。しかし、それは非常にロングテールです。非常に小さな対処可能な問題について話しています。しかし、この未来に向かって加速するにつれて、あなたが言ったように、私たちが考えることさえできない、私たちが知らない巨大な問題もあると思います。
おそらく将来の話ですが、星に拡張するにつれて、地球上のすべてのエンジニア、人間のエンジニアでも対処できないほど巨大な解決すべきソフトウェア問題が出てくるでしょう。そして今、人間のエンジニアそれぞれが自分のエンジニア軍団で超強化されている未来があり、おそらくそれらの問題も結局取り組み可能になるのです。
全くその通りです。あなたがそれを説明する方法でも、私が気に入っているのは、それ自体が目的としてのソフトウェアエンジニアリングではなく、これらの個人が問題を抱え、それからバーチャルエンジニアの軍団を使って問題を解決できるということです。宇宙を探索するなど、何でも、途中で問題があり、それをより効率的に解決してもらうのです。
効率の向上は明らかに純粋な善だと思います。
Factoryの設計哲学
Factoryに戻りましょう。私が使い始めたとき、そして使い続けている中で最も印象的なことの一つは、設計です。実際のUIだけでなく、UXも含めてです。使用体験です。明らかにIDEではありません。
設計について、Factory内でのUX/UIがどこに向かっているか、そして人間がプロダクトとどのようにインタラクションするかについて何を意味するかを教えてください。
私たちのデザイナーCalに大きな賞賛を送りたいと思います。彼は実際に私の兄です。彼と一緒に働けるのは爆発的に楽しいです。
私たちの設計についていくつかのことがあります。本当に素晴らしいことの一つは、Calのバックグラウンドが実際に工業デザインだということです。彼はアメリカ最高の美術学校RISDに行きました。
Factoryには世界最高のエンジニア22人がいますが、私たちにとって本当に重要なことは、ソフトウェア開発者向けに構築されたものを設計する際に、異なる視点を受け入れることです。なぜなら、素朴に考えると、開発者による開発者のための製品だから、開発者と話して、これがここにあるか、あれがそこにあるかを決めればいいと思うかもしれません。
しかし、UIUX全般での彼のバックグラウンドからの少しアウトサイダーの視点を持つことは、私たちがこれを再考する上で本当に価値がありました。なぜなら、私たちが行っているゲームの一部はIDEから離れることであり、世界最高の開発者たちは過去何年間もIDEを使用してきたからです。
実際にIDEで働いたことがない人を持つことは役立ちます。なぜなら、習慣が染み付いていないので、この新鮮な視点を持っているからです。これは物理学でも非常に似ています。物理学では27歳が常に最高の年齢のようで、物理学者が27歳のときに最高のアイデアが生まれます。それは、空間についてのコンテキストを持ちながらも、思考方法について非常に染み付いて習慣的になっていないこのバランスがあるからです。だから、すべてを疑問視する能力がまだあります。
これは設計面で非常に役立ちました。そして物事がどこに向かっているかについて。先ほど述べたように、私たちはその類推で車を構築しようとしており、より速い馬のような、IDEでより多くのAIを作るという反復的アプローチから離れています。
ここでの夢は、人間が手動でコードを編集する必要がないこの世界にますます近づくことです。それには、ソフトウェア開発者が何を成し遂げたいかについての明確な計画を提供することが必要で、それは単に「ダッシュボードを作って」というようなものではありません。
行動を引き出したい、または適切な制約をソフトウェア開発者から引き出したいのです。そうすることで、彼らが実際に考えていることが何であれ、実際に実装する際にできるだけそれに忠実になれます。
また、それを検証するための決定論的な方法があることも確実にしたいです。これは少し愚かな例ですが、青いダッシュボードを作りたいとしましょう。または、FactoryにFactoryのテーマに沿ったダッシュボードを作ってと頼み、それがピンクのものを作ったとします。それは明らかに私たちの現在のデザインシステムの違反です。
私たちが望むのは、Factoryがその間違いを犯したとしても、私が考えていた制約に違反するようなものを作ったとしても、それを見つけて反復できる方法があることです。そうすれば、私に「完了しました」と連絡し、私が見に行ってピンクで「ちなみに私たちはダークモードで行います」と言う必要がないのです。
人間の開発者からこれらの制約を明示的に得るか、時間とともに学習して毎回言う必要がないようにするインタラクションパターンを形作ります。
また、ソフトウェア側では、検索とコード生成性能が最先端であることを確実にします。このコードを実行するドロイドが、出力と客観的な結果に基づいて反復できることを確実にします。「これらのテストを実行し、これが失敗したのを見たので、それに基づいて反復しましょう」というように。
これをより完璧にできればできるほど、人間が手動でコードを編集する必要が少なくなります。これにより、エージェントネイティブな未来に向かって押し進められます。そこでは、ソフトウェア開発者が本当にしなければならないことは、何を完了させたいかの明示的な計画と範囲を持ち、それをエージェントに送信することだけで、エージェントがそれに取り組みます。
Factoryの技術的アプローチ
Factoryは企業のコードベースを本当によく理解しています。舞台裏で使用されている技術のうち、共有していただけるものはありますか？FactoryのドロイドがコードベースのパターンやFilesを理解し、同じパターンでコードを書き、すべきでない変更を行わないことを可能にするFactoryに独特の技術は何ですか？
おそらく最も重要な3つのことがあります。それぞれについて説明しましょう。
第一にファーストパーティ統合、第二にメモリ、そして第三にローカルおよびリモートコード実行です。
ファーストパーティ統合について説明します。MCP serverは素晴らしいです。IDEのようなものを使用している場合、モデルに情報を取得する素晴らしい方法だと思います。
大規模なコードベースや大規模な組織にとっての欠点は、これの多くがアドホックで計算されることです。これは人間のエンジニアがどう働くかとは非常に異なります。
コードベースで働く人間のエンジニアは、空白のメモリを持ち、問題に取り組み、作業していることに意味的に関連するものを見つけて勉強してから作業するということはしません。一般的に、彼らはコードベースの状態やエンジニアリング組織の状態について事前計算された理解を持っており、問題に入るときに「これはあれに関連している」ことを知っているので、この問題に取り組む際のショートカットをすでに知っています。
私たちも似たようなことをします。GitHub、Slack、Jira、Sentry、DataDogなどとのファーストパーティ統合があり、これらの間の関係を事前計算します。
Notionに、行おうとしている変更を概説するエンジニアリング設計文書があったとします。それには、それを知らせた顧客要求や顧客問題も含まれているかもしれません。そして、その変更やその機能を実際に出荷したときの関連するPRがあります。そして、そのPRに基づいてSentryで障害が発生します。
今、このすべての異なるものをMCPで取り込み、何が関連するかを事前に理解しようとする代わりに、私たちは「ここにこの問題があり、これはこのコード行と関連付けられ、これはこの設計文書のためにこのPRから追加された」ということを知っています。
これにより、これらの問題を解決したり、これらの変更をはるかに速く行うことができます。
MCPは素晴らしいですが、大企業や大規模なコードベースを扱う際には、ファーストパーティ統合は多くの時間を節約し、はるかに高品質な結果を提供します。少し脆弱性が少ないです。
メモリについて教えてください。ChatGPTのメモリは非常に重要な機能で、とても多くのより良いインタラクションを可能にしたからです。メモリはFactoryにどのように組み込まれるのでしょうか？
メモリは基本的にFactoryがあなたについて、そして基本的に異なる抽象化レベルで学習することを可能にするものです。
大規模な組織と協力している場合、組織メモリがあります。組織全体がどのように機能するか、出荷している製品について、直面している顧客について、スタックについて、これらのようなことです。
しかし、その組織内のサブチームである場合、チームレベルでのメモリもあります。あなたのチームが他のチームがしないことをする特定のことがあるかもしれません。Factoryはそれらについても学習します。
そして個人レベルまで下がって、あなたのコーディング方法と、常に忘れる特定のことについて。Factoryはそれを学習し、時間とともに「この人はPRを提出しようとしている。彼らは常にテストを書くのを忘れる。だから彼らのためにテストを書こう」ということを知るようになります。
または「このチームは、PRがどのようになる必要があるかについて厳格な要件を持っている」ので、PRを提出しようとするたびに、Factoryはそれらの制約に適合するように調整します。
これは時間とともに学習して向上するものであり、また、組織やチーム、または個人のリーダーとして、手動で何かを変更したい場合は、このメモリのいずれかを修正することができます。
3番目の要因もありました。
3番目の要因は、単純にコードを実行する能力です。重要なのは、基本的に2つの方法でそれを行えることです。
複数のドロイドをクラウド環境で立ち上げて送り出し、100並列で異なるタスクに取り組んでもらうか、またはローカル環境、つまりあなたのデバイスで行うことができます。
アイデアは、よく範囲が定められており、送り出すことに満足しているタスクがある場合は、リモート環境のドロイドに送ることです。もう少しハンズオンでモニターし、おそらく手綱を取りたいものがある場合は、あなたのマシンのローカル環境で実行してもらうことができます。
その実際の実行により、単にコードを生成し、勘で撃ち、動作することを望むのではなく、実際に実行して、コンパイルされ、テストに合格し、期待通りに機能的に動作することを検証できます。これは人間のエンジニアがどのように働くかに非常に似ています。人間は動作すると思うPRを提出するだけではありません。
実際に実行して「これは私が望んでいたことを実際に行ったか？すべて合格しているか？」を検証します。
非技術企業への影響
Factoryは高品質のコードを書くこと、大量のコードを書くことを簡単にしています。書くための書くのではなく、先ほど話していたように多くの問題を解決するためです。
これにより、垂直SaaS企業がどうなるかを考えています。以前、企業組織が非技術的で、ソフトウェア企業ではなく、技術製品を構築していない、内部でソリューションを構築するための余剰エンジニアがいない場合、Factoryのような企業は、非技術企業が独自のツールを内部で構築することを採用すべきだと思いますか？
絶対にです。実際、私たちの最大の顧客の何人かは、最終的に彼らのコアコンピテンシーがソフトウェアを構築することではありません。例えば、その一つは、アスピリンを作るドイツの製薬会社Bayerです。彼らは私たちの顧客の一つです。
明らかに、彼らはソフトウェアを出荷していませんが、現実は今日のすべての企業がかなりの量のソフトウェアを持っているということです。販売しているものでなくても、ドロイドにタスクを委託したり、おそらく法外な金額を支払っているが、実際に提供するもののサブセットしか必要としない巨大なレガシーソフトウェアがある場合、組織としてのレバレッジを増やすことが非常に重要です。
「内部で自分たちで構築できる」のです。
または、ソフトウェアがビジネスのコアコンピテンシーでない場合、おそらく少ないエンジニアを持つことになるので、より速く出荷できます。持っているエンジニアには、最も最先端で生産性の高いツールで武装してもらいたいし、エンジニア1人あたり複数のエージェントに委託できるようになると、乗数効果も得られます。
なるほど。つまり、はい、非技術企業、特にFactoryがソフトウェア構築に長い経験がない人でも優れたソフトウェアを実際に構築することを容易にしているからこそ、それが理にかなっていると思います。
その線で続けたいと思います。Factoryのような製品はソフトウェア構築のコストをゼロに向かって押し下げています。それは垂直SaaS企業をどうするのでしょうか？
今は本当に興味深い時代だと思います。これは実際に、この10倍がすべてのエンジニアを10倍にする場合、人員削減するのかという話に戻ります。それは競争というものが存在しない場合にのみ真実でしょう。
現実は、すべての競合他社も各エンジニアを10倍にできるということです。だから、人員削減して生産性を維持するのは良いですが、人員削減しなかった競合他社は100倍生産的になり、あなたを塵の中に置き去りにするでしょう。
これはソフトウェアの消費者にとって素晴らしいことです。なぜなら、消費しているソフトウェアの各部分のバーが大幅に高くなるからです。各企業にはまだこのゲーム理論があり、世界で唯一AI にアクセスできる企業なら、確かに人員削減しても最先端を維持できるでしょう。
しかし、競争のダイナミクスは、良いソフトウェアのバーが劇的に上がるようなものです。90年代に本当にクールなウェブサイトを持つのに多くの時間がかかったのと似ています。
しかし今では、クールなウェブサイトを非常に素早く作成できるツールが非常に多くあるため、素晴らしいウェブサイトのバーが劇的に上がったのです。90年代の素晴らしいウェブサイトは、今では基本的な要求事項ですよね。
Factoryの今後の展開
最後の質問です、Matan。人々は何にワクワクすべきでしょうか？あなた方は何を構築することを考えていますか？今後6か月で何を構築しているのでしょうか？
ワクワクすべきことは、エージェントがはるかに信頼性が高く、はるかに高品質になるということです。はるかに少ない指導で、やりたいことを成し遂げることができるようになります。
今見ているのは、このエージェントネイティブソフトウェア開発に非常に傾倒している人々がFactoryを使って魔法のような時間を過ごしていることですが、彼らはまだ1万人の開発者がいる組織にいます。
AIやエージェントについてそれほど盛り上がっておらず、何をやりたいかを説明するために入って実際に良心的な努力をすることにそれほど乗り気でない人々がいます。
今後6か月で、AIエージェントについて気にしない人でも、EmacsでAIがない古い方法でいたい人でも、Factoryを1分だけ試してみれば、魔法の体験を得るポイントに到達すると思います。そして、それは本当に人々をこの新しい世界に変えるでしょう。そこでは、開発者としてより高いレバレッジを持ち、それがあなたを力づけるのです。
人々は本当にそれにワクワクするでしょう。
Matan、今日は私と話していただき、ありがとうございました。とてもワクワクしています。Factory AI。以下の説明にすべてのリンクを載せます。再度ありがとうございました。
参加させていただき、ありがとうございました。
コメント