Ali-Reza Adl-Tabatabai、Gitarの創設者兼CEO – インタビュー・シリーズ

Ali-Reza Adl-Tabatabai、Gitarの創設者兼CEOは、シリコンバレーで最も影響力のあるテクノロジー企業の1つである、Uber、Google (GOOGL ) 、Facebook (META ) 、Intel (INTC ) 、AMD、IBMでキャリアを積んだベテランエンジニアリングリーダーです。Gitarを2023年に立ち上げる前に、Uberのエンジニアリング部門のシニアディレクターを務め、開発者プラットフォームのイニシアチブを牽引し、GoogleではSite Reliability Engineeringを担当し、Communications、Photos、Social、Cloud、テクニカルインフラストラクチャなどの製品を担当しました。

彼のキャリアの初期には、Intel LabsとFacebookのHipHop VMチームでコンパイルテクノロジー、仮想マシン、並列コンピューティングシステム、ハードウェア最適化に取り組み、スタンフォード大学でもコンパイル設計を教えていました。プログラミング言語、インフラストラクチャの信頼性、開発者ツール、ラージスケールシステムアーキテクチャに関する彼の長年のバックグラウンドは、進化するAIパワードソフトウェアエンジニアリングの風景において、著名な人物としての地位を確立しています。

Gitarは、AI支援開発の拡大で生じた課題、すなわち企業システムへ流れ込む大量の機械生成コードを検証し、安全を確保することに取り組んでいます。AIエージェントがコードレビュー、CI/CD障害の調査、バグや脆弱性の特定、修正提案を自動化し、GitHub、GitLab、Jenkins、Jira、Slackなど既存のワークフローに統合されます。同社はコード生成だけで競うのではなく、信頼性と安全性を維持するエージェント型品質ゲートを構築しています。

あなたはUber、Google、Intel Labsでエンジニアリングを率いてきました。大規模な開発者プラットフォームとインフラストラクチャに取り組んでいました。どのような経験がGitarの創設に繋がり、コード検証ではなくコード生成に焦点を当てたのですか?

Uber、Google、Facebook、Intel Labsで、さまざまなスケールの開発者プラットフォームに取り組んできました。開発者エクスペリエンスは競争上の優位性であるという教訓が繰り返し出てきました。優れたツールは最高のエンジニアを引き付け、企業が迅速に動くことができます。開発者は、迅速でノイズのないツールを求め、自動化されたgrunt workを求め、フローを維持することができます。しかし、開発者ツールは深く断片化されており、多くの企業は一貫したエクスペリエンスをまとめるために大量のエンジニアリングリソースを費やしています。私は、そこを修正することの利点を直接見ました。

AIは、以前よりも多くの開発者ワークフローを自動化できるようにします。コード生成はすでに十分にカバーされていますが、それはボトルネックを下流にシフトしました。検証、リファクタリング、メンテナンスのコードが今までにない速度で生成されるようになりました。Gitarはそこに焦点を当てています。AIがより多くのコードを書くにつれて、希少なリソースは生成ではありません。信頼性、正しさ、メンテナンス性が重要です。コード検証は、AI生成コードが実際に安全にプロダクションに到達するかどうかを決定するワークフローの部分です。それが解決すべきより難しい、より貴重な問題です。

AI生成コードの台頭により、多くのチームは現在「コード過負荷」と呼ばれる問題に直面しています。この問題は今日の企業内でどれほど重大なものですか? チームはどこで最も苦労していますか?

変化はコードの書き方ではありません。すでにチームが吸収できるよりも速く進んでいます。変化したのは、コードの後に続くすべてのことです。AIツールは、チームがレビューできるよりも速くプルリクエストの連続流れを生成し、システムの設計ではなかった部分に圧力がかかります。

すべての変更はまだ検証を通過する必要があります。コードレビュー、CI、セキュリティチェック、承認など、すべてが消え去るわけではありません。以前は管理可能なフローでしたが、バックログに変わりました。チームはアイデアや実装でブロックされていません。信頼性でブロックされています。出荷できますか? 安全ですか? 何か微妙なものを壊しましたか?

業界は主にコード生成の高速化に焦点を当ててきました。なぜ検証が見落とされているのでしょうか? それが今より重要になる理由は何ですか?

コード生成の下流のシステムは同じペースで進化していません。出力が増加すると、下流のすべてがストレスを受けます。プルリクエストは大きくなり、頻度が増えます。CIの失敗は積み上がり、レビューサイクルは圧縮されます。誰もがすべての変更を深く調べる時間がありません。

品質は低下し始めます。エンジニアが気にしないわけではありませんが、ボリュームによりトレードオフが必要になります。プラットフォームチームはパイプラインの問題、失敗のトライアジ、フローを維持するための負担を増やします。シニアエンジニアはコーディネーターとして働き、ログを組み立て、問題を診断し、安全にマージできるかどうかを決定します。

Gitarはコードレビュー、テスト、CIワークフローをAIエージェントで処理します。これらのエージェントは従来の静的分析ツールやルールベースのパイプラインとどのように根本的に異なりますか?

違いは表面的なものではありません。実際のエージェントは、プロンプトに応答するだけでなく、マルチステップの作業を処理し、計画し、ツールを使用し、コンテキストを追跡し、タスクを進め、常に入力を必要としません。

ほとんどのシステムはこの基準を満たしていません。出力を生成しますが、実行を管理しません。実際のワークフローに配置されたとき、これらのツールのギャップはすぐに明らかになります。複雑さを軽減しません。多くの場合、管理する必要のある別のレイヤーを追加します。

信頼はソフトウェア開発における自動化の重大な障壁です。Gitarはどのようにして検証プロセスがチームに依存できるだけの信頼性があることを保証していますか?

うまく機能するパターンはシンプルです。作業を小さなステップに分割します。明確な境界を定義します。出力を継続的に検証します。リスクを伴う決定では人間を関与させます。

エージェントはコードをレビューし、大規模環境で見落とされやすい問題を表面化できます。CI障害を分析し、関連エラーをまとめ、考えられる根本原因を示し、修正を提案したり、管理された方法で適用したりできます。

あなたのプラットフォームでは、チームが独自のエージェントを作成できます。エンタープライズの採用におけるカスタマイズの重要性は何ですか? どのような興味深いユースケースを見ていますか?

カスタマイズはエンタープライズの採用にとって不可欠です。プラットフォームチームは、CIを会社の特定のニーズに合わせて調整するために、多大なリソースを費やしています。これには従来、独自のスクリプト、構成、ツール統合、ログプロセッサ、現代のDevインフラストラクチャを維持するためのその他のDUCTテープが必要でした。

Gitarはその作業を圧縮します。プラットフォームチームは、自然言語のプロンプトを使用してカスタムチェックを記述できます。これにより、従来のプログラム分析では困難または不可能なものを検証できます。たとえば、ユーザー向けの文字列を曖昧な翻訳としてフラグ設定するか、AGENTS.mdファイルの更新を検証します。カスタムワークフローもプルリクエストの上に自動化できます。Jiraの問題にPRをリンクする、解決されていないレビューコメントのためのフォローアップチケットを開く、不安定なテストを自動的に再試行する、またはPRの要約にカスタムのTODOリストを追加するなどです。

これにより、エンジニアが行う手動トリアージは減ります。エンジニアをループから外すのではなく、時間の使い方を変えるのです。多くのシステムは完全自律ではなく、チェックポイントを備えて動作します。

チームが独自のエージェントを作成できることは、企業導入にどれほど重要ですか。また、興味深いユースケースには何がありますか。

カスタマイズは企業導入に不可欠です。各プラットフォームチームは、自社固有の要件にCIを合わせるため、スクリプト、設定、ツール統合、ログ処理などに大きな資源を費やしています。

Gitarはその作業を圧縮します。自然言語でカスタムチェックを書き、翻訳が曖昧なUI文字列やAGENTS.md更新など従来の解析では難しい項目を検証できます。さらにPRとJira課題の連携、未解決コメントのチケット化、不安定テストの再実行、PR要約へのタスク追加も自動化できます。

最も興味深い用途は、私たちが予想しなかったものです。チームは自分たちのコードベースと課題を最もよく知っています。「CIにXを確認してほしい」という要望を短いプロンプトにできれば、標準機能として想定しなかった作業まで直ちに自動化します。

現代のエンジニアリングチームは、GitHub、GitLab、Jiraなどの複雑なツールのスタックに依存しています。Gitarが既存のワークフローに統合されることの重要性はどれほどですか?

導入には、開発者がすでにいる場所で応えることが必要です。新しい画面やダッシュボード、ツール間の切り替えは望まれていません。既存の作業を速く静かにする必要があります。そのためGitHub、GitLab (GTLB )、Jiraなどへの深い統合が戦略そのものです。

しかし目標は統合だけではありません。PRレビュー、チケット連携、フォローアップ、不安定テストの再実行など、複数ツールにまたがるワークフロー自体をバックグラウンドで自動化します。エージェントがレビュー指摘やCI障害を直接修正し、最終的には方針を満たす変更の承認とマージまで扱います。

最終形は、開発者がログインする新しいツールではありません。既存ツールが自らより多くを実行し、開発者が判断を必要とする仕事に集中できる状態です。

人によるコードレビューはいずれ例外になると述べています。組織がその移行を信頼するために何が必要ですか。

信頼は一度にではなく段階的に構築されます。組織は自分たちのコードで、AIが本当に重要なバグや脆弱性を見つけ、ノイズを増やさず、予測可能に動くことを確認する必要があります。

第1段階は検出です。誤検出率を低く保ちながら実際の問題を見つけると確認できれば、より広い範囲のレビューを任せられます。

第2段階は修正です。AIが問題を指摘するだけでなく修正し、人手なしでPRのブロックを解除してCIを通します。修正が反復可能で安全であることが信頼の条件です。

第3段階は承認です。エージェントが安定してPRを通せると分かれば、組織が定めた規則の下でAIに承認を許可します。制御された範囲から始めることで信頼を築けます。

第4段階はマージです。チームが納得する条件の下でAIが変更を取り込みます。競合解決、ブランチ規則、デプロイ前チェックなど、明確な基準を満たす必要があります。

AIを標準レビュアーにする移行は、一度の信頼の跳躍ではありません。証拠が積み上がるごとに一段ずつ上るはしごです。

あなたは、シニアエンジニアの役割が次の数年間にどのように進化することを想定していますか?

シニアエンジニアはすでに、ログを集め、問題を診断し、安全にマージできるかを決める調整役へ移っています。これは当初計画された役割ではなく、負荷に耐えられなくなったシステムへの反応です。

エージェントが反復的な検証を担うにつれ、エンジニアはループ内に残りながら、より上位の仕事へ移ります。手動トリアージが減り、システム設計、方針設定、例外処理、ツールでは決められない判断に時間を使います。

Gitarは最近、900万ドルを調達しました。資本の優先事項は何ですか? 次の12〜18ヶ月間に成功とは何ですか?

資本は2つの優先事項に向けられます。最初はマーケティングです。エンタープライズの動きを拡大し、開発者への認知度を高め、Gitarが存在することをチームに知らせています。2つ目は製品です。完全に自動化されたコード検証と品質に向けて構築を続け、エージェントの機能を深化し、ワークフローのカバレッジを拡大し、開発者がすでに使用しているツールとの統合を強化します。

今後12〜18か月の成功とは、多くの企業顧客がコードベース全体でGitarを使い、開発者コミュニティがAI駆動コード検証の標準として認識し、エージェントがレビュー、修正、マージを徐々に広く自動化している状態です。順調なら、検証はボトルネックではなくAI開発を安全に拡大する仕組みになります。

素晴らしいインタビュー、ありがとうございました。詳しく知りたい読者は、Gitarを訪れてください。