AIがコード生成において飛躍的な進化を遂げる一方、生成されたコードを本番環境で維持・運用する段階では依然として大きな課題が残されている。Resolve AIの創業者兼CEOであるSpiros Xanthosは、AIによるコード生成が加速する中で、むしろインシデント対応やトラブルシューティングといった運用フェーズにおける負担が増大している現状を指摘する。同社は、エンジニアが深夜や週末のオンコール対応から解放されるよう、AIエージェントによる自動監視・診断・修復提案のシステムを構築している。本対談では、マルチエージェントアーキテクチャの実装、AIモデルの役割分担、エンジニアリングの抽象化レベルの進化、そしてAI時代におけるソフトウェアエンジニアの役割変化について深く掘り下げられている。
AIコード生成と本番環境の課題
なぜAIは膨大なコードを生成しているのに、本番環境で稼働するプロダクトは少ないのでしょうか。この問題について、Resolve AIの創業者兼CEOであるSpiros Xanthosさんと話をしていきます。この対談はResolve AIの提供でお送りします。Spirosさん、お会いできて嬉しいです。
こちらこそ、Alex。招待してくれてありがとうございます。
どういたしまして。さて、今日はAIコーディングに欠けている要素について話していきたいと思います。世の中にはたくさんのAIコードが存在していますが、そのコードが生成された後に何が起こるのか。あなたの会社はそれをAIで処理し始めています。まず広い視点から始めたいと思います。現在のAI技術の状況について、あなたの見解を聞かせてください。AIは今どこにいて、どこに向かっているのか。そして、より良くなるために必要な主要な構成要素は何でしょうか。
まず第一に、AIは非常に大きな意味で現実のものになっていると思います。少なくとも私たちの生涯において、これは経済的に最も大きな影響を与える可能性のある技術の波であり、人類にとって非常にポジティブな方法で実現されると考えています。それは生産性の向上によって、そしてはるかに多くの技術を創造することによって実現されるでしょう。私の考えでは、これらすべての技術は、以前は不可能だったこと、非常に高価だったこと、非常に困難だったことを、はるかにアクセスしやすいものにするでしょう。私はそのことを強く信じています。
もちろん、この種の技術進化があると、多くの誇大広告も生まれてしまいます。資金提供を受けたり創造されたりしているアイデアのすべてが素晴らしいアイデアというわけではないかもしれません。でも、それも長期的には悪いことではないと思います。影響は現実のものであり、良いソリューションと良いアイデアが勝ち残っていくでしょう。
現在地について言えば、私たちはまだAIの指数関数的な改善曲線の中にいると信じています。モデルは大幅に改善し続けています。というのも、おそらく数ヶ月前、昨年末頃だったと思いますが、モデルの改善が停滞しているのではないかという懸念がありました。しかし、それは起こりませんでした。実際、モデルは加速し続け、より良くなっています。
また、この12ヶ月間で、非常に効果的なエージェント型ソリューションの開発が見られました。特にソフトウェアとコーディングにおいて、その影響は現実的で非常に目に見えるものです。2年前には、コーディングでAIを使っている人は事実上誰もいませんでした。それがGitHub Copilotによって、誰もが使い始めるようになりました。そして過去12ヶ月間、エージェントの支援なしにコードを書いている人は実質的にいなくなりました。2026年には、このパラダイムがソフトウェアの他の部分や他の業界にも現れ始めると思います。カスタマーサービスや他の多くのビジネスプロセス自動化においてすでに見られています。もちろん、AIの消費者としての私たち自身の個人生活への影響も大きなものになるでしょう。
コード領域におけるAIの優位性とその理由
でも、コードについて話しましょう。コードはテキストであり、具体的な答えがあるものです。確率的なAIシステムにとって、いくつかのことを試して、うまくいくものを強化することができます。誰かが何かをプッシュすれば、それは良い仕事をしたという良い指標であり、もっとそうすべきだということになります。これらすべての他の種類の分野はもっとオープンエンドです。だから、もう少し時間がかかるだけなのでしょうか。そしておそらくそれがコードが最初だった理由ですが、もう少し時間がかかるのでしょうか。どのように進化していくと見ていますか。
それは非常に妥当な指摘です。モデルやエージェントを特定のドメインでタスクを実行する際にどのように改善できるかというと、明確な報酬関数を持つことが重要です。モデルやエージェントを訓練するための十分なケースがあることが必要です。コードの場合、誰かが製品を使用したときに非常に明確なシグナルを作る能力を作り出しました。しかし、私の考えでは、コードで起こったもう一つのことは、実際にモデルをコードで訓練することに加えて、利用可能なコードがたくさんあるため、基本的にはユーザーが使い始めるような製品、IDEを構築しました。答えが完璧でなくても使い始めたのです。
それによって、ユーザーが実際にこれらのことにどのように反応するかについて、はるかに多くのデータが生成され始めました。いつ変更を受け入れ、いつ受け入れないか。それ自体が非常に貴重なデータであり、データのフライホイールを作り出します。そしてそれが戻って、コードを生成する方法を改善することができるのです。
このパラダイムは他のドメインにも適用可能だと思います。まずは人間が運転席にいる、私たちの場合はエンジニアですが、そのツールがないときよりも速く、より良い作業方法であれば、このデータのフライホイールを作ることもできます。AIが行ったことが人間に受け入れられたかどうかについて、ある種の反応を本質的に得ることができます。そしてそれが次のサイクルでの改善と、時間の経過とともにはるかに多くの自動化を生み出すのです。
Resolve AIでの見方としては、エンジニアがResolve AIを使用する主な方法は、ソフトウェアに何か問題が起きたときに真夜中に起こされる代わりに、私たちをオンコールに配置することです。Resolveがトリアージとトラブルシューティングを行い、修復を提案します。私たちは、一般的な意味でより良くなるのに役立つ報酬関数やグラウンドトゥルースのようなものを作成する能力を生み出しました。しかし、おそらくもっと重要なのは、私たちが学習するパターンや、人間が持っているかもしれない知識を抽出するような、特定の組織に対してです。
そうですね。あなたが言及したこのオンコールの状況について話すべきだと思います。知らない人のために説明すると、テクノロジー企業にいる場合、通常は誰かが夜間や週末にオンコールになっています。何かがダウンした場合に修正するのがあなたの仕事です。これらの人々は、人々が目を覚ますときや週末に物事を使っているときでも、問題があったとしても解決できるように、多くの場合サービスを救ってきました。
問題は、企業にとってコストがかかり、エンジニアの生活の質を台無しにすることです。この苦しみを経験した多くの人々をあなたも知っていると思います。これは実際にAIコードで何が起こるかという問題です。なぜなら、AIコードについて私たちはすでに今日ここで話したように、AIはコード生成が得意だということを知っています。問題は、それを本番環境に投入すると、人々がそれを監視するためにより多くの仕事を作り出すだけだということです。
AIからROIを見つけることについて話すとき、これは本当に可能性を減少させると思います。なぜなら、一つのことに必要だった作業量を減らしましたが、今度は他の人々のために何倍もの新しい仕事を作り出したからです。これについてのあなたの見解と、どのように解決できるかについて少し話してください。
本番環境維持の課題とAIによる解決策
質問の導入から始めると、世界はソフトウェア上で動いており、このソフトウェアの背後には人々がいます。彼らはしばしば夜や週末をトラブルシューティングとソフトウェアの保守に費やし、そのソフトウェアの信頼性や可用性を確保しなければなりません。
さて、あなたの質問ですが、AIがコード生成において大きな影響力を持っていることは非常に明確です。しかし同時に、その後のステップに対処することなく、はるかに多くのコードを持つことは、企業にとって資産というよりもほとんど負債です。なぜなら、結局のところ、あなたがやりたいことは、技術をより速く創造することですが、同時にその技術を信頼性を持ってユーザーに提供できる方法で創造することだからです。ユーザーが誰であれ。
そして今、AIによって生成されたはるかに多くのコードを持つことに加えて、そのコードが本番環境に入ると、ソフトウェアエンジニアがそのコードのトラブルシューティング、保守、改善を行うことがより困難になっています。研究によると、AIが使用されるにつれて、新しい変更ごとに何かがうまくいかないインシデントがかなり増加したことが示されています。その上、私たちはおそらくAIが作成したコードにあまり精通していません。
私にとって、コードをもっと生産するだけでは、技術でより速く前進することはできません。実際、システムを確実に保守および実行する方法に対する信頼が低下するため、より速く前進することの妨げになる可能性があります。ですから、AIは必要だと思いますが、もちろん戻る道ではありません。このコードをすべて生成しないというのは答えではありません。
私にとっての答えは、より多くのAIです。しかし今度は、次のステップに適用されます。つまり、このコードがすべて生成されたら、実際に監視、保守、改善ができるモデルとエージェントが必要です。何かがうまくいかないときにトラブルシューティングができるようにです。そうすれば、全体が5倍、100倍速く動くことができるかもしれません。なぜなら、このプロセスで半分が5倍速く生成されても、次のステップが5倍速く動かなければ、実際には速度をそれほど改善していないからです。これがまさにResolveが焦点を当てている領域であり、現在の状態のためだけでなく、AIによって生成されたコードが大量にある状態に移行しているため、非常に大きな影響があると考えています。
わかりました。つまり、あなたは効果的にAIソリューションです。AIで生成されたコードである必要はありませんが、製品を稼働させ続けることに関するすべてのことについて、あなたは効果的に製品を構築しました。それはコードベースを調査し、エラーを探すのでしょうか。そして、それを修正する権限を持っているのでしょうか。
非常に良い質問です。なぜなら、コードをデプロイして本番システムで実行する際に起こるもう一つのことは、データに関してだけでなく、何かがうまくいかないことに関しても多くの敏感さがあるからです。人間はもちろんミスを犯すことがあり、課題や停止を引き起こすことがあります。サービスをダウンさせることもあります。しかし、AIも潜在的に同じことをする可能性があります。
私の見解では、私たちがこれを行う方法は、信頼に焦点を当てたAIを構築することによって行っています。ソフトウェアエンジニアやあらゆるドメインのオペレーターに対する信頼です。私がそれについて考える方法は、ほとんど自動運転車のようなものです。私たちは、人間のドライバーよりも優れた運転ができることをデータで証明されない限り、自動運転車を道路上に出させません。運転には異なるレベルの自動化もあります。
同じことがAIで多くのドメインで起こると思います。特にこの分野では確実に起こります。最初は、ほとんどの人がAIに作業を行わせ、調査を行い、発見と解決策が何であるかを報告させます。そして人間のエンジニアが決定しなければなりません。次のステップでは、AIがこれらのアクションのいくつかを自分で実行できるようになるかもしれません。それらがあまりリスクが高くないか、元に戻せる限りは。
そして最終的には、レベル5の自動運転のような状況に到達するでしょう。AIが人間には解決できない問題を解決でき、変更を行い、はるかに速く前進できるようになるべきです。それが本当に、はるかに多くの技術をはるかに迅速に構築することを可能にするものです。
マルチエージェントシステムの実装と課題
あなたのクライアントにとって、そのレベル5はどれくらい先だと思いますか。今のところ、私が正しく理解していれば、あなたのソフトウェアはエラーが発生したときに調査し、それを人にプッシュして、「これがおそらくそれだと思います」と言います。彼らはボタンを押して修正されるのでしょうか。それについて聞きたいのと、AIが「自分で入って修正します」というのはどれくらい先なのか知りたいです。
この質問には二つの側面があると思います。一つは、ソフトウェアエンジニアと同等かそれ以上になるためのAIの能力、つまり推論能力です。それを許可するための能力です。そしてもう一つは、いつAIにそのすべての作業をさせるかについての、コンプライアンスの枠組み全体です。何かがうまくいかないときに何が起こるか。私たちは両方を解決する必要があると思います。しかし、能力の観点から答えます。
私たちがまだ指数関数的な曲線上にいるときに未来を想像することは非常に難しいです。なぜなら、それは私たちの考え方や物事が改善する方法にとって非常に異常だからです。今日エージェントがコードの主要な生産者であるのと同じように、AIがソフトウェアの運転手になるまで、おそらく1年だと信じています。
1年後には、人間がより高いレベルの抽象化で動作し、まだAIを監督し、ほとんどの最終決定を行っているという同じ場所に移行すると思います。しかし、おそらく2〜3年後には、AIがこれらの決定のほとんどを行っている場所になり、人間は高レベルの決定フレームワークやタスクをAIに委任することになるでしょう。ですから、レベル5を予測するのは難しいかもしれませんが、その下のレベルはおそらく次の2年間で起こるでしょう。
わかりました。あなたは指数関数的だと言いましたね。明らかに物事は本当に速く動いています。実際、指数関数的という言葉はおそらくAI業界の誰もが最も好きな言葉で、最近の進み方を考えると責めることはできないと思います。
しかし、モデルはすべてコモディティ化しており、平準化して飽和しているという理論がありました。では、次の利益はどこから来るのでしょうか。あなたはこれについて尋ねるのに最適な人だと思います。なぜなら、あなたは本当に難しい問題、本当に骨のある問題に取り組んでいるからです。
単にモデルをコードベースに投げつけて、「おそらくこれです」というような標準的なインスタント応答では対処できないと思います。おそらくあなたは、複数のモデルを実行して互いの作業をチェックするようなオーケストレーションに深く関わっていると想像します。
あなたの直接の経験について聞きたいです。それがどのように機能しているか。そして、指数関数的な進歩が現在のように続くと思うか、あるいはこの指数関数的な進歩が続くとすれば、このような方法で行われると思うかどうか。より大きなモデルではなく、それも一部かもしれませんが、複数のモデルと複数の異なるプログラムを取り、それらに作業をチェックさせ、互いに構築させるということです。
基盤モデルは非常に速いペースでコストを抑えて改善し続けると信じています。より多くのデータとおそらくアルゴリズム的にできることはもっとあると思いますが、それだけが方法ではありません。おそらくそれが今のところ最も改善する方法ですが、アプリケーション層もここでかなり重要だと思います。
アプリケーション層とは、単にアプリケーションを構築することを意味するのではなく、ドメインを取り入れてモデルにも追加することを意味します。一般的に言えば、時々AIがビジネスにそれほど大きな影響を与えなかった理由の一つは、モデルは誰もがアクセスできるものですが、ドメインやビジネスの詳細を理解するために深く入り込んだアプリケーションがそれほど多くないからだと信じています。
ほとんどの製品は、ラストマイルの扱い方において少し薄いと言えます。非常に成功するためには、多くの例を見てきましたが、製品やモデルに多くの知識、詳細、部族的な知識や組織的な知識を組み込む必要があると信じています。そして、それが次に起こる必要があることだと思います。
私たちのドメインでそれを行う方法は、まず、ソフトウェアエンジニア自身が使用できるツールを使用できるマルチエージェントシステムを構築する必要があります。なぜなら、今日の世界はそのように見えるからです。世界はエージェント用に構築されていませんでした。エージェント用に構築された新しいツールセットに移行するまで、人間のツールを使用できる必要があります。
それから、人間と非常にうまく協力できる必要があります。エージェントは人間に対して適切なインターフェースを持っている必要があります。そして、これらの環境に存在する多くの知識を発見できる必要があります。その知識は多くの場合、文書に書かれているかもしれません。時には文書は古くて間違っているかもしれません。しかし、それは多くの場合、人間の心の中にあり、AIは人間と協力しなければなりません。そうすれば、時間の経過とともに彼らから学びます。
これには、異なるエージェントがおそらく異なる責任を持つマルチエージェントシステムが本当に必要です。作業をどのように行うか、ツールをどのように使用するか、互いにどのように調整するか、そしてエンジニアとどのようにコミュニケーションするか。これが非常に困難な理由です。なぜなら、それは単にモデルの問題ではないからです。
それはマルチエージェントのオーケストレーション、計画、推論の問題です。多くの場合、エージェントが実行しなければならないステップが非常に多く、時には数百にもなります。そのため、コンテキストが不足し、多くのモデルの問題にも直面し始めます。
一歩下がって考えると、少なくとも私たちのドメインで起こることは、他のドメインにも一般化できると思いますが、ドメインをよく理解し、顧客のコンテキストをよく理解する深いエージェント型アプリケーションを構築する必要があるということです。その多くをモデルにもっと多くのイノベーションをプッシュする必要があります。はるかに多くのデータ、はるかに多くのコンテキストを扱うことができ、はるかに長いタスク、長期的なタスクと呼ばれるものを計画して推論できるようにするためです。時々、モデルは自分が何をしようとしているのか見失ってしまうことがあります。
でもこれについて話させてください。マルチエージェントシステムが何をすることになっているかは理解していますが、一つのエージェントが壊れたら、全体が停止するのではないかと想像します。では、一つのことをやらせようとするチャットボットが時々課題になるのに、どうやってマルチエージェントのプロセスやワークフローを機能させているのか、少し話してもらえますか。非常に難しい問題のように思えます。
はい。まず、例を使って説明しましょう。二つのエージェントが協力しなければならないとします。一つのエージェントは文書を理解し、もう一つのエージェントはコードベースにアクションを実行してタスクを実行します。
これら二つのエージェントがいて、多くの場合は二つ以上、五つや十あるかもしれませんが、実行したい計画を考え出さなければなりません。彼らの間で作業をどのように調整するか。そして彼らは本質的に作業を行い、互いに学んだことをコミュニケートし合わなければなりません。
これを確実に行うためには、多くの層のガードレールが必要だと思います。ガードレールという意味は、モデルやエージェントに何か間違ったことをさせないという意味でのガードレールではありませんが、多くの場合、あるエージェントに作業をさせ、別のエージェントがその作業をレビューしてフィードバックを提供し、最初のエージェントに反復させます。
そして、それが複数のエージェントに広がると、おそらく全員が作業を行い、私たちの場合、エージェントがインシデントを調査し、何が起こったか、どう修正するかの分析を生成するような結果を生み出します。その後、別のエージェントにその作業をレビューさせ、推論に何か穴があれば最初のエージェントに戻って作業をやり直させます。
ですから、非常に信頼性の高いシステムを実際に生産できるようにするために、制御とチェックと検証の観点から多くのものを重ねる必要があると言えます。そして、時間の経過とともに起こるもう一つのことは、何が機能するかについてはるかに多くのデータを収集することです。何かを行う順序で、それがうまくいくわけです。
先ほど話したグラウンドトゥルースと報酬関数についての議論に戻ります。ですから、これらのような軌跡と呼ばれる、作業が成功裏に行われた方法のものが多ければ多いほど、モデルに戻ってモデルを改善することができます。そうすれば、アプリケーション層でより困難な問題を解決するためのはるかに多くの余地が得られます。
真ん中にオーケストレーターがいて、これらの異なるボットを派遣し、それから戻ってきて作業を見せ、物事が良い状態にあることを確認するための必要なチェックをするのを助けるのですね。
効果的には、マネージャーがいて、他のエージェントを管理するエージェントがいて、決定を下し、彼らに何を伝えるか、また手元のタスクに応じて何を伝えないかを決定して、彼らを混乱させないようにします。そしてそのエージェント自体が自分の作業をチェックしますが、スポットチェックや作業の検証も行うスーパーバイザーのようなものが別にいるかもしれません。ですから、多くのそのような委任とチェックがあります。
モデル選択とドメイン特化の未来
素晴らしいですね。あなた方が考え出したもの、人々がこれらのシステムで考え出すものは本当に驚くべきものです。質問させてください。オーケストレーターには、より賢いモデルが必要ですか。基盤となる最も賢いモデルをオーケストレーターとして使い、それから、これらの他のことのいくつかを行うために、より専門的な、あるいは少し愚かなオープンソースモデルを送り出すのでしょうか。
はい、それは妥当です。なぜなら、考えてみれば、特定のタスクで1ステップか2ステップかかる場合、多くの推論を必要としないモデル、または長い一連のタスクのために推論する必要がないモデルで十分です。しかし、多くのエージェントにわたって、そして多くのステップにわたって計画しなければならない何かがある場合、通常、推論の観点から最も能力のあるモデルが必要です。つまり、通常は非常に大きなモデルで、おそらくクローズドなプロプライエタリモデルです。
興味深いですね。それがあなたが持っているミックスなのですね。
はい。そしてある意味では、一般化すると、トップレベルでは通常、最も能力のあるモデルを持ち、通常は最も高価で最大のモデルです。そして、基礎となるタスクは、おそらく高速なクローズドソースモデルか、タスク用にポストトレーニングするオープンソースモデルによって実行できます。
そして長期的に考えると、特定のドメインについて、非常にうまく推論できる専門的な大規模モデルがあり、それがそれを行う会社によって所有されるのか、それとも現在の状況のように、ドメイン間で適用されるこれらの水平モデルを持つ状況になるのか、という疑問になるかもしれません。
正直なところ、どう思いますか。確信はありませんが、私の直感では、ソフトウェアのような大きなドメインやカスタマーサービスなど、経済的に大きな影響があるため、ドメイン特化型で非常に優れたモデルに投資することは理にかなっていると思います。ゼロから始める必要はないと思います。より大きなモデルに存在するすべての機能を取り入れますが、そのドメインで最も能力のあるモデルは、ドメイン特化型のモデルになるという状況になると思います。
それは本当に興味深いですね。さて、ここで文化について少し話しましょう。これらのツールは非常に速く、激しくやってきました。よく聞くことの一つは、モデルができることよりも人々が活用していないという能力オーバーハングのようなものがあるということです。人々はGPT 5.2にGPT-3に尋ねていたのと同じ質問をしています。
あなたの視点から少し話してください。あなたはエンジニアと仕事をしているので、これらの人々は一般的にテクノロジーができることを理解しています。このようなものを採用することへの興味はどのようなものでしたか。そして、もし私たちがこのAIシステムを使ったら、問題があったときに確実に稼働し続けるなら、私たちはどうするのか、というようなことはありましたか。
これは妥当な質問であり懸念です。さて、エンジニアはおそらく見つけることができる最も早い採用者だと思います。ですから、それは一般的に、コーディングのためにAIが広く採用されること、そして今ではソフトウェアエンジニアリングの後続のステップ、Resolve AIの採用で私たち自身が見ているようなことを助けました。
しかし、時には二つのことが起こっています。変化に対する自然な抵抗があります。人間が習慣を非常に迅速に変えることは難しく、異なる性格を持つ異なる人々が時には変化に対してより抵抗があります。ですから、それは間違いなく問題です。そして、時には人々の仕事についての懸念があります。
さて、これについての私の見解は次のとおりです。特にソフトウェアエンジニアリングでは、世界で最も高給取りの専門家の一部であり、より多くの技術を生産することによって、最終的な状態がソフトウェアエンジニアが少なくなるような状態になるとは思いません。
また、これは私の意見では最適化式ではありません。これらの高給取りの人々が多いか少ないかはほとんど問題ではありません。私たちが最適化すべきは、最終的に全世界に利益をもたらす技術をはるかに速く生産できるかどうかだと思います。より困難な問題を解決するか、今日では高すぎる可能性のある問題を解決することによって。その意味で、はい、私たちはこの抵抗を押し通す必要があります。なぜなら、最終目標は誰にとっても有益だと本当に思うからです。
エンジニアリングの未来と抽象化レベルの進化
エンジニアと話すとき、私たちはこのようなことについて素晴らしい会話をします。エンジニアと話すと、未来がどのようになるかについての感覚を得ることができます。なぜなら、彼らは指先に最もツールを持っているからです。彼らはあなたに、「ああ、これはここでうまくいっている」とか「これは私にこのような効果を与えている」とか「私たちはオフィスでこれをやっている」とか「これを完了できなかった」と教えてくれます。
私が聞いたことの一つは、人々が考えているのは、もしコーディングがAIに引き渡されたら、人々はコーディングする能力を失うだろうということです。そして、何かが壊れるまでは問題ありません。それで私はいつも、エンジニアは効果的にAIが生産したコードの監査者と修復者になるのではないかと思っていました。
そして繰り返しますが、私たちはAIのためにはるかに多くのコードを持っていることについて話しています。そしてあなたは、テクノロジー自体でその監査と修復を助けるソリューションを構築しました。それでは、これがあなたが予想する方法で機能するとしたら、エンジニアリングスキルの最終状態はどうなると思いますか。
AIが十分に良い仕事をすれば、エンジニアがそれらのスキルの一部を衰退させるリスクがあると思いますか。
すべての技術進化と同様に、明らかに私たちは人間として、結果をはるかに速く生み出すための多くのレバレッジを得ます。私たちは他のドメインで機械を使用することに抵抗していません。同じことがソフトウェアにも当てはまると思います。
ソフトウェアは過去50年間で、マシン自体のための非常に低レベルのコーディングから、オペレーティングシステムや高レベル言語を使った異なる抽象化レイヤーに移行しました。AIは単なる別の抽象化だと思います。
そして、この答えや懸念は、人間やエンジニアがコードを生産または実行するすべてのスキルを衰退させるかどうかではないと思います。本当の答えは、両方の部分を非常にうまく行うエージェントを生産すべきだということです。彼らは非常に迅速にコードを生産すべきですが、同じ方法でコードの実行、保守、改善、トラブルシューティングもできるべきです。
エンジニアは今すぐに、私の意見では、より高いレベルの抽象化で動作するようになり、すぐになるでしょう。彼らは、使用できるツールの低レベルの特定の、特注のようなものについても多くの心配をする必要がなくなります。クエリ言語や、答えを得るためにこのAPIやCLIをどのように正確に呼び出すべきかというようなことです。
このような重労働でストレスの多い作業はすべてAIによって行われ、私たちはその上のレベルで動作することになります。私はそれが望ましいことだと思いますし、リスクや懸念だとは思いません。
実際の使用例と導入事例
わかりました。最後の質問です。AIがコードベースを監視し、修正が必要なときに企業に警告できることについてたくさん話してきました。あなたのAIはその修正を提案できるかもしれません。日常的な使用例を一つ、具体的に聞きたいです。これが本当にうまく機能したケースを聞きたいです。
エンジニアを起こしたかもしれませんが、彼らはボタンを押して物事を修正することができたような例です。企業名や製品の具体的な名前などを使って、例を教えてもらえますか。
はい、100パーセント。Resolveの私たち自身のエンジニアは、真夜中に目を覚ますけれども、実際にラップトップに行く必要がないという多くの話を社内で共有しています。彼らは携帯電話を見て、Resolveが言っていることを見て、それから眠りに戻ります。これは多くの顧客から聞きました。
しかし、実際の世界では、Coinbase、DoorDash、Salesforceのような顧客がいます。最初の二つは、誰もが日常的に使用している消費者向け企業です。変更が起こり、誰かが新しい機能を開発しようとして、本番環境に新しいコードをプッシュすることは珍しくありません。それが意図しない結果を引き起こし、多くの層がエンドユーザーにエラーを生成することになります。
Resolveが行うことは、ユーザーがエラーを見ているようなエラーから始めるか、何か問題があるかを特定します。すべてをトラバースし、インフラストラクチャのパスを歩き、これが特定のアプリケーションやサービスから起こっていることを把握します。すべてのエラーをレビューし、エラーを新しいチェーンに接続します。問題を引き起こしている作成されたコードを見に行って、基本的にサイクル全体を説明します。
そして、このコードの変更を実際に元に戻す必要があると伝えるかもしれません。そうすれば、すべてがうまくいき、正常に戻ります。
わかりました、Spiros。通常、このインタビューの最後に、どこで見つけられるかをゲストに尋ねますが、それはあなたのスウェットシャツに書いてあります。resolve.aiですね。それがURLですよね。
その通りです。resolve.aiです。
わかりました。皆さん、もっと知りたい場合は、resolve.aiをチェックしてください。Spiros、これは私たちの最初の会話でした。あなたを知る機会を得られて素晴らしかったです。また話せることを願っています。
ありがとう、Alex。同じく。
それでは皆さん、見てくれてありがとうございました。また次回お会いしましょう。
コメント