この動画は、決済プラットフォームStripeの共同創設者であるPatrick Collisonが、プログラミング言語の選択、AI技術の活用、そしてStripeにおける重要なエンジニアリング判断について語ったインタビューである。Collisonは自身の初期のスタートアップでSmalltalkを使用した経験から始まり、LispやRubyといった言語への思い入れ、そして現在のAI時代におけるプログラミング環境の進化について詳しく論じている。また、Stripeの技術的な意思決定の背景、API設計の重要性、そして組織運営におけるプログラミングの概念の応用についても深く掘り下げている。
冒頭の挨拶とSmalltalkについて
お越しいただき、ありがとうございます。こちらこそ、お招きいただき、ありがとうございます。こちらに来ることができて嬉しいです。
あなたの最初のスタートアップはSmalltalkで書かれていたと聞いています。説明していただけますか。
説明することがあるかどうかわかりませんが、それは最高のプログラミング言語なんです。
私はそれより前にLispとLispの方言に取り組んでいました。実際、Lispのウェブフレームワークに取り組んでいて、最初のスタートアップを構築する際に、まずRailsで実装しました。しかし、Lispと比較すると、開発プロセスがかなりフラストレーションの溜まるものでした。詳細に立ち入る必要はありませんが、継続ベースのウェブフレームワークが、ウェブアプリケーションを実装する正しい方法だと思っていました。
Rubyには継続がありませんし、継続ベースのフレームワークもありません。いろいろ探し回った結果、Smalltalkで書かれた良いフレームワークが見つかったので、少し試してみることにしました。そして、Smalltalkが実際に非常に興味深い開発環境であることを発見しました。私が本当に評価していたLispの多くの側面を持っていたのです。
適切なデバッガーを備えた完全にインタラクティブな環境のように、ウェブリクエストの最中や、深いスタックトレースの中でも、コードを編集できるのです。例えば、ウェブリクエストでエラーに遭遇した場合、エラーを修正するためにコードを編集し、スタック上位で再開することで、ウェブリクエスト全体が完了するようにできます。
ログステートメントを追加して、バイナリサーチのようにして問題を見つけ、最終的に修正版をデプロイするという、1時間かかる可能性があるこの煩わしいフィードバックループではなく、文字通りスタックフレームを調べ、どの変数が間違った値を持っているかを確認し、それを修正して、上に戻って続行ボタンを押すだけで、全体が動作するようになるのです。
とにかく、この継続ベースのウェブフレームワークを求めていた過程で、Smalltalkが一般的に、RubyやSlash、基本的に他のすべての主流プログラミング言語と比較して、はるかに強力な開発環境を持っていることを実感しました。
そこで、その言語を会社で使用することにしました。振り返ってみると、それがひどい判断だったかどうかはわかりません。なぜひどい判断だと思われるかというと、人を雇うのが困難で、スケールが難しく、その他諸々の理由があるからです。しかし、人を雇うのは困難ではありませんでした。むしろ、誰もそれを知りませんでしたが、会社で教えるのは簡単でした。
入社前に知っていましたか？
いいえ、知りませんでした。しかし、本当にすぐに覚えましたか？
はい、賢い人は言語を本当に素早く学びます。ですから、主流ではない言語を使わない理由にはならないと思います。会社はうまくいきませんでした。関連のない理由だと思います。アイデアがそれほど強くなかったのだと思います。しかし、Stripeには Rubyを選択しました。ですから、よくわかりません。利益がそれほど大きくなかったのかもしれません。
そのスタートアップの買収企業は、あなたのSmalltalkへの熱意を共有していましたか？その力学はどのようなものでしたか？つまり、無知な経営陣がSmalltalkのコードベースを何も知らない開発者たちに押し付けて、彼らがそれを乗り越えようとしていたような状況でしたか？
買収後の状況とAIボット開発の経験
プログラマーと経営陣の間の力学はどのようなもので、そのSmalltalkコードベースに何が起こったのでしょうか？
それは今でもどこかで生きているのでしょうか？願いたいのですが、答えは99%確実にノーです。私たちを買収した会社は、主に人材獲得でした。そのため、コードベース自体はそれほど重要ではありませんでした。すぐに消えてしまいました。
あなたの最初のプログラミングプロジェクトの一つが、Lispで書かれたAIボットの開発だったとも聞いています。
それは本当です。MSNのクライアントのようなものでした。どこでそれを見つけたかは知っていますが、それは事実です。そして、それにチューリングテストを通過させようとするアイデアに、いわゆる「ナードスナイプ」されたと聞いています。
はい、ChatGPTを作らなかった理由について、もう少し真剣に、どのように機能したのか、当時のニューラルネットワークの状況はどうだったのか、そして今日私たちが使用している技術の前身を考慮したことがあるかどうか、好奇心があります。
それは当時大流行していたMSNメッセンジャーを使用する小さなクリッターのプロジェクトでした。それは異なるインスタントメッセージングソリューションの年代学における特定の堆積層のようなもので、おそらく私の年代を正確に示しているでしょう。
それは本当にシンプルなベイジアンの次単語予測子でした。そこには本当に洗練されたものはありませんでした。何かしら洗練されたものがあったとすれば、一般的なテキストコーパスではなく、MSNメッセンジャーでそれ自体が行った会話をトレーニングデータとして使用していたことでしょう。
そしてそれは合理的によく機能しました。より良いバージョンでは数単語先を見て、そのようなことを行いました。人々が実際の疑念を抱いて、この識別能力を行使しようとする場合、それは決して本当にチューリングテストを通過しませんでした。
しかし、彼らが疑いを持たず、人々が最終的にそれとかなり長い会話を行うような、より弱いバージョンのヒアリングテストは確実に通過しました。
Lispの発見とプログラミング言語の進化
それが私のLispの発見の一部でした。Peter Norvigの「AIプログラミングのパラダイム」が本当に形成的な本だったことを覚えています。そこにはさまざまな興味深いアプローチがありました。ニューラルネットワークについては何もなかったと、ほぼ確信しています。
私は決して、Marvin Minskyの「心の社会」や何らかのニューラルネットワークに関する資料を読んだことがありましたが、それらを真剣に検討したことはありませんでした。実際、遺伝的アルゴリズムを多く実験しました。
それらは、あなた自身のコンピューターでより実用的だったと思います。ニューラルネットワークをトレーニングするには多くのコンピューターが必要ですから。そこで、遺伝的アルゴリズムを多く実験しました。
実際、私はDvorakキーボードレイアウトを使用していますが、それはQWERTYより入力が快適だからです。私の兄弟Johnも同じですので、誰も私たちのコンピューターを使用できません。しかし、最適なキーボードレイアウトが何であるかを調べるために、遺伝的オプティマイザーを書きました。
結果的に、遺伝的アプローチを使用すると、実際には基本的にDvorakであることが判明しました。その兎穴にかなり深く入り込みましたが、ニューラルネットワークを実際に試したことはありませんでした。それが、おそらく他の70の理由とともに、私がChatGPTを作らなかった理由です。
Automaticを売却した後のインタビューの古いビデオがあります。そこでSmalltalkについて尋ねられています。そこでその奇妙な事実を見つけました。当時、なぜそうするのかと尋ねられた時、あなたはSmalltalkやLispスタイルの言語の機能が好きだと言い、2008年頃だったと思いますが、主流のCスタイルプログラミング言語がこれらのより古いプログラミング言語からアイデアを借りるようになると予測していました。
それはJavaScriptやPythonのエコシステムである程度実現されています。主流に借用されるべき、より古いより難解なプログラミング言語に埋もれた過小評価されたアイデアがあると思いますか？
多くのアイデアがJavaScriptエコシステムに借用されてきたことは興味深く、奇妙な方法でウェブインスペクターを通じて行われています。そこには、人々が一般的に露出している最も豊富なランタイムの一つがあります。
JavaScriptにはファーストクラスのスタックフレームがあるとは思いません。何かしら奇妙な拡張があるかもしれませんが、ECMAScriptにはそれがないと確信しています。ファーストクラスのスタックフレームは、明白な理由から、実際に他の多くのことを可能にします。
それは特定すぎるかもしれません。開発環境でありテキストエディターだけでない、という基本的なアイデアが本当に正しいアイデアだと思います。それが私が復活を見たいものです。
それはLispマシンとGeneraが持っていたもので、ある程度Mathematicaが持っているものでもあります。それがSmalltalkが持っているものであり、ランタイムとテキスト編集、そしてコードが実行される環境の間にこのような分離がある開発環境に行き着いたのは、本当に間違いだと思います。
ランタイムとコードが実行される場所は同じでも異なってもかまいませんが、概念的に若干異なる3つのものがあり、これらの3つの環境はすべて同じ場所に共存できます。
今日でも、特に難解な記号数学を行っているわけではありませんが、より効率的な開発環境だからという理由で、Mathematicaを多く使用しています。LLMsのせいで、それは少し真実ではないかもしれません。MathematicaはCursorスタイルのプロンプト開発をサポートしていないからです。
しかし、それが他の人に借用してもらいたいコアアイデアだと思います。VS Codeはある程度その方向への一歩でしたが、もっとずっと進めることができると思います。
理想的な開発環境とプログラミングの未来
例えば、私がコード行にマウスを置いた時、そのコードまたは関数のプロファイリング情報やランタイム特性を見たいと思います。変数にマウスを置いた時に、ログやエラー情報が重ねて表示されるのを見たいと思います。本番環境で取る最も一般的な値のような、これらの種類の豊富で深い統合を見たいと思います。
あなたは「原理に基づく発明」のファンですか？そして、はい、Brettには大きな敬意を持っています。ただ、Brettは少し偏りすぎていると思います。Brettの大ファンで、彼は本当に素晴らしい人です。Dynamiclandに行ったことがありますか？はい、そして支援もしています。
Brettの大ファンです。私が多少異なる意見を持っているか、少なくとも私にはそれほど響かない点は、Brettが現象に対するグラフィカルで視覚的な表現のアイデアに本当に没頭していることです。
それは彼がアイデアを実演した動的システムのような特定の領域では非常にうまく機能すると思います。しかし、Stripeのさまざまな部分のような任意のシステムに対して、そのような有用な空間的連続表現を見つけることは非常に困難だと思います。
それを見つけることができたとしても、それがどれほど有用かは確実ではありません。それは私だけかもしれません。私は視覚的やグラフィカルよりも、記号的で語彙的により多く推論します。それは個人的な好みかもしれませんが、わかりません。
彼が従事している種類のパラダイム破壊は、非常に称賛に値すると思います。
真の統合開発環境を作る予定ですか？
私たちは、AIがバックグラウンドで時間を取って、コードを実行し、出力に反応することを増やすというアイデアで遊んでいます。そして、これらすべてがうまく連携すべきだと思います。
私たちは、フロー、スピード、コントロールに大きく焦点を当てています。それがAIにとって本当に重要だと思います。プログラマーにすべてのコントロールを与え、AIが生成するすべてのものを理解してもらうことです。また、本当に高速な反復ループを提供することです。プログラマーは待つことを嫌います。
しかし、場合によっては、AIに少し考えてもらってから戻ってきてもらい、APIが他の人間とのAPIのようになることが可能になってきていると思います。そして、それらがすべてうまく連携することを望んでいます。
AIは70%の何かを持って戻ってくることができ、それを非常に迅速にフォアグラウンドに持ち込み、作業し、再びバックグラウンドにスピンオフできます。AIがバックグラウンドで多くの時間を費やして考えることの一部として、その思考を有用にするために、コードを実行してそれに反応する必要があります。そうでなければ、書いたものをただ見つめてより多く考えるだけになります。
質問をするのは私ではなく、答えるのが私の役割だと思いますが、5年後、私がCursorで主に見ているものはコードだと思いますか、それとも他の何かだと思いますか？
他の何かかもしれないと思います。非常に大きな単純化ですが、ソフトウェアの一部が何であるかを定義する際には、エンジニアがソフトウェアの動作を正確に設計することに多くの時間を費やすロジックコンポーネントがあります。
エンドユーザーアプリケーションやGUIを持つもののための視覚的コンポーネントもあります。私たちか他の誰かかもしれませんが、AIとの相互作用の方法が、人間のヘルパーに仕事を委任したり、あなたが次に行うことを予測したりするのではなく、コンパイラやインタープリター技術の進歩のようなものになる世界のバージョンがあると思います。
それは、プログラミング言語が実際に変化し、より形式的でなくなり、より高レベルになり、どのようにするかではなく、何を望むかについてより多くなることができる世界につながる可能性があります。
それは必ずしもGoogleドキュメントのようには見えないと思います。プログラミングから保持したいものがあると思います。ロジックをどこかで命名し、それを他の多くの場所で使用するようなことです。
ソフトウェアの外観についての視覚的要素もあります。私たちか他のツールかもしれませんが、UIの直接操作がもう少しそれに関わってくる世界があると思います。
しかし、これらは遠い実験的なアイデアです。一般的に、過去20年間にプログラミングのパラダイムをそれほど実験していないことが興味深いと思います。ここで議論している多くのものは80年代や70年代のものです。
明らかに、過去よりもはるかに多くの開発者が今います。しかし、実験の範囲は本当にそれほど広くないと感じます。JavaScriptエコシステムや他のいくつかがクールなことを行い、RustやGoやその他すべてで言語レベルでの実験もありましたが、開発環境レベルでは、なぜそうなのかわかりませんが、今は難しく複雑すぎるのかもしれませんが、期待していたほどではありませんでした。
同感です。私たちが取り組んでいるものがこれに役立つかもしれないと思います。それがCursorの成功をある程度説明することを願っています。久しぶりに本当に真剣に取り組んでいる最初の人たちです。
私たちは、素晴らしい新しい色で描くことができるという新しい色や色のセットから多くの利益を得ていると思います。
プログラミング言語には、プログラマーがコンピューターがどのように機能すべきかを正確に定義するための複雑なUIである頭の中のニューロンと、多くのロックインがあると思います。人々は言語を学び、そして人々は多くのことを学びたがりません。
また、一つの言語に多くのロジックがあり、それを維持する必要があるというロックインもあります。実際、私たちの希望の一つは、AIプログラミングがより良くなるにつれて、何百人もの人々と何百万行ものロジックを扱う専門的なアプリケーションに取り組むことの欠点の一つが、コードベースの重さが本当にあなたを圧迫し始めることです。
新しいコードベースにいる感覚、すべてが楽に感じられる感覚が失われます。すべてが雑用になります。ここで一つのことを変更すると、別の場所で何かが壊れ、それが大きな泥のボールのようになります。
その楽な感覚を作り出し、既存のロジックセットの重さを軽減することは、AIがプログラミングをより良くできる分野の一つだと思います。
コード整理とAIの役割
今日、Twitterで誰かが言っていました。Andre Karphathyかもしれませんが、誤って帰属させているかもしれません。Andre Karphathyにはあまりにも多くのバイブコーディングに関することが、ChurchillやEinsteinのように帰属されています。
しかし、この人が誰であれ、コードの作成をプロンプトすることは一つですが、AIが大いに助けになる可能性がある別の場所は、コードベースの美化とリファクタリングだという観察をしていました。あなたが前で少し不格好で、完全に正しく因数分解されていないデトリタスを生成し、その後、夜間にこれがあなたの後ろから来て因数分解することを想像できます。
私が唯一受講したCSクラスは、Jerry Susmanの授業で、彼は大規模記号システムと呼んでいましたが、実際には、修正しやすいコードベースと環境と抽象化を作成するアイデアに焦点を当てていました。
クラスには、ゼロから何かを書く課題はありませんでした。すべての課題は、既存のシステムを修正することに関するものでした。そして、それらの修正をどのように設計すれば、かなり深い修正であっても、簡単になるかを考えることでした。
それは明らかに美しいアイデアです。実際には、今日や来週に出荷したいもののすべての緊急性と圧力を考えると、それを行うことは非常に困難です。しかし、これらのものを書いている時に、美しい方法でそれをすべきだと気づくことがよくありますが、そうしていません。
おそらく、それを清掃するAIを後ろに持つことができるでしょう。はい、おそらく間もなくです。
多くの開発者に起こることの一つは、物を作ることを気にかけるため、または多くの人が物を作りたいために開発に来るということです。コンピューター画面で物事を起こしたいのです。そしてそれがコーディングにつながります。
多くの開発者グループに起こることは、彼らが最終的に作成したいソフトウェアがあまりにも大きく、すべてのコードを自分で書くことができないことに気づくことです。そして、コードを書くのを手伝ってくれる人間に頼む必要があります。
そして、彼らはエンジニアリングマネージャーやディレクターになったり、会社を始めたりするかもしれません。そうすると、ほとんどの仕事はコードを入力することではなくなります。人々の間での調整になります。
ソフトウェアを一緒に構築するために人々のグループを組織にプログラミングする行為に役立つプログラミングからのアイデアはありますか？
APIとデータモデルの重要性
興味深いです。APIとデータモデルを本当に真剣に受け取ることだと思います。
Stripeですべてを再びやり直すとしたら、異なってやりたい百万の小さなことや、いくつかの大きなこともありますが、おそらく予見可能で有益に異なってできたと思うことは、APIとデータモデルにさらに時間を費やすことです。
その理由の一部は、Conway’s lawの効果で、これら両方のものが組織を形成することになるからです。それを深く内在化しなければ、あなたが持ちたいと思うよりも組織のダイナミクスに対するコントロールが少なくなるかもしれません。
しかし、それは組織を形成するだけでなく、Conway’s lawの弱いバージョンは組織を形成するというものですが、強いバージョンは、それが戦略と単純にビジネス成果を実質的に形成するというものだと思います。
それのバージョンとは正確には違うかもしれませんが、長い間、おそらく今日でも、iOSソフトウェアエコシステムがAndroidアプリエコシステムよりもはるかに活気があり、重要で成功していたかを私はよく考えます。
これら二つのエコシステムには多くの異なることがあります。今、使用されているAndroidデバイスは、iOSデバイスよりもはるかに多いと思います。
しかし、アプリ開発者がiOSでアプリを構築し、最初にiOSでアプリをリリースし、iOSバージョンがAndroidバージョンよりも良いことを好む傾向があったという事実の多くは、iOSのフレームワークと抽象化が単純にAndroidのものよりも元々優れていたからだと思います。
しかし、それは正しいAPI設計、正しい抽象化設計が、かなり重要なビジネス的な影響を与えることになった場合だと思います。
おそらく、技術では全てが非常に迅速に変化するので、これらのことに時間を費やす価値がないという感覚があるかもしれません。あなたが作る仮定は何でも、2年後には時代遅れになるでしょう。
しかし、実際にはそれは真実ではないと思います。正しいAPI設計と正しい抽象化、正しいデータモデルは本当に持続できます。iOSの最初のバージョンでは、使用したクラスの多くがNSで始まっており、それは当然NextStepの略です。それは、API設計が20年以上持続した例です。
Stripeの場合、Stripeは今15年になり、15年前に設計した多くのことが今日でも使用されています。それは良いことでもあり悪いことでもあります。持続したという意味では良いことですが、私たちは今でもそれらの欠点と共に生活しています。
とにかく、それが私が思い浮かぶ最初のことです。
Stripeの技術的選択と長期的影響
実際、その最後の点について、シリコンバレーの著名で成功した民間企業のエンジニアリングリーダーと話していました。彼らのコードベースは主にScalaで書かれており、スタートアップの始まりを、疲れた、過労で、おそらく過度にカフェインを摂取した創設チームメンバーがこれらの初期技術決定をやみくもに行い、それが将来の何百人もの専門エンジニアの生活を左右するビッグバン瞬間として考えるのが好きだと言っていました。
そのScalaの選択はその一つでした。彼らは今その欠点と共に生活しています。Stripeのビッグバンで、あなたたちが今でも共に生活している、良いものか悪いものか、結果的な初期条件は何でしたか？
そのメタファーは私には真実に聞こえます。私が最初に言いたいことです。
生存者バイアスが少しあるかもしれません。実際の声明は、私たちが変更しなかった初期の決定が、私たちが共に生活している決定であるということですが、そこにはタウトロジーのようなものがあります。
確実に、私たちが非常に早い段階で行った設計決定で、今日では真実でないものもあります。ダッシュボードの初期バージョンなどは、今日のダッシュボードとは全く異なって構築されていました。
逆も真実です。最初、StripeでMongoDBを使用することを決定し、RubyをStripeで使用することを決定しました。これらは今でもStripeで非常に基本的な技術です。
MongoDBを必要な程度に故障に対して寛容で、分散され、耐久性があり、信頼性があり、すべてのものにするために、多くのインフラストラクチャを構築する必要がありました。
Stripeの重要なAPI可用性は昨年99.99986%でした。これは年間を通して44秒の利用不可能性です。他の人たちは、これほど詳細な統計を公開していませんが、これは業界で最高だと信じています。
ストレージチームや他の多くのチームが構築したすべてのものが、そこで本当にうまく機能しましたが、それはかなり重要で決定的な初期決定でした。
Rubyも同様に、企業は途中で言語を変更することもありますが、選択された初期言語は持続する傾向があると感じます。
Stripeでは、またはStripeの歴史の早い段階ではなく、私たちの集合的な個人の歴史の早い段階で、私たちの共同創設者の一人がいました。彼は、潜在的なJava移行についての文書が山のようにあったことを覚えています。
それは部分的に起こりました。つまり、多くの主要なサービスをJavaで書き直しました。特にスループットが本当に重要ないくつかのサービスでは、Rubyを十分に苦しめて、ホットパスの一部をCや何かで書き直すことができれば、かなり高速にできますが、アロケーターと戦うことが多く、Ruby文字列でさえそれほど効率的でないなど、さまざまな部分があります。
そのため、特定のサービスをJavaで書き直しましたが、現在は両方を使用しています。
なぜ、または早い段階で他の何かを考慮しましたか？なぜそれを選んだのですか？そのためのRFC プロセス、RFPプロセス、意思決定プロセスは何でしたか？
それは私とJohnだけでした。ソファに座って、使うべきかどうかを話し合いました。
彼らはブログで、またはその時のオープンソースコミュニティでの評判や何か他のものであなたに伝えましたか？
前の会社のためのデータストア、オブジェクトベースのデータストアを書いたことがあります。SQLが本当に好きではありませんでした。アプリケーションのドメインとSQLが本来表現可能にするもの との間に、翻訳的な不適合が多すぎると思いました。
SQLでは、明らかに比較的制限された原始的形式のセットに折りたたまなければなりませんが、アプリケーションでは、Stripeの場合のお金のような概念があり、それは使用している特定のSQLデータベースがお金を表現する方法と正確に一致しない場合があります。
そして、私はSQLに対して原理的な反対意見を持っていました。これが良いことだったとか推奨するとは言いませんが、このインタビューが示すように、技術について奇妙な考えを多く持っていました。
Stripeでは、前の会社よりも主流的であり、技術選択においてより異端的でないことを望んでいました。そのため、Smalltalkを使用する代わりに、Javaには行きませんでしたが、相対的により主流的に見えるRubyに行きました。
同様に、独自のオブジェクトデータベースを書く代わりに、比較的より主流的に進み、MongoDBを使用しました。これは、オブジェクトデータストアの種類であることで、多くの柔軟性を提供してくれました。
それで良かったのです。私が言ったことすべてが、他の会社の技術選択を行うことを私から不適格にするかもしれませんが、Stripe 2について何か違うことをしますか？
Stripe V2 APIの設計と哲学
私たちはまだそれについて多くを公に話していません。その答えは、フランス革命についてのDeng Xiaopingの発言のようなものかもしれません。判断するには早すぎます。
2022年に、データモデルと抽象化についてのこの議論で、Stripeのコア抽象化のいくつかが、適切な長期抽象化ではないことに気づきました。それを修正する必要がありました。
そこで、多くのV2 APIを設計しました。幸いなことに、Stripeの早い段階でこの可能性を考慮していました。人々がStripeで慣れ親しんでいるREST URIのほとんどは、2010年からSLV1で始まっています。
2022年に、名前空間をインクリメントすることを決定しました。そこで、これらの新しいAPIを設計しました。それらは今年出荷を開始しました。
おめでとうございます。ありがとうございます。私たちは、それが可能にする機能について非常に興奮しています。その詳細に立ち入ることなく、これらは歴史的に、エンドカスタマー、サブアカウント、さまざまな種類の支払いの受取人などを区別し、別々に表現していましたが、それらを同じ種類のエンティティ表現に統合することを可能にします。
これは、ある程度明らかに正しい答えであり、すでに一部の顧客のビジネスを変えています。詳細を再入力することなく、または同じアカウントを異なる国間で持参することなく、ユーザーがさまざまなことを行うことができるようになったからです。
それは長い道のりでした。長い道のりだった理由は、これらのAPIを孤立して定義することは、それほど有用ではないからです。それらを孤立して定義したいだけなら、それはかなり簡単なことです。
困難なのは、それらをStripeの既存のすべてのものと相互運用可能にし、翻訳層を構築することです。そして、私たちは私たちのコードベースを制御していますが、彼らのコードベースは制御していないので、顧客と合理的なアップグレードパスがどのようなものかを理解することです。
誇張したくはありませんが、少なくともある程度は、チップアーキテクチャの命令セット移行のように感じます。命令セット自体は簡単ですが、すべての共存の問題が困難になります。
しかし、今年出荷は困難で、私たちはそれについて興奮しています。
その質問は、そこから学んだ教訓は何か、そして書き直しのプロジェクトやこれらの種類の数十年の長期抽象化について考えることについて、より大きなことを引き出すことはあるかということでした。
それに対する私の取るに足らない答えは、合理的に統合できるものはすべて統合することです。
V2の設計アイデアをどのようにテストしましたか？
設計している人々が、まず、別の教訓を与えて、それからその質問に答えます。もう一つの教訓は、少し安っぽいものでもあります。また、全体を理解し、他の誰よりも責任を持つ主要なAPIデザイナーがいて、それは一人の人です。何らかの作業グループではありません。
作業グループはありますが、全体を理解し、他の誰よりも責任を持つ一人の人がいます。それが必要だと思います。
私の他の取るに足らない勧告は、合理的にn対mの関係になり得るものをすべて、それをサポートするようにすることです。1対nやn対1などのみをサポートする場合、それがn対nになることがどのように可能なのかが明白でなくても、必然的にそれが必要になります。
2つの異なる会社に所有される会社は決してないだろうと思うかもしれませんが、実際には、空間内のすべての順列が最終的に探索されることが判明します。
それをどのように行うかについて、私は、これらの新しいAPIが適切なAPIであることを本当に感じています。どのようにそれらが適切なAPIであることを知るのかという質問をしました。
部分的には、初期バージョンを顧客に見せることから、部分的には、それらを設計した人々が、以前のバージョンの欠点を目撃し、それらと共に生活するのに多くの年を費やしたからです。
私たちは強い意見を持ってきましたが、強い意見でさえ、時々誤って予測したり、誤って推定したり、何かを過度に工学化したりすることがあります。そのため、顧客検証、顧客フィードバックのサイクルが非常に重要だと思います。
私たちが多く行ったのは、新しい世界に存在するであろう統合を文字通り書くことも非常に重要だと思います。本当に、Javaは、CやC++や前駆体に存在していたメモリ管理などの問題を修正する例かもしれませんが、多くの冗長性とオーバーヘッドを犠牲にしています。
私たちは、無意識のうちに物事を過度に工学化することから自分たちを守るために、さまざまなビジネスモデルとフローなどをどのように実装するかを具体的に記述する多くのAPIコードを書くことを自分たちに強制しました。それを見た時に、正しく感じられるかを確認するためです。
しかし、私はまだ私たちのアプローチを強く支持したくありません。非常に楽観的に感じていますが、私たちは60-70%完了しているところで、100%ではありません。そのため、勝利を早まって宣言したくありません。
PatrickのAI活用方法
Patrick Collisonは、AIをどのように使用していますか？
主な方法は、予測可能なものです。LLMチャットツールを多く使用しています。主に、興味を持っている事実的または実証的な質問に答えるために使用しています。
深い研究スタイルの質問については、いつもDeepSearchを使用するわけではありません。LLMがツールの使用とウェブの自己ナビゲーションで向上しているので、DeepSearchをそれほど必要としません。
しかし、実証的または事実的な質問に答えるためには、彼らが書くために有用であることを願っています。しかし、通常、彼らが生成する書き物に不満を感じます。そのため、あまり使用しません。
私自身の書き物を編集または採点するためにも使用しません。モデルが進歩するにつれて、書き物の改善を見たことがありますか？私も同感です。また、彼らは驚くほど一般的です。
一般的でないようにプロンプトしようとしています。人々の名前を挿入しても、うまくいきません。そのため、それを与えた時に失望しています。
基本モデルがこれでより良いと人々は言っています。それは、あなたが知っているような、何らかの引力盆地にそれを置くOAIHFの正規化だということです。
そこで効果的に使用することに成功していません。ClaudeがOpenAIの初期モデルよりも優れていて、o3がより良いと人々は言っており、相対的にそれは真実かもしれませんが、私は、自分が特に才能のある作家だと示唆しているわけではありません。そうだとは思いません。
私の個人的なスタイルが、いわばモデルの個人的なスタイルと異なるだけです。そして、自己中心的な方法で、書く時に自分の個人的なスタイルを使用したいのです。
事実的なものに多く使用し、そのために素晴らしいと思います。本を読んでいる時でさえ、最近はGrok の音声モードを使用しています。読んでいる間に受動的に質問をし、Grokはバックグラウンドで聞いていて、答えは非常に役立ちます。
そして、明らかに、通常はCursor を介して、コードを書くためにLLMを使用します。
ソフトウェア産業人としての視点
私たちは、ソフトウェア産業人の典型として、あなたPatrick Collisonにインタビューしています。多くの理由で、あなたは中央キャスティングから直接出てきたような感じです。
一つは、大規模なソフトウェア会社、成功した大規模なソフトウェア会社を運営していることです。二つ目は、プログラマーとして始まり、その後会社の運営に移ったことです。三つ目は、会社が開発者向けのものも構築しており、ベン図の多くの円の交差点のようなものだからです。
Stripeでの経験について議論することは役立ちます。私たちは、副業の経済学者であり世界の学生であるPatrick Collisonにもインタビューしています。
AIがある今、進歩研究は運命づけられていますか？そのための必要性はありますか？
私は、進歩研究の必要性が高まっていると言おうとしていましたが、固有名詞の進歩研究が必要性の増加を見ているとは言いません。
しかし、進歩研究が答えようとしている種類の質問が、今、より緊急で切迫していると思います。なぜなら、自由度が増加していると思うからです。
AIがすべての問題を魔法のように解決するというパンダシア的な見解があると思いますが、将来の予測は困難ですが、一つはそれは真実ではないと思いますし、二つ目は、これまでの証拠が示す限り、それは実績ではなかったと思います。
これらのものをどのように使用するか、どのような決定を行うか、どのような考慮事項と人間の福祉のマージンを進めようとするかという判断は、本当に重要だと思います。
おそらく、5年前に進歩研究や進歩研究スタイルの思考に対してレベルを上げることができた批判は、これらはすべて良い質問だが、世界は何らかの目的論的結果への運命づけられたエスカレーターパス上にあるということです。
今日、世界はそのようには感じませんし、今日よりもそのようには感じません。
世界情勢とテクノロジーの複雑性
それは世界情勢やその他のことですか？
いいえ、世界情勢全体のトリプルフェクタかもしれません。第二に、理想と志向がより積極的に争われており、今日の米国では、左派と右派が何を代表しているかさえ曖昧になっています。
私たちは現在、一つの政党が関税を支持し、別の政党がそれに反対していますが、価値観は歴史的に期待されたものから変化しています。
そして第三に、明らかに技術、そして何よりもAIですが、私たちの業界では、安定コイン、ドローン、ロボット、バッテリー、ソーラーなどの未来技術における卓越した製造力としての中国の台頭があります。
多くの異なる方法で、未来は、Peter Schwartzが概念化したSchwartz window、つまり何年か後の考えられる未来の窓があります。2005年に2015年の世界を考えた時のSchwartz windowはかなり狭く、正しく狭かったと感じます。
2015年の世界は、実際に2005年に期待していた通りに展開されました。今日2025年に2035年のその窓を考えると、非常に広いと感じます。
そのため、進歩研究スタイルの質問がより緊急であると思います。
生産性数値とAIの影響
あなたは、情報技術が増加し、科学技術により多くの人々が取り組み、より多くの資金が投入されているにもかかわらず、生産性数値の改善が見られない理由について、人々がより多く焦点を当てるべきだと記録に残して言っていました。
数値は今どのように見えますか？数値にAIが見えますか？
ほんの数日前に、この非常に関連する新しい論文が発表されました。今日読むためにキューに入れたばかりで、この瞬間では要約のみを読んでいます。
その主張は、言語モデルの使用から生じる生産性の改善は、実際には観察されないということです。確かに、彼らが見ているものについて言うことはできません。LLM使用の強度に基づいて、個人レベルで何らかの自然実験を行っているようです。
しかし、彼らの方法論的厳密さを支持することはできません。それをよりよく理解すると、本当に感銘を受けて非常に信頼できると思うか、恐ろしいと思うかもしれません。
しかし、今日偶然見つけたのは、その発見でした。全体的に、米国のGDP成長は、過去2年間で、私たちが期待していたよりもやや良く見えます。
明らかに、私たちは今、不安定な時期に話しています。確実に、指数関数的な離陸の証拠は見えません。過去2年間に見た励みになるGDP数値が、これらの新しい技術に帰属できると思う限り、これらの技術が準公共財であるため、他の国でも見られることを期待するでしょう。
誰でもこれらのLLMを使用できます。米国外のGDP成長はそれほど励みになるものではありません。私たちは、世界全体で大規模に加速された経済成長期間に生活しているわけではありません。
明らかに、まだ初期段階です。しかし、これらの技術の経済全体への拡散には本当に時間がかかり、実質的な複雑性が含まれていると思います。
最後の点は、AnthropicのJack Clarkが共同創設者の一人で、Tyler Cohenとのインタビューで言ったと思います。Anthropicは、ある程度、AGIやASIの概念を非常に真剣に受け止めており、Darioがそれについて公に話し、書いています。
再び、共同創設者の一人であるJack Clarkは、AIがGDP成長を年0.5%増加させると期待すると言いました。私はJackを本当に楽観主義者だと解釈しており、年0.5%は実際には複合すると多くの増分GDPです。
それが小さいと言っているわけではありませんが、それが彼の数値だったのは興味深いと思います。
経済生産性の測定と人間生物学のプログラミング
AIが経済で今取っている形式で、単純にラインを前方に伸ばすと、現在持っているものよりも新しい経済生産性の測定が必要になると思いますか？実際の生産性が上がると仮定します。AIが改善し続けると仮定します。あなたが期待する方法で展開されます。
新しい測定が必要だと思いますか、それとも数値に表示されるべきだと思いますか？
いいえ、そうは思いません。GDPが完璧だと言っているわけではありません。GDPは改善できると思いますが、経済として一般的に考えるものが大規模に強化される世界では、それはGDPに表示されるでしょう。
人間生物学をプログラミングできるようになるのはいつですか？
これについて非常に興奮しています。私が設立に関わった生物医学研究組織であるARCで、DNAなどを使用した生物学の基盤モデルのトレーニングに取り組んでいます。仮想細胞に取り組んでいます。
一般的に、生物学により多くの時間を費やすまで理解していなかったことですが、人類は複雑な病気を治したことがありません。
病気の一つのオントロジーまたはスキーマは、インフルエンザ、風邪、COVID-19などの感染症があり、結核や死亡率の高い病気があります。
そして、ハンチントン病のような単一遺伝子疾患があります。そして、複雑な病気があります。複雑な病気は、私たちが西洋世界で少なくとも問題のある感染症のほとんどを治した後の残留物です。
ほとんどの心血管疾患、ほとんどの癌、ほとんどの自己免疫疾患、ほとんどの神経変性疾患など。これらの状態の特定のものについて、心血管疾患のスタチンのような、助けになる治療法があるかもしれません。
しかし、それらのどれについても、私たちがそれを治し、因果経路を意味のある詳細で理解し、それに対して予防接種できるなどと本当に言えるものはありません。
これは、部分的には、実験的で、認識論的という言葉は大げさかもしれませんが、認識論的技術がその任務に適していないからだと思います。遺伝子が体のすべての異なる部分とシステムと細胞内のメカニズムに与える影響の多面性は、そこに組み合わせ複雑性があり、環境はそのような広大で定量化が困難なものです。
これらの状態のいずれについても、イデオロギーとダイナミクスなどを理解することは本当に困難です。
過去10年間、もう少し長いですが、開発の多くは過去10年間に起こりました。生物学で3つの新しいクラスの技術を得ました。
読むために、はるかに良いシーケンシング技術、単一細胞シーケンシング、RNAの単一細胞シーケンシング能力、そして思考レベルでのこれらの改善を得ました。
ニューラルネットワークとディープラーニングとトランスフォーマーと、そこにあるすべてのものを得ました。それらは長い間存在していましたが、それらの最近の改善、特にトランスフォーマーを得ました。
そして、書く側では、機能的ゲノミクスとCRISPRとブリッジ編集の明らかな大きな改善を見ました。これはARCの技術の一種ですが、細胞に非常に特定の指向性摂動を行う能力です。
これらをまとめると、個々の細胞のレベルで、読み、考え、書く能力があります。これは、新しい種類のチューリングループを持ち、独自の種類の完全性を持つように本当に感じ始めます。
この体系的なアプローチが、これらの複雑な疾患に対して、どれだけのことができるか、そしてそれらのダイナミクスに新しい光を当てることができるかはわかりません。
しかし、希望を持ち、興奮しています。
プログラミングの自動化と予期せぬ受益者
もしケーサーでの私たちや業界の他の人々が、今日知っているような多くのプログラミングの自動化に成功し、はるかに高レベルで生産的で、ソフトウェアがどのように見えるかを定義することにより多く焦点を当てたソフトウェア構築の形式でそれを置き換えることに成功したら、あなたは誰に長期的に投資しますか？
人々はデザイナーについて話し、これが彼らのルネサンスになると言いますが、コンピューターで物事を起こすことにはそれほど熟練していないかもしれませんが、本当に素晴らしい本当に驚くべき多くの大学院生がいます。
しかし、より多くの人々がコンピューターで物事を作ることができ、既にコンピューターで物事を作っている人々がはるかに生産的になる世界、特にプログラミングから離れた進化である場合の、最も予期しない受益者は誰だと思いますか？
それに対する高い信頼性の答えは持っていません。制約された実物資産、特に制約された実物資産のような、取るに足らない株式答えが全てあります。
SF不動産などに長期的に投資すべきかもしれません。世界で最も美しい都市の一つであり、永続的にそうであるからです。
これらのシステムへの入力と成分に長期的に投資すべきかもしれません。それらへの需要が放物線的になるからです。そのため、銅に長期的に投資すべきかもしれません。
地位財と有名人、Taylor Swiftの音楽カタログに長期的に投資すべきかもしれません。ここには多くの魅力的な理論があると思います。
しかし、この経済的瞬間で興味深いと思うことの一部は、技術軌道自体の予測不可能性と偶然性と、正確な仮定への敏感性です。
それが5年または10年後に取る形状は、その答えを大きく決定することになると思います。過去2年間を振り返ると、かなり多くの予測が合理的に貧弱に持ちこたえていることに驚きます。
一見して、非常によく情報を得た人々からでさえです。そのため、多くの人にこの質問をしましたが、確信を持てるほど魅力的な答えは聞いていません。
私たちは、Stripeとあなたたちの使命に奉仕できることを非常に嬉しく思っています。私たちに何を構築してほしいですか？あなたPatrick Collisonにとって、またはStripeにとって、Cursorをどのように改善できますか？
あなたたちはすでにStripeをより良くしてくれています。そのため、あなたたちがやっていることを続けることは、私たちの観点から悪い結果ではありません。
Cursorには現在、何百人、そして間もなく何千人もの非常に熱心なStripe社員がいて、彼らはCursorの日々のユーザーであり、非常に重要な生産性向上だと報告しています。
経済数値を待っていますが、経済はかなり大きく、これらの拡散には時間がかかります。StripeがR&Dとソフトウェア作成に費やす金額は、単一の事業に費やす金額よりも多いです。
そのプロセスをより効率的で生産的にしてくれるなら、もっと何かを望むのは貪欲に見えるかもしれません。
利己的になるなら、3つのことがあります。先ほど議論したランタイム特性と統合のものは、本当に価値があると思います。
またお話しした再構築と美化のものも、非常に役立つと思います。それは、Stripeへの将来の変更のコストを下げることができれば、アーキテクチャの品質を向上させることができれば、本当に私たちの自由度を変えると思います。
第三に、私たちはStripeでクラフトと美しさと呼ぶものを本当に大切にしており、私たちのソフトウェアが良く設計され、使いやすくあることを望んでいます。表面的なピクセルの意味でだけでなく、深い意味で非常によく機能し、セットアップして、基本的に忘れて、ただ信頼できるものです。
忘れたい程度に忘れることができるものです。AIがより多くのスロップとよりクラッピーなものの作成につながるが、最高のものはより多くないという懸念があります。
Cursorが、世界がより多くのソフトウェアだけでなく、より多くの最高のソフトウェアを作成することを確実にするために何をするかはわかりません。
しかし、それは興味深く重要な次元だと思います。これらが、すべての明白なこと以外での私の3つの提案です。
素晴らしいです。ありがとう、Patrick。
ありがとうございます。お招きいただき、ありがとうございました。
コメント