HashiCorpの共同創業者ミッチェル・ハシモトが、現代のクラウドインフラを支えるツール群の誕生秘話を語る。大学の研究プロジェクトの失敗から始まり、ノートに書き留めた未解決の課題リスト、そして2分で返信したメールが運命を変えた。AWS、Azure、Google Cloudとのパートナーシップにおける率直な見解、AIコーディングツールへの適応、そしてエージェントを常時稼働させる理由まで、業界で最も実践的なビルダーの一人が、AIツールが有用な場面とそうでない場面について語る。
創業前夜:AWSとの出会い
当時のAWSでの経験について、率直な意見を聞かせてください。
AWSは本当に傲慢でしたね。まるで私たちに恩を着せているような感じがしました。いつでも自分たちで製品を立ち上げて、あなたの会社を潰せるぞ、という微妙な雰囲気が漂っていました。
Terraformはあっという間にどこにでもあるような存在になりました。あの突然の人気はなぜだと思いますか?
私がイライラしたことの一つは、ああ、彼らは市場に最初に参入したから勝っただけだ、という意見でした。実は私たちは市場参入が7番目だったんです。
AIのせいで、オープンソースのほとんどが変わらざるを得ないように感じます。AIは、もっともらしく見えるけれど不正確で低品質な貢献を作るのを簡単にしてしまいます。オープンソースは常に信頼のシステムでした。今ではデフォルトで拒否して、信頼を得なければならないようになっています。
数年後もGitは存在していると思いますか?
興味深いのは、12年から15年ぶりに、誰かが笑わずにその質問をしているということです。
ポッドキャストの導入
もしAIエージェントがコードを書き、プルリクエストを開き、機能をリリースできるなら、もうオープンソースの貢献者は必要ないのでしょうか? HashiCorpの共同創業者であるミッチェル・ハシモトは、このことについて、そしてオープンソースの未来と、AIを日々のワークフローに効率的に統合する方法について深く考えてきました。
ミッチェルは、現代のクラウドインフラストラクチャを支えるツール、TerraformとHashiスタックを構築しました。彼はまた、人気のターミナルGhostyを作成し、私は彼をAIがソフトウェアエンジニアリングの技術をどのように変えているかについて、業界で最も思慮深い声の一人だと考えています。
今日のエピソードでは、HashiCorpの原点の物語、失敗した大学の研究プロジェクト、未解決の問題のノート、そして彼が2分で答えた未来の共同創業者からのメールを取り上げます。
AWS、Azure、Google Cloudとパートナーとして働いた際の、率直でフィルターのかかっていない見解。傲慢さと、ビジネスについて考えたこともない優秀なエンジニアたちの両方について。彼がどのようにAIコーディングツールに適応したか、なぜ常にバックグラウンドでエージェントを稼働させているのか、そしてまだAIエージェントに慣れていないエンジニアへの実践的なアドバイス、などなど。
業界で最も実践的なビルダーの一人から話を聞きたい、そしてAIツールがどこで有用でどこで有用でないかを知りたいなら、このエピソードはあなたのためのものです。
このエピソードは、フラグ、分析、実験などの統合プラットフォームであるStatsigによって提供されています。彼らとシーズンスポンサーであるSonarとWorkOSについて詳しく知るには、ショーノートをチェックしてください。
プログラミングとの出会い
ミッチェル、ポッドキャストへようこそ。実際にお会いできて嬉しいです。
ええ、何年もあなたをフォローしてきた後に直接お会いできてクールですね。あなたはテクノロジー業界やソフトウェアエンジニアに多大な影響を与えてきましたが、どのように始まったのですか?
大枠は多くの人と同じストーリーだと思います。12、13歳くらいの10代前半に独学で学び、ビデオゲームに動機づけられました。多くの人と同じですね。ただ、私はすぐにウェブが好きだと気づきました。ウェブは新しかったんです。Googleはまだ存在していませんでした。ウェブが新しかったんです。だから私はすぐにビデオゲームプログラマーにはならず、すぐにウェブプログラマーになりました。PHP、Perlなどです。
そして、とても若かったので、学ぶ唯一の方法はオンラインで公開されているコードを通じてでした。だから、それがオープンソースとの出会いでした。当時はそれが何と呼ばれているか知りませんでしたが、仕事もお金もない子供でした。
両親は本を買いたがりませんでした。専門書は、今いくらかわかりませんが、当時は50ドルくらいでしたよね? だから彼らは「絶対だめ」という感じでした。それに、私が本当に読むとも信じていませんでした。だから買ってくれることはありませんでした。だから、オンラインで見つけたものが何でも、私のコーディングへの入り口でした。
毎日、友達のグループと一緒に学校まで歩いていました。ある期間、PHPマニュアルの最初か2番目の章を印刷していました。約30から40ページの紙だったと覚えています。プログラミングをしたことがなかったので、全部のことが12歳の私にはとても混乱していました。学校まで歩く度に、その40ページ全部を読みました。
どのくらい時間がかかったか覚えていませんが、長い間それをやりました。ある時、学校まで歩いている時に、突然これらのドル記号が何なのか理解した瞬間がありました。何らかの理由でそれがピンと来たんです。
それは変数ですよね?
変数です。ええ。そして私は本当に理解しました。それまでその言葉を聞いたことがありませんでした。12歳でどんな文脈でも変数という言葉は聞きませんよね。そしてついにある時点で、それらが物を保存し、物が変化できるということが私に響きました。何週間もこれを読んで理解できなかったのに、学校に着いてとても興奮したのを覚えています。それが私の中でトリガーされたんです。その後、物事が本当に早く起こったのを覚えています。
どんなものを作りましたか?
ウェブサイトです。ええ、ウェブサイトでした。ゲーム関連のウェブサイトでした。たくさんの掲示板ソフトウェアのようなものでした。ええ、ウェブサイトをクローンするのがとても楽しかったです。下手にですけど。PayPalが出ていて、インターネット上でお金がどうやって送金されるのか本当に不思議でした。どうやって動くんだろう? だからPayPalのコピーのようなものを作ろうとしました。
フリーランスのウェブサイトで18歳のふりをしていました。だから、画像アップロードなどで、ここで100ドル、ここで50ドルみたいな仕事を得ました。大学でコンピュータサイエンスを学ぶことにしました。ワシントン大学に行きました。それを真剣と呼ぶんでしょうけど、高校を通じて毎日できる限りコーディングしていました。
ああ、そうなんですか。
ええ、それは印象的ですね。これを一人でやっていたんですか? 友達グループに他にやっている人はいましたか? それとも孤独な感じでしたか?
孤独でした。とても孤独でした。現実世界では孤独でしたが、MSN MessengerやAIM Messengerやフォーラムを通じてすぐにオンラインの友達を見つけました。オンラインの友達を見つけました。その多くには今会っていて、まだ連絡を取り合っているのがクールです。でもいいえ、当時はプログラマーであることは、誰もその言葉を知らなかった時代でしたが、コンピューターに興味があるというのは社会的な死のキスでした。だから親友でさえ、親友たちからもそれを隠していて、学校では話しませんでした。だから大学に行くまで秘密でした。大学で全てを出すことにしました。
大きなブレイクスルーは、ブログを書いていたことでした。1年生の終わり頃、夏に向かう時期に、誰かが突然メールをくれました。ちょっと詐欺かと思いました。Ruby on Railsプログラマーになりたいか? というような内容でした。私はRubyを知りませんでした。PHPプログラマーでした。
Rubyをやったことがありませんでした。Railsもやったことがありませんでした。でもこのメールをもらって、ヘッドハントされたこともありませんでした。これが何なのかわかりませんでした。18歳でしたし。だからそれについてどう思うべきか本当にわかりませんでした。おそらく返信しなかったでしょう。でも連絡してきた人がLAにいたので、返信して会議を設定しました。実際の対面会議です。彼と会社に会って、これが本物で真剣で誠実だと気づいて、その仕事を受けました。そこで仕事で多くのことを学びました。だからそれは大きな変化でした。
それはスタートアップか小さな会社のようなものでしたか?
いいえ、コンサルティング会社でした。2007年のRuby on Railsのような標準的なものの一つでした。Ruby on Railsは爆発的に人気になっていました。既にとても人気がありました。そして、どこからともなく現れたこれらのコンサルティング会社が全てありました。基本的には、私たちがあなたの最小限の実行可能な製品を構築しますよ、という感じでした。そういうショップの一つでした。
大学生にとっては素晴らしい仕事でした。約2ヶ月ごとにクライアントが変わり、YouTubeスタイルのウェブサイトを構築したり、慈善活動のウェブサイトを構築したり、eコマースのウェブサイトを構築したりしました。様々なテクノロジーと様々なスケールの課題と様々な、スケールの問題について考えることを学べました。MVPを構築していたので多くのスケールはありませんでしたが、スケールの問題について考える機会がありました。素晴らしかったですね。
HashiCorpの始まり
最終的にHashiCorpはどのように始まったのですか? このRubyの仕事を得てから数年後までの間に何が起こったのですか?
このRubyの仕事から始まります。その会社で働いていた一人の男性がいて、彼はプライバシーにかなりこだわっているので名前は明かしませんが、彼は私の上司でした。HerokuもEngineYardもなかったので、自分でホスティングする必要がありました。当時、Ruby on Railsのホスティングは少し難しかったです。だから彼は、これらのプロジェクト全てを専用サーバーにホストさせた人でした。私はそれについて何も知りませんでした。彼はLinuxを使っていて、長い黒髪をしていて、マウスを使わず、私にとってとても奇妙なことをしていました。興味をそそられました。彼は隅に座っていました。誰とも話したがりませんでした。
私はその世界についてもっと知りたかったんです。幸いなことに、外見に反して彼はとても親切でした。だから、本当の興味を示すとすぐに、たくさん質問を始めると、彼は私にチャレンジを与え始めました。最初に覚えているチャレンジは、彼が私のマウスを抜いたことです。
今の時代にそれをやったら、何らかのハラスメントになるかもしれない時代があると思います。でも彼は文字通り、マウスを抜いて、「もう二度とマウスで作業しないから。だから何とかしろ」と言いました。方法は教えないと。マウスを抜いて、コンピューターを再起動して、「あなたの問題だ」と言って、マウスを持って行ってしまいました。
約1週間かかりましたが、キーボードが本当に上手くなりました。
厳しいレッスンですね。
厳しいレッスンでした。キーボードが上手くなると、彼は私のターミナルにscreenをインストールしました。初期のチーム。彼は私のターミナルにscreenをインストールして、「これを理解しろ。これから使うことになる」と言いました。質問はなし。これを使うことになる、と。彼はゆっくりと私にそれを教え込んでいきました。そこに到達すると、次はSSH、これがパッケージマネージャーだ、と徐々に教えてくれました。それで私はインフラストラクチャにのめり込んだんです。すぐに大好きになりました。超クールで超楽しかったです。
それと同時に、またはその直後に、ワシントン大学のSeattleプロジェクトという研究プロジェクトに参加しました。これはひどい名前です。Googleで検索できないので。でもSeattleプロジェクトと呼ばれていました。もう存在しないと確信していますが。これもこの時代に人気があったもので、folding@homeのようなものでした。folding@homeを理想化したもので、たくさんの人の計算資源、自宅のマシンでも、地下室の使っていないラックでも、世界中どこでもいいのですが、この異種混合のハードウェアを寄付して、その上に一般化されたスケジューラーを作れるか、という考えでした。そうすれば世界中の学術機関が、研究だけでなくワークロードを実行できるようになります。
私が得た仕事は、非常に曖昧でしたが、スケジューラーコンポーネントではなく、これらのノード全てを立ち上げる能力を作ることでした。そして他にもたくさんありました。非常に曖昧でしたが、インフラストラクチャの問題でした。そして私は完全に失敗しました。
1学期でやろうとしましたが、技術的な面から失敗しました。そしてノートに書き留めました。10週間の期間でこの問題を解決できなかった理由、つまりこれが必要だ、これが必要だ、これが必要だという欠けている部分だと思ったことを。
ミッチェルがHashiスタックの一部となるコンポーネントを定義する際のアプローチがいかに構造的だったかが興味深く、これは私たちのシーズンスポンサーであるWorkOSにうまくつながります。偉大なエンジニア、ミッチェルを含めて、彼らから学んだことの一つは、彼らが何を構築するかを選ぶ際に非常に慎重だということです。
偉大なエンジニアは速く出荷するだけではありません。彼らはシステムで考えます。レバレッジを理解し、何が長期的なサービスエリアの一部になるかについて注意深いのです。
SaaSを構築している場合、特にAI製品の場合、認証とエンタープライズアイデンティティは静かに長期的な投資になり得ます。SAMLのエッジケース、ディレクトリ同期、監査ログ、そしてエンタープライズ顧客が期待する全てのこと。WorkOSはこれらのビルディングブロックをインフラストラクチャとして提供するので、チームは実際に製品を差別化することに集中できます。
偉大なエンジニアは何を構築すべきでないかを知っています。アイデンティティがあなたにとってそのうちの一つなら、workos.comを訪れてください。
これで、ミッチェルがHashiCorpで構築することになる全てのコンポーネントが書かれたノートに戻りましょう。
今でも家にこのノートがあります。問題は本当に、そこにある様々なリソースを宣言的に管理する方法がない、プライベートネットワークでこれらをネットワーク化する方法がない、などです。
そこにはたくさんのものがありましたが、結局構築しなかったものもありました。でもその一部が最終的にHashiCorpが構築することになったものでした。これを学部の上司、後に共同創業者となるArmonと共有しました。
後に共同創業者となった人ですね。
はい。彼は学部側での私の上司でした。これが何かということを、退職面接のような形で彼と共有しました。それから数週間が経ち、彼が突然メールをくれました。「一緒にスタートアップをやらないか?」と。
10代で、このコミットメントが何なのか全くわからないわけです。
でも、この時点で21歳くらいですよね。
ああ、おそらくそうでもないです。おそらく19か20歳でした。そして彼が突然メールをくれました。「スタートアップをやりたいか?」と。会ったこともない、ほとんど会ったこともない人から、個人的に会ったこともない、そういう全てです。とても面白いですよね。彼が11時30分にメールをくれました。
大学にいますよね。2分で返信して「もちろん」と言いました。彼は、こんなに早く考えたんだ、彼は本当にやる気だ、準備ができている、と思ったのを覚えています。それが私たちの友情の始まりでした。
それと同時に、重複する部分がありますが、私はVagrantというものにも取り組んでいました。Vagrantは研究プロジェクトというよりも、このコンサルティング会社から生まれました。2ヶ月ごとに新しいクライアントがいて、異なるチームがいるというコンサルティング会社の問題を解決していました。どうすれば再現可能な開発環境を作成して、請求可能時間をあまり使わずに誰かを助けに行けるか?
これは素早く立ち上げられる開発環境ですよね?
ええ。ええ。ええ。私がいつも使っていた比喩は、当時Windowsは使っていませんでしたが、いつも使っていた比喩は、どうすればダブルクリックして開発環境を開けるか? でした。
それはいい比喩ですね。
ええ。私たちが抱えていた問題は何だったか?
コンサルティング会社では、請求できない時間の無駄は本当に無駄なんです。だから基本的には、もし他の誰かがスケジュールに遅れているなら、どうすれば飛び込んで、機能を実装して、抜け出せるか? その時代、プロジェクトの開発環境を設定するだけで半日かかるかもしれませんでした。
そしてクライアントにそれを請求できないですよね? クライアントは作業にしか支払わない。
ええ。クライアントにそれを請求できませんでした。だから4時間の作業が無駄になり、おそらく実際のクライアント用の開発環境も台無しになります。Rubyのバージョンが違う、Railsのバージョンが違うので、両方を壊してしまうことになります。
だからVagrantがそこから生まれました。あちらに行く必要があっただけで、最終的にvagrant upになったものが、数分で、2時間手伝いましょう、という感じでした。
どうやって構築したんですか? 当時は何らかの仮想マシンか何かでしたか?
ええ、VirtualBoxでした。OracleのVirtでした。いえ、当時はSunでしたが、VirtualBoxでした。それともう一つのクールな制約は、私が大学生だったのでお金がなかったということです。
当時は高かったですよね?
仮想化は高かったです。VirtualBoxは無料でオープンソースでした。オープンソースの側面は気にしませんでした。読むつもりはありませんでしたから。でもええ、無料でした。だからそれを使いました。だからEC2を使わなかったんです。EC2は既に出ていましたが、これらのインスタンスにお金を払うお金がありませんでした。だから、ええ、それが制約でした。これを持ち出すのが好きなのは、ソフトウェアエンジニアリングの多くは制約を理解し、これらの制約と共に働くことだと思うからです。
以前のポッドキャストでは、静的な力と動的な力と呼ばれていました。それです。それがより良いソフトウェアを作るのに役立つと思います。制約があると。それが私の制約でした。
だからVagrantがあり、失敗したインフラストラクチャプロジェクトがありました。コンサルティング会社の上司が私をインフラストラクチャに導いてくれました。そして外部的には、クラウドが導入されました。AWS。私はワシントン大学に通っていました。
ああ。
まさにその震源地にいました。
Amazonが隣でしたよね。
Amazonがすぐ隣でした。すぐにたくさんのクレジットを寄付してくれました。ローンチについて知っていました。UWのCS学生のほとんどがAmazonでインターンをしていました。必ずしもAWSではありませんでしたが、AWSを含む至る所で。だから私はクラウド、クラウド、クラウド、AWSのバブルの中にいました。人々がS3をS cubedのように発音していた頃です。まだどう発音するか知らなかったんです。それくらい新しかったんです。だからええ、全てのことが一緒になって、それを管理するためのツールを構築する道に私を導きました。
その時点で、クラウドを見たとき、それが大きくなる、あるいはクラウドが今日のように大きくなるという確信はありましたか? というのも、これは当時非常に新しかったですよね?
完全にそうです。
シリコンバレーでのみ、あるいはそのような場所でのみ起こっていたことだと思いますが、この大規模なシフトを強調する必要があると思います。
おそらくそうです。
他のどこよりも大規模に、シリコンバレーでおそらく起こっていました。冗談でよく言われていたのは、AWSがとても信頼性が低いので、AWSがダウンすると、これらのスタートアップがようやくキャッシュフローがニュートラルに近くなって、損失が減るということでした。だから大規模なUS eastの停止があると、みんな「リージョンを移行するの?」と聞いて、「いや、今お金を節約してるんだ」という感じでした。
でも話を戻すと、全員がクラウドファースト、クラウドボーン、クラウドネイティブ、何と呼んでもいいですが、そういう状態でした。そしてもう一つは、彼らが私たちが直面しているのと全く同じ課題に直面していたということです。彼らは私たちのツールを使っていませんでした。単に内部プロトタイプツールだったからです。
でも私は、私たちのツールが良い感じだと知っていました。だから、正しいものを構築しているとかなり確信している、という自我、傲慢さと、業界がその方向に向かっていると思う、という二つのことが一緒になりました。それが、その辺りで会社を始めようということにつながりました。
Vagrantを持っていたという事実は、業界での尊敬のようなものでした。Vagrantは当時それほど大きくなかったので、それほど大したことではありませんが。でも公的にこの方向に向かうための信頼性を与える基盤があっただけです。それだけでした。そして私たちはHashiCorpを始めました。
会社を設立することを決めたとき、資金を調達することにしましたか? 当時はまだ一般的な常識ではなかったと思います。Y Combinatorがおそらくその頃始まっていたくらいですよね。だからスタートアップは大きなことでしたか? それともスタートアップを始めたら資金調達するのが当然でしたか?
私の社会的なバブルでは、かなり当然でした。それだけでなく、私は設立しました。自己資金でした。貯金から2万ドルをこの法人口座に移しました。初期資金です。
それで働きました。最初の6ヶ月間、自分には0ドル払いました。だから2万ドルは純粋に会社が必要とするものに向けられました。それが最初の6ヶ月でした。それから6ヶ月後にArmonが参加しました。そして資金調達することにしました。その動機は本当に、他にあまり選択肢がなかったからです。
基本的には当時私が見ていた3つの選択肢がありました。ブートストラップです。何かを構築してお金を稼いで、余裕ができたら成長を続けて再投資して成長する。ブートストラップ。反対側にVC。そして中間には、私がパトロネージと呼んでいたものがありました。今日のPatreonスタイルのものではありません。当時はそういうインフラがありませんでした。サブスクライバー寄付型のインフラはありませんでした。パトロネージはもっと、VMwareのような会社に、あるアイデアに取り組むために給料を払ってもらうよう説得できるかもしれない、というものでした。最良の例はVMwareのRedisです。
会社の設立時に含まれていた計画を私たちは作りました。それにはVaultを除く全てが含まれていました。Terraform、Consulは含まれていました。Vaultは少し後に来ました。そしてそれを見て、もしこれをブートストラップしたら、たとえうまくいっても、ソフトウェアを構築するだけで10年くらいかかると言いました。
ベストケースシナリオでも、これは遅くなるだけです。遅いことの問題は、物事には窓があるということです。クラウドが非常に速く成長していたので、もし私たちがそんなに遅かったら、誰か他の人が自分のやり方でそれをやってしまうでしょう。
つまり、主な問題は、本当に速く進みたかったということです。
速く進む必要があると知っていました。
ええ。必要でした。すぐに多くのエンジニアを雇って、すぐに構築を始める必要がありました。だからVCが私たちが選んだルートでした。
Hashiスタックの製品群
最初のいくつかの製品と、それらが何をするかについて話してもらえますか? Vagrantは知っていますが、後にHashiスタックになったものについてあまり知らない人のために。
ええ。これらを順番に並べられるか見てみましょう。まだできると思います。Vagrantはそれ以前でした。HashiCorp自体から出てきた最初の製品はPackerという製品でした。公的にはやや過小評価されていますが、今日でも業界の多くのものを支えています。これはイメージ構築ツールです。Amazonイメージ、VMwareイメージなどを構築します。
公的にどれだけ出てきたかわかりませんが、数十億ドル規模のクラウドプラットフォーム全体があり、彼らの公式イメージは全てPackerで構築されています。
みんながAWSのこの水平スケーリング、オートスケーリングの性質を活用しようとしていました。それが夢でした。そして、今日のサーバーレスのコールドスタート問題のようなものですが、サーバーが準備できるまで数十分待っていたら、反応できませんでした。
だから私のアイデアは、それをやって、イメージをスナップショットして、次回はそのイメージを立ち上げるだけ、というものでした。
それがPackerでした。
それがPackerでした。Vagrant、Packer。次に出てきたのはConsulでした。Consulはネットワーキングの問題を解決していました。ネットワーキングではなく、サービスディスカバリーの問題を解決していました。これらのマシンが出入りしている状態です。
これも概念化するために、以前はIPを持つ静的なマシンのセットがあり、おそらくDNSか何かを使っていましたが、IPはそれほど変わりませんでした。だから、ああ、私のデータベースはここにあって、動かない、という感じでした。
でもウェブサーバーとロードバランサーとデータベースが呼吸しているような世界にいるなら、つまり常に作成と破壊、作成と破壊を繰り返しているような状態なら、サービスディスカバリーははるかに速くなる必要があるスケールで物事が起こっています。
速いだけでなく、ああ、このIPアドレスにある、という応答を得たときに、そのIPアドレスが準備できているという保証をより良く持ちたいのです。
これもKubernetesのreadinessチェックやヘルスチェックなどでより主流になっていると思います。それを物理サーバーやクラウドサーバー、仮想マシンなどにもたらしていました。それがConsulでした。その後、Terraformをやったと思います。Terraformはインフラストラクチャコードを立ち上げます。
AWSのパーラメントでインフラストラクチャを記述します。EBSボリュームへの全てのアタッチメント、ゲートウェイ、VPC、サブネット、それらを全て接続するようなものでした。アイデアは、空のAWSアカウントまたは任意のクラウドアカウントを持ちたい、このテキストを持ちたい、このテキストを現実にしてくださいと言いたい、それがTerraformです。AWSがかかる時間だけ待って、まばたきすれば数千のリソースができて、それから1つのコマンドでゼロに戻すこともできました。
それがTerraformでした。2014年頃に出ました。それが次でした。その後がVaultでした。
Vaultは、核となるシークレット管理として説明するのが最も簡単です。シークレット管理と暗号化で、それ以上のことをするようになりました。
ローカルの開発者マシンに環境変数があるような、それをチームレベル、会社レベルでスケールさせて、サービスがこれら全てに安全にアクセスする必要があるようなものですね。
ええ、本番環境のシークレットにもっと焦点を当てていました。開発者のシークレット問題を本当に解決するという夢とビジョンがありましたが、Vaultは実際にはそれをうまくやりませんでした。
ミッチェルは今、シークレット管理について話しました。これは彼にとってかなり重要な焦点分野となりました。一般的に、セキュリティは非常に価値がありますが、うまくやるのもかなり難しいです。これは私たちのシーズンスポンサー、Sonarにうまくつながります。
今日の私たちの状況を見ると、タブ補完を超えて、Agentic AIの時代に移行しました。自律エージェントがプルリクエストを開いています。一つの大きな質問。リスクの山を継承することなく、AIのスピードをどう得るか?
SonarCubeのメーカーであるSonarは、これをフレーム化する本当に明確な方法を持っています。バイブしてから検証する。バイブの部分はイノベーションについてです。チームとAIエージェントに高速で構築し、反復する自由を与えることです。検証の部分は不可欠な自動ガードレールです。
エージェントがコードベースのより多くを貢献し始めるにつれて、人間が生成したものであれ、マシンが生成したものであれ、品質とセキュリティ基準に対して全ての行をチェックする独立した検証は、これまで以上に重要になっています。
品質、セキュリティ、保守性を確保しながら、開発者と組織のリーダーがAIから最大限を引き出すのを助けることは、来るべきSonar Summitの主要なテーマの一つです。
これは単なるユーザーカンファレンスではありません。開発者、プラットフォームエンジニア、エンジニアリングリーダーが集まり、この新しい時代の実践的な戦略を共有する場所です。私もそこでスピーチすることを嬉しく思います。コード品質を犠牲にせずにAIを採用する方法を考えているなら、Sonar Summitに参加してください。
アジェンダを見て、3月3日の無料バーチャルイベントに登録するには、sonarsource.com/pragmatic/Sonarsummitにアクセスしてください。
それでは、HashiCorpと、会社が創業から6ヶ月後に資金調達することを決めた理由に戻りましょう。
でもええ、基本的にはシークレットをどこに保存するか? ということです。シークレットは単なるパスワードだけでなく、PIIのようなものも含まれていました。だからお客様のメールやアドレスをどう保護するか?
クレジットカード番号とか?
クレジットカード番号です。だからVaultはそれら全ての核心でした。今も続いています。
そういうものを構築するのは難しいですね。
ええ、それを構築したとき、実際にとても怖かったです。というのも、Vaultを構築したチームには、1学期分の学部レベルのセキュリティ経験以上のものを持つ人がいなかったという事実を隠していたからです。隠してはいませんでしたが、誰も聞かなかっただけです。
業界のプロのセキュリティエンジニアもいませんでした。プロのセキュリティ学者もいませんでした。ええ、それを構築しました。そのために多くの監査を受けました。怖かったですから。だからVault 0.1のために、スタートアップとしては非常に高額でしたが、数万ドルを2つの会社に支払って監査してもらいました。2つに支払いました。
早期ベータ版を、公開ではなく非公開で、レビューしてもらうために、セキュリティの専門家である多くの人々と共有しました。多くの良いフィードバックを得ました。でもええ、それをある意味では露出させたくありませんでした。だからええ、理解できますが、つまりこれは、経験がないかもしれない人々でも良いものを構築できることを検証していると思います。でも人々は学んでいたんですよね?
セキュリティのことは、すぐにプロフェッショナルを雇って、製品を手伝ってもらいました。セキュリティのことは常にかなりしっかりしていました。でも本当に示したのは、セキュリティ業界が必要としていたのは、やっていることの根本的な変化というよりも、ユーザーエクスペリエンスの変化だったということです。なぜなら、やっていたことは、既に存在していた数億、数十億ドル規模の会社と根本的には変わらなかったからです。でもエクスペリエンス、インターフェースの方法が劇的に違っていました。それはその良い例だったと思います。
Vault の後は何が来ましたか?
Nomadです。
Nomadですね。Nomadは私たちのスケジューラーで、市場に出るのが数年遅れました。
スケジューラーと言いましたか? オーケストレーターではなく?
私はいつもスケジューリングと表現していました。
何をしていたんですか?
シンプルなことです。コンピュートのプールがあります。ついに学部時代の問題を解決しました。コンピュートのプールがあります。特定の要件セットを持つアプリがあり、それを実行する場所を見つける必要があります。
学部時代の問題ですね。
これらを構築している間、数年かかったものもあると言いましたが、ビジネスとしてのHashiCorpはどう機能していましたか? 何らかのビジネスを生み出し始めましたか?
いくつかのランダムなソースからの収益がありましたが、実際の再現可能な成長するビジネスはありませんでした。だからビジョンを構築していただけでした。
創業者のビジョンですね。これら全てが必要だ、ブートストラップだと10年かかる、5年で構築して何とかしよう、という。
文字通りそれでした。
文字通りそれでした。全てオープンソースでした。私はいつもこの考え方を持っていました。会社が失敗しても重要ではない、なぜなら良いアイデアがあればオープンソースコミュニティが続けるだけだから、というものです。
だから当時の投資家にそれを言うことはなかったと思いますが、技術を世に出すことが最も重要なことだという考えがありました。
ビジネスは本当に何とかできればと思っていましたが、最も重要なことではありませんでした。
創業者になることを考えているエンジニアや、創業者かもしれない人にとって、これは投資家とどう機能しましたか? お金を入れてもらったとき、取締役会の席を得ましたか? 期待を管理する必要がありましたか? 少しビジネス帽子をかぶって聞いていると、4年間クールなものを構築しているけど、正確なビジネスプランはない、という感じです。どう機能したのですか? それとも最終的に何とかすると信じていたのか、オープンソースでのトラクションのようなものを見ていたのか?
トラクションです。私たちがやったことはシリコンバレーでは非典型的ではなかったと思います。大まかな手振りの説明方法は、シードは製品を構築することについてです。プロダクトマーケットフィットがあるかさえわかりません。教育された推測をしていますが、何かを構築しています。
Aラウンドを得ると、プロダクトマーケットフィットのヒントを証明していますが、まだ完全には持っていません。ヒントを証明しています。Bラウンドを得ると、プロダクトマーケットフィットを証明し、今は再現可能な収益を証明していません。
収益のヒントはありますが、製品が有用だとわかっています。人々が製品を好きで使いたいとわかっています。製品にお金を払いたいかもしれませんが、全員に製品にお金を払ってもらう方法は正確にはわかりません。
CラウンドとDラウンド以降は、再現可能な収益マシンを構築し続けるだけです。
そのフレームワークを念頭に置くと、私たちは正しい軌道に乗っていました。基本的には製品を構築するためでした。Aラウンドまでには明確なプロダクトマーケットフィットがありました。オープンソースの面でです。数百万のダウンロード、GitHubの多くのスター、これが響いていることを示す様々なシグナルがありました。収益はゼロでした。
だから資金を調達して、徐々にビジネス問題の解決に近づいていきました。平均的なスタートアップより1年か2年遅かっただけだと思いますが、一般的なキーフレームは同じで、タイムラインが少しずれていただけです。
ビジネスをすることを決めたとき、既にHashiスタックがあって、マネージドオファリングを構築しましたよね。覚えています。
ええ。商業化への最初の試みは完全な失敗でした。
ああ、本当ですか?
ええ。Atlasという最初の製品がありました。筋金入りのHashiCorp製品ファンでなければ知らなかったでしょうが、Atlasという最初の製品がありました。アイデアは、全ての製品を実行するというビジョンを商業的に出荷することでした。
そこにはいくつかの致命的な釘がありました。一つは、全ての製品を実行する必要があったことです。だから単なるVaultユーザーだったら、商業製品を購入または採用するのが本当に不可能でした。
二つ目は、アタッチするには大きすぎる問題だったということです。必要な採用に関係なく。会社内の複数の異なる購入組織が争っている問題を解決しようとしていました。だから全てのツールを採用した人でさえ、誰が支払うかという問題に直面しました。
エンジニアが支払うという単純なことではありませんでした。
正しいです。創業者になるエンジニアでビジネスバックグラウンドを持っていない人へのレッスンの一つは、学ばなければならなかった難しいレッスンの一つですが、企業はソフトウェアにお金を払いたいのですが、誰の予算がそれを所有するかで争うということです。
予算は重要ですよね?
はい。だから予算が存在しなければならず、ネットワーキングの問題のように見えたら、「ああ、ネットワーキングがそれを払うべきだ」と言うでしょう。だから私は欲しい他のおもちゃを買うためのより多くの予算を持てる。
または、より多くの人を雇える。または、ベンダー予算のように分解されるかもしれません。だから既に外部購入のために確保されているかもしれません。
ええ。だから私たちはこの製品を持っていて、セキュリティが支払うのか? ネットワーキングが支払うのか? インフラが支払うのか? 開発ツールが支払うのか? という感じでした。どこに行くのか? そしてそれはみんながお互いを指差すスパイダーマンのミームです。
最終的に何も売れません。だからそれはその理由で失敗でした。これを追いかけた総時間は覚えていませんが、確実に金曜日に取締役会がありました。取締役会は通常金曜日でした。サンフランシスコ市を拠点にしていました。
取締役会は南に1時間、本当のシリコンバレーにありました。うまくいきませんでした。怒鳴り声はありませんでした。「お前たちは台無しにしている」と言う人もいませんでした。そういうことは全くありませんでした。私の説明方法は、両親があなたに満足していないときだけど、満足していないと言う必要がないときです。
でも満足していないことはわかります。この取締役会がありました。家まで運転しました。帰りの運転は完全に沈黙でした。金曜日でしたから、通常やることは、まっすぐArmonの家に行って、ワインを一杯飲んで、報告して、物事について話し合うことでした。でもこの車の帰りでは話しませんでした。Armonはまっすぐオフィスに運転しました。私は疑問に思いませんでした。オフィスに行きました。これより少し大きくないテーブルに座りました。唯一の違いはホワイトボードがあったことだと思います。
ある時点で、私たちの一人が「まあ、うまくいかなかったね」と言ったと思います。お互いにわかっていました。良い気分ではありませんでした。そして、今ここの一連の出来事は非常に曖昧になっています。でもある時点で、サンクコストがなかったら、ゼロから始めるとしたら、今日何を違ったやり方でやるかという実験をしようと決めました。
全てをホワイトボードに書き出しました。書き出したのは、製品ごとのエンタープライズ製品で、Vaultを最初にやる、といったことでした。全てを書き出して、そこである程度の時間を過ごしました。まだ金曜日です。時刻的には土曜日かもしれませんが、まだ金曜日です。
Armonがボードを見て「なぜそれをやらないの?」と言ったと思います。なぜやらないの? という感じで、私は「ええ、なぜやらないの?」と言いました。だから、その週末の間に、全てを捨てることにしました。
以前やっていたこと全てを捨てる。2人の有料顧客がいました。契約違反するだけ。わかりません。何とかする。抜ける。終わりだ、と。
月曜日に全社ミーティングを招集しました。おそらく当時会社には20、30人しかいませんでしたが、Zoom経由で全社ミーティングを招集しました。当時Zoomを使っていたかわかりませんが、何らかのビデオチャットです。
そして「OK、方向を切り替えます。今、私たちのお客様はエンタープライズで、製品ごとのオープンコアです」と言いました。オープンソースがあり、クローズドソース機能を持つ内部でフォークされたバージョンがありました。
ええ、フォークでしたが、オープンコアビジネスモデルでした。Armonと私は人が辞めると思いました。何らかのレベルの信頼を打ち砕いて、ワオ、この人たちは何をやっているかわかっていない、と失うと思いました。正確な数字はありませんが。実際わかっていませんでした。
オープンコアでさえ当時は人々の口に少しイヤな味がありました。だから哲学的に「いや、オープンソースで働くためにここに来た。オープンコアはやらない」と言って辞める人がいると思いました。エンタープライズは単に退屈なことのようなものでした。人々が辞めるかもしれない複数の側面がありました。
誰も辞めませんでした。Slackの雰囲気は素晴らしく、超ポジティブでした。
何が起こったと思いますか? 社内の人はなぜそうだったと思いますか?
1対1やフォローアップで聞きました。聞いてみました。本当に、みんな明確な方向性と確信があったことにただ興奮していた感じでした。未知への恐怖はありました。でも以前は、壁にダーツを投げているだけで、この変なことをやっているだけで、お客様が正確に誰なのかわからない、という感じでした。
全てのこの不確実性がありました。今は、うまくいくかわからないけど、少なくともこれに向かってスプリントするだけ、明確に設定されたことがある、確実にエンタープライズ、確実にオープンコア、確実にVault、こういったこと全てが決まっていて、それが異なる確実性のセットを与えて、突然会社は「行こう」という感じになりました。だから誰も辞めませんでした。超うまくいきました。
年の時期は覚えていませんが、秋のようでした。Vault Enterpriseを構築しました。新年までに、販売しようとする最初の四半期以内に、それが違うと感じることができました。明らかに成功しているわけではありませんでしたが、行っている会話の質、購入プロセスで到達している距離、やっているスピードが違うと感じました。
このアプローチの何が違ったのですか?
ええ、つまり一部は古典的なスタートアップの、お客様の声を聞く、ということに帰着します。最初から聞くべきでした。なぜなら潜在的なお客様は、私たちが最終的にやったことをやるように叫んでいたからです。全ての製品を採用してこの絵空事を買って、というピッチをしていました。そして誰かが「OK、考えてみます。でもVaultでシークレットをどうレプリケートするんですか?」と質問する会議がたくさんありました。
もし私が聞いていただけなら、私はとても盲目でした。私たちの多くが盲目でしたが、私はとても盲目でした。もし聞いていただけなら、「待って、たくさんの人がシークレットレプリケーションについて聞いている」と気づいたでしょう。それは大規模の問題です。もしかしたらそれをクローズドソースにできるかもしれない、という感じです。それが最終的にやったことです。それがシークレットレプリケーションという最初の機能でした。
データセンター間でさえありませんでした。最初の機能は単一リージョン内のVaultサーバーのクラスターのようなものでした。
よりフォーカスされた製品を販売しますが、今は先ほど話した問題、セキュリティが確実に購入者でした。明らかな予算、話している明らかな人がいました。そのスケールに響く機能がありました。だから、それを完了させるという点で、はるかに高品質なミーティングをしていました。
ミッチェルは今、HashiCorpがエンタープライズのお客様が気にかけ、購入したい製品を構築した方法について話しました。それがそのスケールで響いたからです。これは私たちのシーズンの提示パートナー、Statsigにうまくつながります。
Statsigは、エンジニアリングチームに、構築するのに何年もの内部作業を必要としていた実験と機能フラグのためのツールを提供します。特にエンタープライズスケールで重要です。
実際にはこのように見えます。機能ゲートの後ろに変更を出荷し、段階的にロールアウトします。最初は1%または10%のユーザーに。何が起こるか見ます。クラッシュしたかだけでなく、気にかけているメトリクスに何をしたか? コンバージョン、リテンション、エラー率、レイテンシー。
何かおかしければ、すぐにオフにします。正しい方向に向かっていれば、ロールアウトを続けます。重要なのは、測定がワークフローの一部だということです。3つのツールを切り替えて、セグメントとダッシュボードを後から合わせようとしているのではありません。
機能フラグ、実験、分析が1つの場所にあり、同じ基礎となるユーザー割り当てとデータを使用しています。
これが、Notion、Brex、Atlassianのような企業のチームがStatsigを使用する理由です。Statsigには始めるための寛大な無料ティアがあり、チーム向けのプロ価格は月額150ドルから始まります。詳しく知り、30日間のエンタープライズトライアルを取得するには、statsig.com/pragmaticにアクセスしてください。
それでは、エピソードに戻って、彼らがVaultを構築した後に何が来たかを見てみましょう。
オープンソースとエンタープライズ
オープンソース側では常に聞かれますが、企業の購入者、法人の購入者は、オープンソースについて全く気にしません。全く気にしません。商業契約が必要なんです。だからそのクローズドソースの性質は、コードエスクロー、ダウンタイムなどに関する法的保護のようなものが必要な人もいました。それがその程度でした。
それ以外は、サポートが必要です。動作することを証明するための概念実証が必要です。他のお客様のスケールなどに関するホワイトペーパーが必要です。ええ、それがその後構築して進める必要があったことです。
それでVaultの販売を始めて、他の製品でもやりましたよね?
ええ、TerraformとConsulでやりました。全ての製品でやりましたが、全てのデータは公開されています。HashiCorpが上場企業だった時の公開レポートで見ることができます。本当に全部Terraformに分解されました。
覚えているのは、Terraformが業界全体で非常に人気になったことです。Hashiスタックはあったけど、他の部分が全て存在していることは、Terraformがどこにでもあるように見えたから知っただけです。その突然の人気はなぜだったと思いますか?
それを聞くのはとても面白いです。なぜなら、私は今それを受け入れて知っていますし、今あなたが感じているのと同じように感じています。Terraformはこの巨大なものです。でも最も長い間、私たちはVagrantの会社でした。他の全てのツールは、誰も他のツールを知りませんでした。それだけでなく、Terraform、最近は聞いていませんが、ある期間、私をイライラさせたことの一つは、「ああ、彼らは市場に最初だったから勝っただけだ」というものでした。
それをたくさん聞きます。私たちは市場に7番目くらいでした。
市場というのは、どのカテゴリーで?
インフラストラクチャアズコードの面で。
他のプレイヤーがいたんですね。
たくさん。ええ。ええ。そして誰も明確な勝者ではありませんでした。戦国市場でした。でも2014年に出た最初の年、Terraformが出たとき、当時の私のマーケティング戦略の一つは、あらゆるカンファレンスにいることでした。狂ったように旅行しました。話せるところではどこでも話していましたが、話せなくても、人と話すためだけに行っていました。
実際にここに小さな逸話があります。2020年3月にCOVIDのロックダウンが起こったとき、妻と私は夜にやることがありませんでした。まだ子供もいませんでした。カレンダーを開いて、2012年から付き合い始めて、約10年の関係で初めて、8日以上同じ場所にいることになると気づきました。
いいえ、約10年、9年間です。9年間連続で、少なくとも8日ごとにどこか違う場所にいました。
それだけ旅行していたんですね。
それだけ旅行していました。ええ。そしてもっと旅行するコンサルタントがいることは知っていますが、たくさん旅行していました。たくさんコーディングしていました。これら全てのことをやっていました。
旅行中もコーディングしていたに違いありませんね。
常にです。ええ。全てのシステムがありました。旅行を始めたとき、機内Wi-Fiは存在しませんでした。
ええ。ええ。正確に。
今でもちょっと不安定です。
ええ。だから全てのGitHubイシューをダウンロードして、分類して、反復していくスクリプトを書きました。ほとんど使っていましたが。
10分から15分以上かからないタスクに分解して、リストを作成しました。飛行機にいるときは、インターネットがないので、一つずつこなしていきました。
ローカルにコミットするだけです。
ええ。
それから戻ってきて、何人かはこれに気づいていました。着陸するとこのプッシュがあって、30のイシューが一度にクローズされたというメール通知を人々が受け取るからです。
ワオ。でもキーは、取り組むイシューを事前に計画することだと気づきました。地上でオンラインでそれをやりました。
ええ。
それから15分のチャンクに分解しました。飛行機でマルチアワーのフローに入るのは本当に難しいと気づいたからです。日本か何かに旅行しているときでさえ。飛行機でマルチアワーのフロー作業に入るのは本当に難しいです。
だから、重いデザイン作業のようなものではない、そういうものだけに取り組むつもりでした。それは全くありません。単なるバグ修正のようなものです。そういうものをクリーンアップするだけ。それが私のプロセスでした。
上場の経験
2021年、HashiCorpは上場しました。上場するとはどんな感じですか? 準備の面でも、どう感じたか? 後で何が変わったか?
準備側については、完全な答えは持っていません。なぜなら、上場する約6ヶ月前にエグゼクティブチームから退きましたから。だから計画の一部には参加していましたし、明らかに上場を計画していることは非常に認識していましたが、例えばロードショーには参加していませんでした。
でもええ、私の席から、参加していた部分、見えていた部分から言うと、それをやるには1年以上かかります。だからたくさんの準備があります。そして面白いことをいくつかやります。上場する2四半期以上前から、公開会社のように運営し始めます。
期限日は覚えていませんが、上場を中止できる日付があって、それはかなり近いです。実際に上場する日にかなり近いです。だから上場企業のように運営して、モック決算電話会議をやる点まで行きます。会議室のテーブルで実際にやります。
投資家は部屋にいない公開投資家です。他の場所に行って、スピーカーフォンで話して、あなたに聞くタイプの質問をします。
CFOまたは財務担当副社長が四半期の完全なレポートを提供します。彼らは受けるタイプの質問をフレーム化しようとします。それを実行して、十分にうまく実行されているかどうかを把握しようとします。それが準備のように感じることです。
そして膨大な量の秘密があります。なぜなら規制の観点から、これについて話すことができないからです。だから、Hacker Newsのコメントのような馬鹿げたものを見返すこともできますが、私はあらゆるトピックで完全に沈黙しました。会社が上場しようとしている最も明確なシグナルです。なぜなら、全てが疑わしくなったからです。
上場する8ヶ月前にHacker Newsのコメントをしたのを覚えています。顧問弁護士が真夜中に「それを削除する必要がある」と言いました。彼と話した後、物事に影響するかもしれないことはわかりましたが、問題だとは気づきませんでした。結局削除しました。
これは公開情報を漏らしてはいけないとか、そういうことですか?
正確な規制は正直覚えていません。
でも情報を漏らしたり、市場に影響を与えたりしてはいけないという規制があるんですね。
本当にそうではありません。つまり、全て情報ですが、どんな方法でも市場に影響を与えることはできません。だから約束はできません。なぜなら、上場すると言ったら、プライベート資金調達でさえ泡立つかもしれず、それは詐欺の一形態だからです。
だから基本的に全てについて話すのをやめました。他の人がどれだけ真剣に受け止めているかわかりませんが、私は、上場するためにニューヨークへのこの旅行を計画した点まで真剣に受け止めました。両親を招待しましたが、ニューヨークに行く理由を両親に言いませんでした。
ただニューヨークに行ってほしいと言いました。本当に本当に重要です。HashiCorpに関係があります。彼らは「もちろん」と言いました。そして「話せません」と言いました。彼らは「もちろん」と言いました。おそらく1ヶ月前に言いました。
犬がいました。叔母に犬の世話をしてもらう必要がありました。出発するまで、家族旅行に行くとだけ言いました。基本的に誰にも言いませんでした。両親以外は知りませんでした。
友達は誰も、何もありませんでした。会社で働いている友達以外は。でもええ、それが準備期間のような感じです。
ええ、Uberで上場したとき、そして以前読んだのは、上場する前にHashiCorpにVMwareが早い段階でオファーをしたと。
早い段階で、会社に2年くらいでした。
2年くらいでした。
おそらく会社に10年くらいで上場したと思います。だからええ。
買収しようとしたとき、どんな感じでしたか? ほぼ売却しそうになった時点はありましたか? 潜在的に売却しそうになった時点はありましたか?
近く感じましたし、後でそれが非常に近かったという多くの話を聞きました。VMwareの取締役会で1票に絞られたと聞きました。会社2年目でした。創業者の私とArmonを含めて3人の従業員しかいませんでした。だから従業員が1人、創業者が2人、3人でした。
VMwareからアプローチされました。これがどんなものかわかりませんでしたし、そうではありませんでした。彼らが現れて「買収したい」と言うようなものではありません。
いいえ。
いいえ、いいえ。
それは明白すぎます。
起こり方は、曖昧に話したいだけの低レベルのビジネスディベロップメント担当者からメールが来ます。曖昧な話は、あなたを買収することに興味があるわけではありません。大企業のBD担当者の仕事の一つは、エコシステムを理解することです。
だから本当に単に理解しましょう、という感じです。エグゼクティブがその人に、この会社について話すよう言ったかもしれません。既にエグゼクティブが周りを探っているかもしれませんが、ええ。だからそういう風に始まります。
私たちのオフィスに来て直接会いたいですか? という風になります。ああ、エンジニアリング担当副社長が立ち寄ったので話しましょう。会えて良かったです、とか。それから、これが私たちの実際のタイムラインだと思いますが、それから夕食があって、3人のVMwareエグゼクティブが夕食にいました。
その時点で興味があるかもしれないと思いましたが、まだとてもダンスでした。ああ、これはオファーがある何ヶ月も前です。まだとても社交的でした。飲んで、趣味や興味について話して、テクノロジーについては非常に基本的なことを話しました。本当にもっと雰囲気です。
夕食に行きます。それからもっと真剣になり始めました。VMwareオフィスでもっと時間を過ごしました。パートナーシップについて、VMwareが私たちの製品をどう助けられるかについて話し始めました。それがパートナーシップについて始まり、それから、VMwareのリソースがあったら何をするか、という仮説的な話になります。この時点で6回くらい会議をしています。何のオファーもありません。
それからある時点で、正直疲れていました。何も起こっていなかったので。
スタートアップで、これらの会議全てに行っているように聞こえます。
ああ、ベイエリアにさえ住んでいません。だから常に飛んでいました。時間の無駄でした。そして多くの創業者に与える警告は、M&Aは時間の無駄になるということです。だから別のM&A、合併買収の逸話があります。
合併買収は時間の無駄になります。だから後でもう一つの逸話を話しますが、最終的に丁寧に、OK、やるかやらないかという会話をしました。そして彼らは私たちの前にLOI、意向書を置きました。
意向書です。LOIは1ページでした。基本的にあなたを買収することを追求しているという半ば拘束力のある約束のようなものです。そこに数字はありませんでした。ただ曖昧でした。
まだ数字はないんですね。
ええ。まあ、口頭ではありますが、彼らは何も書き留めません。メールに何も入れません。そういうことは全くありません。ただ口頭です。
だからその時点で、口頭では2000万ドルという数字を得ていました。
それほど大きく聞こえません。
まあ、ええ、でも私たちは23歳です。
ああ。ええ。
3人で23歳です。
23歳です。私とArmonで会社の70%を所有しています。
OK。ええ。
ええ。控えめに言って興味深く聞こえます。人々に言うのは、買うものについて考え始めることです。それが危険な道です。それが起こることです。
そして、現象的に低すぎる、桁違いに低すぎる、だからもっと高く聞くべきだ、という人々からのアドバイスがありました。
そして、もう覚えていませんが、40か50か何かを聞いたと思います。そして彼らは単にイエスと言いました。OKと言いました。そして、桁違いに低すぎると。
そしてそれも口頭でした。だから拘束力のあるものは何もありませんでした。イエスとは言いませんでした。もっとOK、それに取り組みます、という感じでしたが、とても肯定的でした。
この間接的なビジネスセンスで間接的にイエスです。
間接的です。ええ。そしてそれは、さあVMwareのCEOに会いに来て、という風になりました。明らかに興味があります。なぜならまだ登っているからです。
ArmonとI私は冷めた足を得始めました。なぜならそれは夢を殺す金額だからです。お金は取りますが、VMwareのような会社にとって重要になるには小さすぎます。だから彼らはただ
なぜなら、個人的にはとてもお金があるけれど
個人的にはとてもお金があります。
でもVMwareレベルで、彼らの収益、全てを見ると、それが彼らにとって大したことではないと気づきます。
彼らには無意味です。ええ。無意味です。
それはクレイジーです。それは心を混乱させますよね。
ええ。ええ。だからそれは、個人的にあなたの人生は変わるかもしれないけど、私たち両方が本当に情熱を持っていたこのこと、他の何よりも取り組みたかったことがある意味で終わる、というものになります。なぜなら、おそらくESXか何かで働くことになるからです。
VMwareのCEOでさえないマネージャーを得ることになります。
エグゼクティブは、あなたの製品で全てのことをやろうとしているように聞こえますが、それは企業機械の中の1人のエグゼクティブに過ぎません。
だから冷めた足を得始めました。もし彼らが興味があるなら、もしかしたら私たちは何かをつかんでいるかもしれない。もし何かをつかんでいるなら、早い段階で売り切りたくない、夢が死ぬ方法で売り切りたくない、という感じでした。
だからそれは夢を殺すものです。Armonは非常に成熟していて、彼は私より2歳若いので、この時21歳です。
いや、彼は年上のように聞こえます。
ええ。ええ。ええ。ええ。彼は非常に成熟しています。そしてArmonは非常に成熟して、後悔最小化フレームワーク、どこから来たか忘れましたが、リスク最小化ではなく、後悔最小化フレームワークを考え出しました。
彼は、個人的に自分で行って考えて、私も同じことをしましょう、そして翌日入って、全てを殺すと言われた場合の数字を出しましょう、と言いました。次の4年間ESXで働くことになります。なぜなら、どうであれロックアップがあるからです。次の4年間働くことになります。それで、これは価値があった、クールだ、最小限の後悔またはそれはそれだった、と言えるような。
私たちの数字が正確にいくらだったか覚えていませんが、かなり近かったです。そして最終的に100になりました。そしてとても間違っていると感じました。どうして100を聞けるのか? という感じでした。でも、これをやると言った、それに固執しました。
だから戻って100を聞きました。ノーではありませんでした。
イエスでもありませんでした。
これにはもっと躊躇がありました。もっと
戻ってきます、という感じでした。わかりませんが、という感じでした。でもノーではありませんでした。そして基本的に戻ってきて、これには取締役会の承認が必要だと言いました。だから来週取締役会を招集します。計画外です。取締役会の時期ではありません。VMwareの取締役会を招集します。これに投票して、それから投票が通らなかったと聞きました。
それで終わりでした。
そんな小さなことがどれだけ影響するかクレイジーです。もしあれが追加のイエスだったら
誰が知っているか。1人です。VMwareにいたかもしれません。このプロジェクトで働いていたかもしれません。
ええ。ええ。つまり、まだTerraformを構築していませんでした。だからTerraform
Terraformはおそらく存在しなかったでしょう。
おそらく存在しなかったでしょう。高い確信で誰の投票だったか知っています。なぜその方法で投票したか知っています。もっと詳細を知っていますが、明らかに私に有利に働きました。でもええ。
HashiCorpを去って、独立しています。独立していることのクールなことの一つは、ものについて非常に率直だということです。Twitterにこの本当に興味深いスレッドがありました。大きなクラウドプロバイダーについて何でも聞いて、と書きました。HashiCorpで全てと働いたから、と。
当時のAzure、AWS、Google Cloudの経験はどうでしたか? 当時彼らがどう機能していたかの率直な見解、そしておそらく彼らについての見解がどう変わったか。
それに先立つのは、HashiCorpにいる間、明らかにクラウドファイターについて言うことに非常に注意する必要があったということです。なぜなら全てとパートナーだったからです。パートナーで、誰も侮辱したくありませんでしたし、全ての関係について非常にプロフェッショナルでした。
全員が好きです、という感じです。
ええ、または何も言わないだけです。
HashiCorpとクラウドプロバイダーとの関係
何か悪いことがあるなら何も言わない方がいいという教訓に従っていたんです。HashiCorpを辞めた後もしばらくはそれを守っていました。まだ太陽に近づきすぎていたというか、危険な領域にいたんですね。でも十分な時間が経って、ああ自分の意見なんて本当は大して重要じゃないなと思えるようになりました。
質問に答えると、全体的な見解としてAWSは本当に傲慢で、イライラするほど傲慢だったというのが私の印象です。
傲慢というのは具体的にどういう意味ですか。どんな形で彼らと仕事をしていたのか、どの部分がそうだったのか教えてもらえますか。
まず前置きしておきますが、私たちはAWSの非常に多くの人々と仕事をしましたし、個々人はみんな素晴らしくて親切で優しい人たちでした。ですから個人を批判しているわけではありません。ただ全体として、それがどうまとまって、どう感じられたかという話です。
傲慢というのは、パートナーシップでも、ミーティングを設定してもらうことでも、あらゆる場面で常に「私たちがあなたと話す時間を取ってあげている」という感じがしたんです。それだけでなく、微妙な雰囲気として「私たちはいつでも製品を立ち上げてあなたの会社を潰せるんだ」というものがありました。
誰も実際にそう言ったわけではないんですが、ある時点で「もし合意に至らなければ、私たちがこのサービスを作ります」みたいな状況になりかけたことはあります。
でもElasticとの件で後に実際に見ましたよね。
ああ、それはもう起きていましたね。
そうです。私たちとではありませんでしたが、OpenSearchで。
彼らはいつも公的には「エコシステムを拡大できて素晴らしい。ライセンスの文言通りにやっている」と言っていて、それは真実の要素を含んでいるんですが、それでも良いことではありません。
オープンソースに注目していた人たちは、AmazonがElasticに対してやったことを十分に評価していなかったと思います。本当にElasticのビジネスを傷つけましたし、会社が血と汗と涙を注いできたオープンソースが、どのように武器として使われ得るかを示しました。HashiCorpも同じでしたよね。寛容なライセンスで公開していたので。
MITかMPLライセンスでした。
つまりAmazonは何でも立ち上げることができたわけです。
ええ。2年間ほど、経営陣全体が常に恐れていた時期がありました。いつVaultサービスか何かが突然出てくるんじゃないかって。これが私のAWSに対する評価です。
例えばAWS Terraformプロバイダーのサポートを得るのに本当に苦労しました。正確な数字は覚えていませんが、5人ほどのフルタイムエンジニアをAWSプロバイダーだけに投入していて、福利厚生なども含めると年間約100万ドルの計算になります。
それは全て純粋なオープンソースで、商業企業との統合でしたが、彼らは全く協力してくれませんでした。クラウドプロバイダーの中で最後まで支援を提供しなかったのが彼らです。あるミーティングでドラマがあって、基本的に私たちは「AWSプロバイダーは非推奨で、もう終わりだと公に言います」と伝えました。コミュニティが引き継ぐかもしれないけど、私たちはもうやらないと。
協力を得られなかったからですね。
ええ。作業量が多すぎるしバグも多すぎる。正直、AWSは機能を速すぎるペースで出荷していて、もう割に合わないと。それで彼らは動揺して、ついに協力し始めました。彼らの側からは違う説明をするかもしれませんが、何年も動きがなかったのに、それを言ったら急速に動き始めたんです。
Microsoftに関しては、最も肯定的な見方をしています。技術的な製品は非常に複雑というか、使いにくかったです。
Azureですね。
Azureです。プリンシパルとか、たくさんの名詞があって、私は今でもAzureのIAM階層を完全には理解していません。チームと一緒に何とか動かして、それで終わりという感じでした。技術的には複雑でしたが、ビジネス面では有能でプロフェッショナル、そしてチームプレイヤーでした。
彼らとのミーティングでは、最初の質問はいつも「どうすれば両者が勝てるか」でした。素晴らしかったです。Terraformのサポートに最初に飛びついたのも彼らでした。何らかのバイアスがあるかもしれませんが、彼らは何年にもわたって一貫していました。Microsoftに関しては肯定的です。
Google Cloudに関しては、常に最高の技術、最も素晴らしい技術とアーキテクチャ思考を持っていました。でも誰もビジネスについて気にしていないか考えていないように感じました。パートナーシップミーティングでは、最もクールなエッジケースやスケーラビリティ、どう機能するかについて何時間も話していました。
公に見られる最良の例は、彼らが私たちと協力してプロバイダーを書いたとき、マジック何とかと呼ばれる非常に優れたものを構築するのに多くの時間を費やしたことです。新しいGoogle Cloud製品を出荷すると、すぐにTerraformリソースが用意されていて、自動化されているように見えないんです。非常に使いやすく、本当に良かった。
でも「どうやって共同販売するか。Terraformで立ち上げられるインフラの販売を、営業エンジニアのクォータにどう帰属させるか」みたいなビジネス面の話になると、全く反応がないんです。誰かを見つけるのが不可能というだけでなく、見つけても20分何か話して「わかった。あと2時間あるから、別のことを考えよう」みたいな感じでした。
ただし免責事項として、この知識は2019年頃のものです。過去7年間で劇的に変わったかもしれませんが、当時はそう感じました。
オープンソースとAIコントリビューション
オープンソースについてですが、あなたは現在もオープンソースに積極的に関わっていますね。特にAIによってオープンソースが大きく変化しているように見えます。Ghosttyでどんな変化を見ていますか。AIコントリビューションについて、オープンソースメンテナーに何が起きていますか。
今日のオープンソースが直面している問題として、複数ありますが、最も広範囲にわたって存在しているのは、AIコントリビューションです。特に信号対雑音比が非常に低いこと、つまり低品質なコントリビューションで非常にノイジーだということです。システムにかなりのストレスを与えています。
HashiCorpを辞めてからGhosttyを始めたんですよね。何年前ですか。2年くらい前ですか。
HashiCorpを辞めたのは2年ちょっと前です。Ghosttyのプロトタイプをいじり始めたのは3年前くらいです。でもHashiCorpを辞めた後、週20時間くらいもっと本格的に取り組み始めました。
Ghosttyに惹かれたきっかけは何ですか。どんなビジョンがあったんですか。
より良いターミナルです。より良いかどうかは主観的ですが。
私はインストールしましたよ。より良いと思います。
ターミナルで、意見の強いターミナルですね。最新のスペックを可能な限りサポートする非常にモダンなものです。画像表示やプロンプトをクリックしてカーソルを移動するなど、数十の例があります。
私を惹きつけた当初のものは、人々が通常与える良いアドバイスの真逆です。問題を見つけて解決策を構築し、その問題を解決するための最適な技術を選ぶというものです。私がやったのはその逆で、一連の技術を見つけて「これらの技術で何が作れるだろう」と考えたんです。
HashiCorpで12年以上、その前の3年間はインフラのオープンソースをやっていたので、合計15年間、ほぼ常にインフラやクラウドサービスについて考えていました。そのため、デスクトップソフトウェアやシステムプログラミングのスキルが錆びついていると感じていました。低レベルのシステムプログラミングが衰えていたんです。GPUについても扱ったことがありませんでした。
暗号通貨が流行っていましたが、私はその流れを無視していました。これはAI以前の話ですが、GPUは明らかに使われていて、どう機能するのか全く分からなかったので、デスクトップに行きたかったんです。
それでこれらの異なる技術を選んで「じゃあZigで」と。かっこよく見えたから試したかったんです。
Zigに詳しくない人のために説明してもらえますか。なぜZigはそんなに興味深く革新的で、多くの開発者の注目を集めているんでしょう。
他の人がなぜ注目しているかは分かりませんが、私にとっては、見た中で最高のより良いCという感じでした。私はCを書くのが実際に好きなタイプの人間なので、より良いCというのは素晴らしく聞こえました。
表面的にはかっこよく見えましたが、プログラミング言語を表面だけで判断するのは非常に難しいです。だから何かを作ってみたかった。GPU、デスクトップソフトウェア、何が作れるだろうと。
HashiCorpにいた間ずっとCLIを作っていましたし、ターミナルの中で生活していました。でもターミナルについてほとんど理解していない。だから、ターミナルを作るおもちゃプロジェクトをやってみようと思ったんです。それが始まりです。
多くのものがそうですが、当たり前だと思っているものの下の層を掘り下げると、想像していたよりもはるかにニュアンスがあって複雑だと気づきます。ターミナルも同じでした。表面の下を掘り始めると、彼らがどれだけのことをしているか、あるものがどれだけ壊れやすいか、特定のものがどれだけ良くなり得るかに気づいて、これをもっと良くしたいと思うようになりました。
Ghosttyの技術的詳細
開発者として、私もターミナルを使いますが、最も愚かな質問をさせてください。どれくらい難しいんですか。ターミナルは実際に何をしているんですか。Ghosttyがどう構造化されているか、何をする必要があるのか教えてもらえますか。
その質問はよく聞かれます。愚かな質問では全くありません。「もう完成したと思っていた」というフィードバックを最もよく受けます。ターミナルでやることなんてあるのかって。
基本レベルでは、それほど多くはやっていません。問題は、ターミナル開発者がやりたいことの機能が大幅に増えたということです。まず、彼らが何をしているか説明しましょう。アプリケーション開発プラットフォームのようなものです。オペレーティングシステムではないので、ハードウェアレベルの問題を扱うわけではありませんが、その上のアプリケーションサンドボックスのようなものです。
他のアプリケーションがその中で実行され、テキスト、色、画像、ウィジェット、マウスイベントなどをレンダリングする必要があります。最良の説明は、テキストコンテンツ用のブラウザのようなものです。ブラウザが持つ複雑さと同様のものを、ターミナルも持っています。小規模ですが似ています。
ターミナルができることを拡張しようとすると、新しい問題のエコシステムが生まれます。画像をターミナルに導入した瞬間、まったく新しい問題のエコシステムが生まれます。
Ghosttyの複雑さについて冗談めかして言う答えは、30%がターミナルで70%がフォントレンダラーだということです。本当にそんな感じです。GPUでレンダリングされようとCPUでレンダリングされようと、あのターミナル画面は、キャンバスに描画しているようなものなので、テキスト用のレンダラーを構築しているんです。そこから全てが派生します。
Ghosttyの大まかなアーキテクチャの観点からは、スレッドで分解するのが好きです。Ghosttyはマルチスレッドで、ほとんどのターミナルはそうではありません。これを良い点として言っているわけではなく、アーキテクチャを説明する良い方法というだけです。
中心となるUIスレッドがあり、ウィンドウなどを描画します。これはデスクトップソフトウェアではかなり標準的です。それからIOスレッドがあり、実際に表示されているシェルを実行します。私たちが送信するバイトや、それが返してくるバイトは、IOスレッドによって処理されます。
そしてレンダラースレッドがあり、実際に描画しています。VSYNCクロックで動作していると考えるのが最良で、30、60、120フレーム毎秒で、ターミナルの状態をサンプリングして描画しているだけです。
レンダラー自体は同じスレッド上のフォントサブシステムを使用します。このグリッドにこの文字、この文字セットがあるという事実を取って、それをフォントにマッピングする必要があります。多くの人は、オペレーティングシステムがそれを解決してくれると思っていますが、そうではありません。もっと高レベルでない限り、等幅テキストを簡単に描画することはできません。パーツを組み合わせる必要があります。これが全体像です。
そのレベルでは非常にシンプルです。そしてターミナルが持つ全ての機能をそこに拡張していくだけです。
2Dグラフィックスエンジンのようなものを構築しているんですね。フォントに非常に焦点を当てた。
ええ。レンダラー側からは非常にシンプルです。レンダラーは実際にはそれほど複雑ではありません。最も難しい部分は実際にはターミナルの状態を維持することです。
ターミナルの動作方法は、等幅セルのグリッドです。80×24、80列24行のようなものがあって、カーソルを動動かしたり、絵筆のようなものを赤く太字にして、その後は全て赤く太字にする、というコマンドをプログラムが送信できます。状態を維持して描画していくだけです。
それからターミナルでお馴染みのスクロールバックがありますよね。それが課題です。高速でパフォーマンスの良い方法でそれを行うこと。それがGhosttyで私が試みていることです。
私たちが実行する多くのベンチマークがありますが、速度を示す最も明白なものの一つは、大きなファイルをcatすること、つまり大きなファイルを読むことです。大量のテキストをダンプしたとき、どれだけ速く処理できるか。現代のターミナル間で顕著な違いが見られます。
Ghosttyだけとは言いません。Ghostty、Kitty、Alacrity、これらの新しいターミナルのどれでも、MacOSのターミナルアプリや従来のLinuxターミナルと比較して素晴らしいパフォーマンスを発揮します。
批判としては「なぜそれが重要なのか」というものです。簡単な答えは、多くの人が誤って大きなファイルをcatしたときに強制終了することです。Redditの作成者がHacker Newsに素晴らしいコメントを投稿してくれました。彼がGhosttyを愛する理由について、以前は本番環境のRedditログをtailしていて、ログが大量に吐き出されるので、中間ファイルに送ってから後で読み出す必要があったそうです。
レンダリングできるようにするためですね。
ええ、そうすれば実際に作業できました。もうその必要がなくなったんです。Ghosttyが十分速いので、ダンプさせながら、精神的にパースしながら作業できます。それが時間の節約になります。
ソフトウェアのパフォーマンスと職人技
最近の多くのソフトウェアはパフォーマンスを気にしていないという点について、いつか話すべきだと思います。実際の例があるのは新鮮です。いつかAIについても話すかもしれませんが、それは助けにならないかもしれません。でも職人技のレベルというものがあります。リソースを無駄にしないとか、効率的であるとか。
日常生活で見ています。より強力なリソース、ラップトップ、電話を持っているのに、速くならない。時々イライラします。
ゲームへの愛のようなものです。Ghosttyの多くは、ゲームへの愛です。レンダラーについて言いますが、以前免責したように、複雑ではありません。Ghosttyを2Dゲームだとは決して言いません。レンダリングの観点からは、2Dゲームの方がはるかに複雑です。
でもレンダラーについては非常に気にしています。私たちのレンダラーは、Macでフルスクリーンのグリッドセットに対して、各フレームの更新が約9マイクロ秒くらいで完了します。描画時間は含まれていません。これは状態を取得してGPUに作業を送信するだけの時間です。約9マイクロ秒で、GPUは多少時間がかかります。
120ヘルツ、120フレーム毎秒のフレームは8,333マイクロ秒です。9マイクロ秒なら、GPUがどれだけ時間がかかるかの数字はありませんが、それほど時間はかかりません。
多くの余地と作業の選択肢を残していますね。
私が言いたいのは、2,000マイクロ秒にしても問題なかったということです。そのパフォーマンスは得られたでしょう。でもそれは楽しくない。10マイクロ秒以下にしたいんです。
その楽しさが好きです。
ええ。多くの時間を費やしました。800マイクロ秒くらいから9くらいまで下げたんです。ブログに書きました。エンドユーザーには違いがないのに、素晴らしいと思いました。
でもおっしゃる通り、職人技とゲームのレベルですね。
AIツールの活用とワークフロー
Ghosttyの開発を始めた頃は、ChatGPTが出た頃だと思います。ツールがいくつかありました。開発の日常でツールセットはどう変わりましたか。
それには2つの側面があります。一つは、AIがターミナルに大きな後押しをしたということです。面白いことに、クラウドコードやこれらのことのおかげで、ターミナルで過ごす時間が増えました。2023年にターミナルの使用が増えると言われたら、増えないと答えたでしょう。
ターミナルを救うという幻想は持っていませんでしたし、実際救っていません。AIが登場してこれらのCLIツールが出てきて、CursorアプリやClaudeアプリのようなものを見ていると、ターミナルを離れているように見えますが、それでも疑似ターミナルで非常に多くのことを実行しています。そこにあるターミナルの数は2023年より大幅に多いんです。笑えるほどです。
超ランダムですね。
超ランダムです。それがGhosttyでやっていることの一部で、libghosttyと呼んでいるものを抽出しています。実際にはもう抽出済みです。皆がターミナルの非常に小さな表面積を再発明していて、彼らがそれをやるとあらゆる種類のことが壊れます。Dockerのビルドやプッシュ、Herokuのようなプラットフォームへのプッシュで、実際にはそれほど奇妙ではない奇妙なことをターミナルで十分やると、プログレスバーを描画したりすると、カオスのようにレンダリングされます。
至る所で。
至る所で。それは単に、ターミナルの小さなサブセットを不十分に実装しているからです。ターミナルは人々が思っているより複雑なんです。
libghosttyは、人々がどこにでもターミナルを埋め込めるミニマルなゼロ依存ライブラリです。
素晴らしいですね。
MITライセンスで、至る所で壊れたターミナルを見るのにうんざりしているので、これを使ってくださいという感じです。
もう一つの角度は実際のAI使用です。難しいところですが、私は大ファンです。正しいカテゴリー内でですが、革命的なツールだと思いますし、使っていて大きな喜びを得ています。毎日使っています。Claude Code、Cursor、Codeex、チャットツールなど、人生の何らかの側面で毎日使っています。
それによって、実際に何について考えたいかを選べるようになりました。これが最も重要だと思います。次の2時間、このつまらない定型的な作業に費やさなければならない、学びたくないことに費やさなければならないと、いつも限界を感じていました。でも今はそれを学ぶ必要がありません。そのカテゴリーでスキル形成は得られませんが、その2時間を別のことに費やせます。それが私にとって最高です。
ワークフローでは、単一のエージェントを使いますか。複数のエージェントを使いますか。実験していますか。
あらゆるものを試しました。標準的なワークフローとしては、常にエージェントに何かをさせておくように努めています。寝ている間はそこまでしませんが、多くの人はそこまでやります。でも私は働いている間、基本的に、コーディングしているならエージェントに計画させたい。彼らがコーディングしているなら、私はレビューするか、常にエージェントが何かをしているべきだと考えています。
別のタブで実行しているんですね。
ええ、別のタブです。時には複数のこともあります。エージェントがすることのクリーンアップ作業を多くやっています。Gastown風のものは実行しません。私が言わば市長なので、あまり多く実行したくありません。彼らの作業のクリーンアップはそれほど楽しくないので。
でも時々2つを競争させて実行します。より難しいタスクで、彼らが完全に成功する自信が高くないからです。だからClaudeとCursorを対決させたり、一つにコーディングさせて、もう一つに何らかのリサーチタスクをさせたりします。
リサーチには絶対に大好きです。素晴らしいです。それから私が別のことをする。でも2つ以上はやらないですね。
彼らが生成するコードは、常にレビューしますか。それとももう少し緩くなりましたか。クロージング・ザ・ループ、検証を誓う人もいますが、あなたはまだ正確なコードを見たい、期待通りか正しいかレビューしたいタイプですか。
何に取り組んでいるかによります。Ghosttyならレビューしています。入るもの全てをレビューします。でも家族の誰かのために個人的な結婚式のウェブサイトをセットアップしたようなものなら、全く気にしません。試した3つのブラウザで正しくレンダリングされたか。電話で正しくレンダリングされたか。コードがどんな感じかは気にしません。ネットワーク呼び出しをしていないか。秘密にアクセスしていないか。気にしません。出荷します。2ヶ月しかオンラインにならないんだから。
GhosttyでのAIポリシーはどう変わりましたか。1年前くらいに、誰かが使っているなら開示を求めていたと記憶しています。ごく最近、もうダメだと取り締まりましたね。
ええ、また変更する予定です。変更というより反復です。1年前に開示を求め始めて、人々から非常に公正な質問があったのは、コードがどう生成されたかが何の問題なのかということです。
私にとって常に重要だった理由は、それを修正するのにどれだけの努力を注ぐかを決めるからです。AIでコードを生成して本当に素早くやったなら、あなたのコードを修正するのに何時間も費やすつもりはありません。あなたが自分の時間を使って修正してください。
その人があまり人間の時間をかけていないことが分かっているから、それを反映しようとしているんですね。
努力には努力でです。あなたが何時間も費やしたなら、私も何時間も費やして助けます。でも数分しか費やさず、何も読まずに壁越しに投げたなら、私も数分で読んで「結構です」と言って閉じられるべきです。公平です。それをよりよく理解する必要がありました。
悪いコードについてではありません。オープンソースは常に悪いコードのコントリビューションを受け取ってきましたから。でも以前の違いは、通常それらの悪いコードのコントリビューションは、本当に最善を尽くして多くの努力を注いで、その悪いコードのポイントに到達した人々から来ていたことです。
だから人々は違う振る舞いをしていました。私はいつも、これは非常にジュニアな人か、プロジェクトに新しい人だと考えて、お返しをしようとしました。これをもっと良くすべきで、慎重なレビューをして教育しようとしました。でも低努力の悪いコードなら、慎重なレビューはしません。
繰り返しますが、これらのことを知りたかったんです。開示はまあまあうまく機能しました。問題は開示ではありませんでした。問題は、受け取る低品質なAI PRの量が高すぎるポイントに達したことです。
なぜそれが起きたと思いますか。より多くの人がエージェントに、抱えている問題を修正するPRをコントリビュートするよう指示したのか。理論や実際に見た証拠はありますか。
理論もあるし、いくつかの証拠も見ました。明らかに、AI使用全般の増加がありますが、私がある時点で見た真の傾向、段階的変化は、正確にいつ起きたか分かりませんが、ある時点で彼らがPRを開き始めたことです。
以前は、コードを生成して、コミットしたりするかもしれませんが、それでもブランチにプッシュしてからプルリクエストを開いていました。ある時点で、彼らがPRを開き始めたんです。そしてAIの完全な証拠があります。少なくとも今日、この録画時点では、ClaudeがPRを開く方法は、本文なしで下書きを開いて、後で本文を編集してからレビュー用に再度開くというものです。
人間はそうしませんね。
年に1人の人間がそうするかもしれません。でも今は1日に3回起きています。AIを開示していなくても隠していても、ああ、って分かります。非現実的な速度で起きます。下書きが1分以内に入って、1分以内に開かれます。純粋なAIです。
数日前にこれについてツイートしました。これらのエージェントツールがPRを開くのを一時停止してくれたらと思います。それが本当に多くの摩擦を引き起こしているポイントだと思うからです。
ポリシーをどう変更しましたか。PRを閉鎖することを検討していますか。最近、その考えが頭をよぎったと述べていましたね。
その瞬間はクラッシュアウトしていたと言えます。でもある意味そうです。AIで書かれたPRは、受け入れられた機能リクエストに関連付けられていない限り、もう許可されないというポリシー更新を出荷しました。
だから、話したこともないことについて突然やってきて「これをやったから、はい」みたいなことはできません。1日に2、3件くらい受け取ります。それは閉じます。内容さえ読みません。AIだと分かります。修正issue番号がないのが分かります。閉じるだけです。コードが良いかどうか分かりません。気にしません。ポリシーです。そんな時間はありません。
現在はそこに落ち着いています。そして別の移行の真っ最中で録画しています。既にPRを開いています。コミュニティのための明示的な保証システムに切り替えます。もうPRを全く開けなくなります。AIかどうかは関係ありません。
どこから来たかは関係ないと批判していた人たちにとって、もう関係ありません。重要なのは、別のコミュニティメンバーがあなたを保証したかどうかだけです。保証されたら、永遠に、または無期限にPRを開けるリストに追加されます。
悪い振る舞いをしたら、あなた、あなたを招待した人、彼らが招待した人の全ツリーが、レポから永久にブロックされます。
これはLobstersを少し思い出させますね。
Lobstersです。それをベースにしています。誰かを保証することで、自分の評判を賭けるというアイデアです。私は理性的な人間です。これが起きて、私か他のメンテナーかコミュニティが間違いを犯した場合、Discordやメールでやってきて、理性的で謝罪的な人に見えれば、模擬裁判のようなセッションを多くの時間をかけて行うつもりはありません。「わかった、もう一度チャンスをあげる」という感じです。
そのシステムに移行しています。少し違う点があると言うべきです。これはLobstersに触発されていますが、特にAI空間では、PIというプロジェクトに触発されています。同様のメカニズムを行っています。ツリーほどではないですが、保証されない限りPRを開けないという似たようなものです。
PIは何に基づいて構築されていますか。
自己改善型の、独自のエージェントツールキットを構築するようなものです。皮肉なことに、AIツールですが、コード品質とアンチスロップについて非常に気にしています。だから似たメカニズムを持っています。ツリーほどではないですが、保証されない限りPRを開けないという似たようなものです。
私たちが行く他の違いは、誰かを肯定的にマークできる保証に加えて、実際にユーザーを非難できることです。悪い行為者がいたら、実際に禁止できます。再度コントリビュートしようと試みることさえできません。
昨日あったのは、誰かがPRを開いて、関連付けられたissueがなくAIだったので閉じました。そうしたら10分以内に再オープンしたんです。同じものではなく、新しいブランチを再送信して再オープンしました。「なんてこった」と思いました。
こういうことが時間の無駄なんです。
オープンソースの未来とフォーク
AIのせいでオープンソースのほとんどが変わらなければならないように感じますよね。あなたの話は唯一のものではありません。プロジェクトがPRを閉鎖したとか、GitHubはプロジェクトが自動的にPRを閉じたり拒否したりできる機能を出荷していると思います。
オープンソースは多くの点で変わらなければならないと思います。誰が書いたか覚えていませんが、論理的な極端の一つは、エージェントが非常に優れていれば、もうオープンソースは必要なくなるということです。自分で構築できるからです。
理論的にはそうですね。
それが極端です。私はその極端を信じませんが、それが極端の一つです。問題は、変更を送信するのに必要な努力という点で、以前は自然な逆圧力があったということです。それで十分でした。
でも今、それがAIによって排除されました。PIが使う言い回しが好きですが、AIは妥当に見えるが不正確で低品質なコントリビューションを作成することを些細なことにします。それが根本的な問題です。
オープンソースはある程度、常に評判のシステムでしたよね。ある程度の信頼を得て、より多くのアクセスを得る。そういう風に機能するはずです。でもその評判システムがある意味でAIによって利用されてきました。デフォルトでPRを許可することが利用されてきました。
私たちがプロジェクトのために提案しているこの保証システムは、オープンソースが何であるかに非常に忠実だと思います。オープンソースは常に信頼のシステムでした。以前はデフォルトの信頼を持っていましたが、今はデフォルトの拒否で、誰かによって信頼を得なければなりません。
もっと多くのフォークが起きると思いますか。
そう願っています。
今までフォークは、維持するのに多くの努力が必要だったので、適切なプロジェクトをフォークするのは実行可能に見えませんでした。
ええ。AIとは別に、私は常に大きな支持者でした。過去数年間、もっと多くのフォークがあるべきだと公に支持してきました。オープンソースでメンテナーが利用されてきた理由の一つは、コントリビューターがある種の権利意識を持っているからだと思います。有害な権利意識かどうかは別として、何らかの権利意識があります。価値ある変更を行ったから、クリーンで素晴らしく動作するから、受け入れるべきだと。でも本当にその必要はありません。絶対にありません。
何度も見てきました。高品質なPR、完璧なPRがあるのに「ノー」と言うと、コミュニティに怒りがあります。でも10年前からHashiCorpで言ってきたことは、マージボタンを押すのが最も簡単なステップだということです。マージボタンを押すところまで到達するのが最も簡単なステップです。学部生でもできるべきです。その後が大変なんです。
ロードマップの文脈内で、マージしたものを何年も維持すること。バグ、顧客ニーズ、そういったことです。それが難しい部分です。何かをマージすると、それを永遠に維持することにサインアップしているようなものです。機能を削除するのは非常に難しいです。何でも削除するのは。
だからオープンソース、OSIオープンソースで得られる核心的な特権はフォークです。それが得られる権利なので、フォークして自分のソフトウェアを維持すべきです。
Gitと開発ツールの未来
興味深いAIの影響の一つとして、誰かがツイートしていましたが、大手テックがモノレポを再アーキテクト化することを検討しているという噂があります。エージェントツーリング、AIツーリングのせいで、より多くのコードが生み出されているからです。実際に何が起きているんですか。Gitの何が問題なんですか。
Gitには多くの問題があると思いますが、モノレポの問題は、Gitが非常に大きなリポジトリに比較的弱いということです。リポジトリ全体をクローンする必要があるからです。それを修正する拡張機能はありますが、公式のメインラインGitは実際にそれをできません。
非常に大きな変更に対して、非常に大きなリポジトリを維持するのはちょっと面倒です。それから多くの変動があると、トランク、メインやマスターブランチに変更を入れるのが非常に難しくなります。コンセプトのリベース、マージキューがある程度それを解決します。
マージキューは人間にとってあるスケールで機能すると思いますが、かなり深くなり得ます。でもそれを10倍したら、控えめに10倍だと思いますが、誇大広告サイクルを信じて100倍や1000倍したら、メインブランチに何らかのまとまりを素早く得ることが完全に維持不可能になると思います。
だから問題の集合があると思います。マージキューの問題、ディスク容量の問題、ブランチレビュータイプの問題です。他にもツイートしましたが、Gitにはブランチがあってブランチをプッシュアップしますが、ブランチはポジティブなものだけです。
PRを閉じて受け入れない場合、ブランチは削除します。GitHubでは閉じたPRに再アクセスできますが、多くの人はPRステージにさえ到達しません。実験して「ああ、これは正しい方法じゃない」と思ってブランチをプッシュしません。それは比較的重要な情報です。
ポジティブほど重要ではありませんが、もっと多くのブランチがあるべきだし、決して捨てない情報がもっとあるべきだと思います。私たちは、メール用のGmailの瞬間のようなものにいると思います。以前はメールを本当にキュレートして削除する必要がありましたが、Gmailが登場して皆に1ギガを無料で提供しました。
マーケティングのタグラインか何かで「メールを削除しない」というのを見た記憶があります。アーカイブするだけですよね。それが私たちがコードでいるべき場所だと感じます。巨大なレポ、大量のコンテキスト、そのGitレポ内の関連するコンテキストを見つけるためのより良いツーリングが必要です。
バージョン管理されたレポと言うべきですね。実際の例を求めるなら、私はこの分野で活動している、現在ステルスの会社にアドバイスをしています。実際の例は非常にエージェント的な会社によって駆動されています。本当にオールインしてクール・エイドを飲んでいる会社です。
彼らがこれらのエージェントが引き起こしている変動の量に苦しんでいます。人間よりもはるかに多いです。AI レビューの問題とかではありません。本当にリリースの問題、マージキューの管理、人間がリポジトリ内の正しいデータセットにアクセスすることなどです。
パフォーマンスの問題が主にGitの問題ですか。それともワークフローの問題ですか。
ええ、両方です。パフォーマンスは確実に、でもワークフローもです。プルするたびにプッシュできない。プルするたびに別のチェーンがあって、プッシュするたびにそこにあります。
多くの並行作業も起きていますね。Gitは今後数年で存続していると思いますか。
誰が知っていますか。でも興味深いのは、12年から15年で初めて、その質問を笑わずに誰かが尋ねているということです。
笑っていませんよね。
5年前に「5年後にGitは存在していますか」と言ったら、「もちろん存在しているでしょう。そう思わないなんてクレイジーだ」と言われたでしょう。でも今、人々はその質問ができます。もちろん笑う人もいますが、Gitが5年後に存在しないかもしれないと批判的に考える人がいます。
プロンプト履歴を保存したいと思います。多くの場合、プロンプトを読むことが実際に、大量の生成されたコードなら、プルリクエストは意味がないからです。
変更は起きます。GitとGitHubフォージは現在の形ではエージェントインフラで機能していません。今日機能していません。変更が起きる場所があると思いますが、正確にはどこか分かりません。自分で変えようとしているわけではありませんが、エージェントユーザーとメンテナーとして受ける側にいて、これは機能していないと思っています。
他のエンジニアリング実践で、10年、20年、それ以上比較的安定していたもので、変わらなければならない、または変わりそうだと思うものは何ですか。CI/CD、テスト、コードレビュー、その他の方法など。
Cursorにはこの言い回しがあって、ちょっとクリックベイトですが本当です。「全てが変わっている」と。20年の比較的短いキャリアで、これほど多くのことが一度にテーブルに乗っていると感じるのは初めてです。
私は楽観主義者なので、本当にワクワクします。とても楽しいです。でもエディターのモビリティがこれほど見られたことはありません。エディターはかつて、誰かがエディターを選んだら、そのエディターから離れさせるのが非常に難しいものの一つでした。固執します。
過去数年間のVS CodeとCursorの間のエディターモビリティのレベルは、飛び回っているだけで、信じられないほどです。だからそこに多くのモビリティがあります。Cursor自体が素晴らしい例です。AIなしではエディター製品で決して得られなかった狂気の評価額に達した会社です。
エディター、フォージ、確実にCI/CDです。テスト全般だと思います。エージェントをより良くするには、その作業を検証できる必要があるからです。だからテストは、最高のテストケースシナリオでも完全なカバレッジを持っていないというところから変わります。最高でも完全なカバレッジを持っていますが、それは非常に極端です。
非常に良いテストケースシナリオは、エッジケースの一つとハッピーケースの一つとバッドケースをテストするだけで、通過すれば問題について考えた人間とペアになっているのでおそらく良いです。
でもAIは、この機能をこの方法で動作させたいという目標指向です。どこかに仕様やテストがなくて、他のものが別の方法で動作すべきだと見えなければ、自分の目標への道で壊します。
これは多くのことで呼ばれています。私が最も好きなのはハーネスエンジニアリングのようなものです。
ハーネスエンジニアリング。
ええ。私の今年の目標の一つは、それにもっと時間を費やすことです。AIが悪いことをするのを見るたびに、その悪いことを防ぐか修正できたツールを構築しようとすることです。
製品から製品のハーネスへの作業に移行するようなものです。だから多くのことがあって、テストははるかに広範囲になるように変わらなければならないと思いますが、CI/CDはリソースパフォーマンス面でそういうことをできるように設定されていません。
だから変わると思います。全てがテーブルに乗っています。本当に興味深いです。
多くのツールが構築されますね。もう一つ、観測性です。
それと同じトピックで、量とスケールと観測性について、サンドボックスのようなものもあります。インフラにいて、インフラに深く関わっていたのに、コンテナが至る所に浮かんでいる最小計算単位の量を爆発させたとき、それが上がるとは思いませんでした。
予測可能に上がるとは思いましたが、勾配変化で上がるとは思いませんでした。エージェントが必要とするサンドボックス環境のせいで、既に勾配変化で上がっています。私にとって非常に興味深いです。全く新しいシステムをストレスするからです。
私が取り組んだもの、私が取り組んだ全ての製品、でもエコシステムのDockerやKubernetesのようなものも、大幅にストレスされると思います。あるレベルのスケールのために設計されていますが、これは異なるタイプの、特に非本番ワークロードスケールで、サポートしなければならないものです。
楽しい問題ですね。
採用と優秀なエンジニア
採用に戻りますが、多くのエンジニアを雇ってきましたね。以前、本当に興味深いことを話していました。HashiCorpの文脈だったと思いますが、雇った最高のエンジニアの一部は本当につまらない経歴を持っていたと。それについて話してもらえますか。誰が最高のエンジニアで、どう…
それはより良いフレーミングですね。
これは支持します。HashiCorpでの時代から覚えている最高のエンジニアのほとんどは、悪名高いほどプライベートです。プライベートでいたいからではなく、パブリックであることを気にしないというべきでしょうか。
特定せずに慎重に説明したくありませんが、単にソーシャルメディアのプロフィールを持っていないことが多いです。正直、9時から5時のエンジニアです。帰宅して夜にコードを書きません。家族と時間を過ごすだけです。
でも労働時間中に他に何もしないので、ロックインしていて本当に優れています。時間をかけることではなく、スキル面でも超強力です。
だから、レジュメをレビューしているときにいつも見つけたのは、GitHubアカウントさえ持っていないような人です。「目立つために公開コントリビューションが必要だ」と言う人もいます。それは目立つ一つの方法です。
でも公開コントリビューションがゼロで、聞いたこともない会社で働いてきただけなら、それは私には興味深いです。何か深いものを知っているかもしれないと。だから、面白いことは、皮肉なことに、私はソーシャルメディアに多くの時間を費やしていて、これらのエンジニアは私より優れています。
でも面白いのは、ソーシャルメディアに費やす全ての瞬間、時間はゼロサムです。ソーシャルメディアに費やす全ての瞬間は他の何かから奪っています。問題は、全てのエンジニアが知っているように、フローに入るために心を本当に入れるのに時間がかかることです。何かを始めるのに時間がかかります。
だから何かがコンパイルされているときにタブを切り替えてソーシャルメディアに時間を費やすと、考えることの点で何かを諦めています。私がやることの最高のものの一つは、ソーシャルメディアに多くの時間を費やしますが、不健康な量かもしれません。でも夜にも不健康な量の時間を費やします。
不眠症はありませんが、眠りにつくのに長い時間がかかります。暗闇の中でただ座っているだけです。大好きなんです。シャワーでやる人もいますが、私には十分長くありません。ベッドに横たわって、明かりを消して、妻が寝ていて、ただ考えることが好きです。
頭の中でコードを書いています。製品について考えています。ウェブサイトのコピーについて考えています。頭の中でCLIを実行して、どんな感じかを考えています。昨夜、9時半にベッドに入りました。私は父親なので早く寝ます。
いつ起きなければならないか分からないときに起きなければなりません。
ええ。そんなに長く起きているとさえ感じなかったんですが、トイレに行かなきゃと思いました。本当に寝るべきだと思って見たら、12時半でした。考えていたのは、とても馬鹿げていますが、この保証システムについて、保証がどう機能するか、しないかだけでした。
私はいつもこういうことをしてきました。競争することは喜んでするし、競争は楽しいと思います。でも製品構築空間で誰とでも競争するのは公平なゲームだと感じています。彼らよりもそれについて考える時間を費やすと思うからです。
人々はそれをオフにすると思いますが、私はオフにしようとしません。
AIエージェントを使ってきて、これが変わるかもしれないと思いますか。これらのエージェントがあなたのために考えたり作業したりできるので。AIの使用が当たり前のこの新しい世界で、どう採用しますか。ほとんどの開発者はプロンプトするでしょうし、書く人は減っていきます。最高の開発者は明らかにコードの書き方も知っていますが。
AIツールの能力は絶対に求めます。全てにそれを使う必要はありません。それは私には重要ではありません。でも他のツールと同じように、時に有用で時に有用でないというエッジを理解する重要なツールです。完全に無視すると、時々最適でないことをすることになります。
最高の例は概念実証です。実際の製品組織では、常にアイデアがあって、それが機能するかどうかを確認するためにデモする必要があります。出荷するつもりのないスロップを壁に投げる方が、1週間かけるより、1日かけるより、人間として有機的にやるより良いと思います。どうせ捨てるんだから。
悪いアイデアだから捨てるかもしれませんが、証明したいです。だからただスロップしてください。これがなぜそんなにニュアンスがあるのかです。オープンソースへのスロッピーなPRについて興奮しますが、それは時と場所があるからです。それはそのための時と場所ではありませんが、あります。
だからその方法で雇いたいし、私が持っているその目標、常にエージェントを稼働させるという目標を、皆が持つよう努めます。繰り返しますが、コーディングである必要はありませんが、何か余分なことをあなたのためにしていることです。それを目指します。
運転が私の最大のものです。ここに運転してくる間、Deep Researchを実行していました。常に30分を境界で費やします。起きたときと、仕事を止める前、家を出る前とかに、30分費やして「エージェントに次に何をさせられるか」を考えます。
それは遅いです。エージェントが次にできる遅いことは何か。ここまで1時間運転すると分かっていました。1時間よりはるかに速く終わりましたが、ライブラリリサーチをする必要がありました。これらのプロパティを持ち、この方法でライセンスされている全てのライブラリを見つけてください。
HP3の素早いものを調べていました。そのエコシステムグラフを構築してください。出発する直前、この保証システムに関することに取り組んでいて、やっていることのエッジケースを完全には理解していませんでした。
手動で考えますが、なぜエージェントを始めないのか。このレポを見てもらって、Cursorを使ってオラクルに相談するように、何が欠けているかもしれないエッジケースについて深く考えてもらいます。
あと2時間仕事があれば、エージェントは必要ありませんでした。自分でやったでしょう。でもないんです。だからやらせないのか。常に一つ稼働させることが私の目標の一部です。
残念ながら今は稼働しているものがありません。全部終わったからです。
興味深いですね。この稼働しているエージェントは、今ではとても自然で、自分の考えの邪魔にならないと正しく感じていますか。自分の考えをして、自分の作業をしますが、時々ちらっと見たり、pingしたり、開始したり、今ではそれが邪魔にならないほど自然ですか。それが気を散らさないというのが重要だと思います。
そうです。実際、全てのエージェントツールがやることをオフにしています。デスクトップ通知をオフにします。デスクトップ通知はほとんどの場合間違いだと思います。だからオフにします。いつエージェントを中断するか選びます。エージェントは私を中断できません。
それから別の側面があって、私のエンジニアリングが変わったと思うのは、考える必要のないタスクと考える必要のあるタスクを特定して、仕事をエージェントに委任しようとすることです。
考えないタスクをやるのが生産的に感じることがあって「ああ、今日たくさんやった。これを手に入れた」みたいになります。でも多くの場合、ただそれを委任しようとします。
考えることが減ると言う人が多くいます。ツールを間違って使えば、考えることは減ると思います。エージェントを起動して、YouTubeを見たりソーシャルメディアをスクロールしたりするだけなら。
でも代わりに、何について考えるかを選ぶ方法と見れば、その考えることを犠牲にする必要はないと思います。でも問題は、人口の大多数はおそらくそうしないだろうということです。
でもそれでも良い考えの材料だと思いますし、あなたがどう使っていて、あなたにとってどう機能しているかを聞くのは良いことです。
起業家へのアドバイス
いつこの2つ目のエージェントを稼働させ始めましたか。何が切り替えを起こしましたか。モデルが良くなったからですか。
正確にどのモデルかは覚えていませんが、ある時点がありました。Claude Codeは出てすぐに試しました。去年の3月か5月でした。
ベータが3月で、公開リリースが5月でしたね。
ベータは使わなかったと思うので、おそらく5月です。正直それほど感銘を受けませんでした。でも夏までに本当に素早く、夏のある時点で、ああ覚えています。とても多くの肯定的な発言を見たので、ツールの使い方で遅れを取るのではないかと恐れ始めました。
それで実際に自分自身に強制し始めました。まだ信じていませんでした。だから全て手動でやっていましたが、同じ品質の結果を生み出すようエージェントにプロンプトする方法を見つけるよう自分に強制していました。
作業を倍にしていたので、はるかに遅く働いていました。倍以上でした。遅いし、行ったり来たりするし、既に作業が終わっているのに、全てこういうことでしたが、自分に強制していました。そして見つけられないものがありました。まだそこになかったようなものです。
でも他のものを見つけました。何千人もの他の人々が到達したのと同じポイントに自然に到達して、ああ、別の計画ステップをすればはるかに良くなるというようなことです。皆がそこに到達しました。
それから、実行するためのより良いテストハーネスがあれば、はるかに良くなることを見つけました。皆がagents.mdやclaw.mdなしで始めると思います。同じことです。間違いを犯してそれをagents.mdに追加すれば、二度とその間違いをしないと気づきました。ああ、というような感じです。
新しい人や、アンチAIの人がAIを試すライブストリームをいくつか潜伏して見たときに気づく漸進的なことです。ハンマーを大きく振り外しているようなものです。
Gitを採用しようとして1時間使って、それでより生産的にならないと決めた人のようなものです。Gitに熟達するには1時間よりはるかに長くかかりますが、努力を注いで後で報酬を得ます。
AIツールもある意味同じだと思います。
そうではない人への最初のアドバイスは何ですか。
最初のアドバイスは、エージェントで自分の作業を再現することです。本当にエージェントにコードを書いてもらいたくないなら、作業のリサーチ部分を再現してください。
理由は何であれ、コードを書いてほしくない人が多くいます。でも作業の隅々を見つけて、その部分を置き換えることができます。人として置き換える必要があるという宣伝を受け取る必要はありません。
潜在的な創業者にアドバイスを与えていますね。成功した創業者だからです。エグジットもしました。この素晴らしい会社を構築しました。「創業者になりたい」と尋ねるメールをたくさん受け取ります。どんなアドバイスですか。通常どんなアドバイスを与えて、どう受け取られていますか。
通常、もっと具体的なことを尋ねます。「成功するために何ができますか」と言われたら、一つ、生存者バイアスを持つ誰かに相談していることを常に免責します。それを考慮する必要があります。
でも生存者として自分の経験を喜んで共有しますが、生存者バイアスがあることを理解してください。でも通常、もっと具体的なことを尋ねます。何をしようとしているのか。「プロジェクトをオープンソースにすべきか」「リモートにすべきか」「エンタープライズをやるべきか」みたいなことです。
でも私が人々に与える最も一般的なアドバイスは、スタートアップはあなたが思っているよりはるかに長いということです。おそらく10年は取り組むことになります。多くの人は5年と言いますが、私は10年と言います。本当に10年取り組みたいことですか。
10年取り組んで、他の誰よりも良くやると本当に信じていると言うには、ある程度の傲慢さが必要です。その背後には何もありません。傲慢さとエゴ以外の実体はありません。だからある程度のエゴと傲慢さを頭に持つ必要があります。
でも多すぎると、入ってくる変化に盲目になります。これが通常与える最初のアドバイスです。多くの人がクールなアイデアを持っていますが、比較的早く燃え尽きます。
現在いくつかの会社にアドバイスしていますね。彼らと何を見ていますか。サーバーは最近何をしていますか。以前と違って何をしていますか。その風景はどうですか。
繰り返しますが、本当に文脈的です。AIスタートアップなら、非常に非常に違います。
AIスタートアップはどう違う働き方をしていますか。
これまで見たどのスタートアップよりも速く進むという多くのプレッシャーがあります。業界が非常に速く動いているので、AIスタートアップにはアドバイスしていませんが、何人かと話しました。アドバイザーとしてさえ、プレッシャーが多すぎると感じます。
牽引力か収益か何かを通じて、素早く自分自身を証明するよう押されています。AIが狂気の速さで進むことを可能にすべきだという、そのエコシステム内のメンタリティのようなものがあります。
それに加えて、狂気の速さで動いている多くの会社があります。変化が起きています。それが一つのことだと思います。それ以外は、多くの同じことです。リモート対非リモート、オープンソース対非オープンソースです。
ソフトウェアエンジニアの役割が今変わっているのを見ますか。特にA&E企業で、エンジニア、あなたのようなエンジニアが、実際にはるかに生産的になっています。はるかに多くのコード、はるかに多くのアウトプットを生み出せます。
もっと多くの帽子をかぶる、ビジネスと話す、少しミニ創業者のようになることを押されていますか。
より生産的と言うのは躊躇します。より多くのことができるという期待があると見ています。それは必ずしもより生産的ではありませんが、例えば、フルデモを構築できるべきだ、全てをデザインするべきだ、それをするのにチームは必要ないというようなことです。
少なくともデモの観点からは。そうしない理由はありません。そのためにスロップを出荷できるからです。それで良いんです。でもこれはまだ同じですが、効果的にリサーチして、ある意味でより曖昧なタスクを処理できるべきだというのがはるかに多く見られます。
実験する能力がはるかに高いと言えます。でもプロダクション化することに関しては、常にそうだったものと似ていると感じます。AIカンパニーのドッグフードを食べている会社が多くあると思います。何でも出荷するというのは、ちょっと怖いと思います。
Anthropicを見て、彼らが10日でClaude Coworkを構築して、10億ドル企業になるのを見て、なぜ自分たちがそれをやっていないのかパニックになっています。
大きな変化は、プレシード的な観点から、プロトタイプを構築するためにシードを調達する必要があるというようなことです。プロトタイプを見せてください。ほとんどのことについて、本当に素早く構築できるはずだからです。それができない難しいテックはまだありますが。
多くのコーディングをして、コーディングについて多くの考えもしていますね。眠ろうとしているときでさえ。コーディング以外、テック以外で、あなたのバケツを満たすものは何ですか。
明らかにステレオタイプ的なこと、休憩を取ったり家族と一緒にいたりとかですが、最大のものは内向的なので、静かな一人の時間が最もエネルギーを補充してくれます。
ビーチにかなり近いところに住んでいて、悪いメンタリティにいるとき、うまくいかないとき、非生産的に感じているとき、何かが起きているとき、ラップトップを閉じて外を散歩するだけで、そういうことがとても助けになります。
多くの趣味とかありますが、一般的な充電としては、それが何よりもです。友達と出かけるのが充電という人が多いことは知っています。それも好きですが、それは私にとって完全な充電ではありません。
おすすめする本とその理由は何ですか。
私はニュース以外はほぼフィクションしか読みません。
素晴らしい。
最近読んだフィクションの本は古い本で、簡単に読めるので、「これを読んでいるなんて馬鹿だ」と思われないことを願います。でも、「The Invisible Life of Addie LaRue」でした。ロマンチックなタイプのフィクション小説のようなものですが、永遠に生きるために魂を売る女性についてです。
でも代償は、部屋を出ると誰も彼女を覚えていないことでした。全ての人間的つながりを失いながら永遠に生きることがどんなものかという、彼女の人生全体を通じての話です。
フィクションを読むのが好きです。
夜にフィクションを読むのが好きです。現実逃避なのか、単に少し違ったものを得られるだけなのか分かりません。コーディングとか何とか全く違います。多分ただそれが物事をオフにするのを助けるだけかもしれません。
個人的には、正直、専門的なノンフィクションよりはるかに多くのフィクションを読んでいます。
私も同じです。私のテレビのバージョンでもあります。テレビは私にとってより社交的な活動です。妻が一緒に何か見たいなら、一緒にショーを見ます。でも一人なら、ショーは見ません。おそらく読みます。
素晴らしい。これら全ての詳細を通じてくださってありがとうございました。あなたがどう働いているか、HashiCorpの歴史、全てが本当に興味深くて動機づけられるものでした。
ありがとうございます。
ミッチェルとのこの長くて興味深い会話を楽しんでいただけたことを願います。この会話から私に本当に響いたことの一つは、ミッチェル自身のルールです。常にエージェントに何かをさせる。必ずしもコーディングではなく、ただ何かをさせる。
例えば、このポッドキャスト録音に運転している間、彼は家を出る前にDeep Researchを実行していました。彼は自分自身に尋ねます。「留守中にエージェントができる遅いタスクは何か」と。
これ全てにおいて重要な部分は、全ての通知をオフにすることです。エージェントは彼を中断できません。彼が準備ができたときにエージェントを中断します。ミッチェルが担当で、彼が委任した作業をする相棒がいて、彼は解決している問題に集中します。
これを聞いている皆さんへの良いチャレンジです。次にデスクから離れるとき、ラップトップを閉じる前に、自分自身に尋ねてください。留守中にエージェントができる遅いタスクは何か。このエピソードを楽しんでいただけたなら、ソフトウェアエンジニアリングがどこに向かっているか考えている同僚と共有してください。
まだ購読していないなら、今が良いタイミングです。このような会話がもっと来ます。ありがとうございました。次回お会いしましょう。
コメント