ノダール・ダネリヤ、ShuttleのCEO兼共同創設者 – インタビュー・シリーズ

ノダール・ダネリヤ、ShuttleのCEO兼共同創設者 – インタビュー・シリーズ：ノダール・ダネリヤは、2019年にShuttleを共同創設して以来、CEO兼共同創設者を務め、YC Summer 2020のスタートアップから開発者向けのプラットフォーム・エンジニアリング・カンパニーへの成長を牽引してきた。Shuttle以前は、Provenance Technologies Ltdのチーフ・リスク・オフィサーを務め、量的ヘッジ・ファンド・戦略に取り組んだ。また、ロンドンとGoogleでテクノロジーとデータ関連の役職を歴任した。

Shuttleは、オープンソースのクラウド・インフラストラクチャ・プラットフォームで、コードの注釈からインフラストラクチャを導出することで、バックエンドの開発とデプロイを簡素化し、開発者がRustやその他のコードを書くことに集中できるようにする。プラットフォームは、迅速なデプロイ、ボックス外のリソース・プロビジョニング、シームレスなスケーリングを可能にし、13万回以上のデプロイを行った10万人以上のエンジニアによって使用されている。Shuttleは、ゼロ・コンフィグ、AIアシスト・エクスペリエンスをすべての言語に拡大し、GitHub CopilotやCursorなどのツールと統合することを目指している。

あなたがShuttleを共同創設するきっかけとなった瞬間や苛立ちは何でしたか？そして、初めに解決しようとした問題は何でしたか？

転機は、量的ヘッジ・ファンドのトレーディングを率いていたときに訪れた。私たちには優秀なエンジニアがいた。博士号を持つ人、シニア・プラットフォーム・エンジニア、機械学習の研究者など。しかし、クラウド・インフラストラクチャが常にボトルネックだった。トレーディング・モデルやバックエンド・サービスを構築すること自体は難しくなかった。問題はデプロイだった。セキュアにライブにすること、スケーリングすること、クラウド・サービスを接続すること。そこですべてが遅くなる。ある時点で、エンジニアチームの半分以上がシステムを維持するためにDevOpsの作業を行っていた。

私が印象に残ったのは、コードや数学の複雑さではなかった。優秀な人たちがほとんどの時間をクラウドと戦うことに費やしているのを見ていることだった。誰もその作業をしたいとは思わないが、避けられない。Shuttleはそのギャップを解決するために作られた。つまり、「私は何かを作った」と「それが信頼性高く動いている」というギャップを解決することだった。

Shuttleは2019年に創設されたが、そのときはAIコード・ツールの現在の波はまだなかった。AIアシスト・開発が主流になったことで、当初のビジョンはどのように進化したか？

根本的な問題は同じままだったが、AIがそれを劇的に増幅させた。Shuttleを始めたとき、インフラストラクチャはすでに強力なエンジニアリング・チームの制限要因だった。Copilot、Cursor、Claudeなどのツールが登場すると、そのボトルネックは無視できなくなった。

突然、開発者は数分でフル・アプリケーションを生成できるようになったが、そのアプリはすぐに壁に当たった。AIはコードを書くことができるが、クラウド・リソースを信頼性高く構成して管理することはできない。私たちが解決しようとしていたギャップは、より広くなり、より緊急性を持つようになった。数百万の人々が今、プロトタイプを構築しているが、実際にプロダクションまで届くのはそのうちの小さな部分だけだ。

ビジョンは、「開発者にとってインフラストラクチャを簡単にする」から、「新しい世代のビルダーにとってインフラストラクチャが機能するようにする」に進化した。ソロ・ファウンダー、小さなチーム、AIエージェントなど、バックエンド・コードを生成できるが、クラウド・コンフィグレーションと戦いたくない人たちが増えている。私たちがサービスしている対象者は、伝統的なエンジニアだけではなくなった。

AIツールが開発者がコードを書く方法を変えたという点では、どの部分が最も改善されたと思いますか？また、チームがまだ苦労している部分はどこですか？

コード生成は飛躍的に進歩した。コードを書く部分はほぼ解決された。特にフロントエンドの場合、パターンがよく理解されているため、コンポーネント、スタイル、レイアウトなどが簡単に生成できる。

チームが苦労しているのは、コードを書いた後に来る部分だ。デプロイ、インフラストラクチャ、運用など。AIがAPIエンドポイントを生成しても、自動的にデータベース、ストレージ、キュー、ネットワーク、パーミッション、デプロイ・パイプラインを作成できない。バックエンド・インフラストラクチャは、コード生成の進歩に追いついていない。

AI生成アプリケーションのデプロイは、ボトルネックとされることが多いです。システムをプロダクション化する際に、コード生成自体と比較して、具体的に何が難しいのでしょうか？

問題は信頼性と結果の重大性にある。コード生成はフォギブなものだ。AIが間違いを犯しても、すぐに見つけて修正できる。インフラストラクチャの間違いは違う。パーミッションが間違っていたり、リソースの設定が不適切だったり、セキュリティやコストに関する間違った仮定をしていると、後に深刻な問題が表面化する可能性がある。

Shuttleは最近、Neptuneをプラットフォームの次の進化として導入しました。Neptuneは「ユニバーサルAIプラットフォーム・エンジニア」と説明されています。開発者がプロトタイプからプロダクションレディのバックエンドに移行する際に、実用的には何を意味しますか？

Neptuneは、コードとプロダクションの間の欠けていたレイヤーを埋める。実用的には、開発者がアプリケーション・ロジックに集中できるようにすること意味する。Neptuneがすべての残りの部分を処理する。必要なインフラストラクチャを理解し、リソースをプロビジョニングし、シークレットを管理し、デプロイを処理し、サービスをオーケストレートする。

AIツールがバックエンド・システムを生成するようになるにつれて、スピードと抽象化の必要性と、コントロール、セキュリティ、観察可能性の必要性をどのようにバランスさせますか？

信頼が答えだ。インフラストラクチャでは、信頼は能力よりも重要だ。悪いサプライズがあっただけで、信頼を失う。セキュリティの穴、壊れたデプロイ、大きなクラウドの請求など。私たちが早くから学んだのは、AIが関与するすべてのものが理解可能でレビュー可能でなければならないことだ。開発者が手動で設定しなかったとしても、 何が起こっているのか、そしてなぜ起こっているのかを見られる必要がある。

Neptuneは、AIシステムが他のソフトウェア・システムを構築、デプロイ、管理するエコシステムで、どのように進化していくと思いますか？

私たちは、アイデアと動作する製品の間のギャップがほぼゼロになる世界に向かって進んでいる。製品は単に速く構築されるだけでなく、実際の使用状況に基づくリアルタイムのフィードバックに基づいて継続的に改善されるようになる。ソフトウェアは静的ではなくなり、常に生成され、変更され、進化するようになる。すべてがどこかで動作する必要がある。インフラストラクチャ、パーミッション、リソース、信頼性が必要だ。

私たちの長期的な目標は、AIアシスト・DevOpsのデフォルト・システムになることだ。基本的に、AIプラットフォーム・エンジニアだ。開発者がCursorでコードを書いたり、AIエージェントが自律的に生成したりしたコードでも、Neptuneがコードから完全に動作するプロダクションレディのサービスへと導く層になるべきだ。

創造性が無限大になれば、インフラストラクチャが制限にならしてはいけない。AIエージェントや自動進化する製品が普通になるにつれて、私たちの役割はクラウド・インフラストラクチャとの相互作用をシームレス、予測可能、安全なものにすることだ。開発者、ファウンダー、企業がインフラストラクチャと戦うのではなく、価値の創造に集中できるようにすることに焦点を当てている。

素晴らしいインタビュー、詳しく知りたい読者はShuttleを訪けてください。