AIの嘘を終わらせた開発スタック

無料のAIコーディング支援には、ほとんどのチームが予算に計上しない項目が付随します。それは、決して動くことのなかったコードを解読するのに失われる時間です。Reactフックを生成するのに30秒節約できても、APIが昨年変更されていたことを発見するのに2時間を費やし、あなたの「アシスタント」がその情報を把握していなかったという状況が巻き起こります。この自信に満ちた出力と現実とのギャップが、真のコストが隠れているところです。

開発者でツール職人のロビン・エバーズは、これを率直に「古いコードは非常に高価だ」と表現しています。AIがあなたにStripe、Next.js、またはAWSの壊れた統合を提供する時、あなたは単に文法を修正しているのではなく、そのモデルのトレーニングカットオフ以来に何が変わったのかを逆エンジニアリングしています。文書と幻のスニペットを比較するのに費やす一分一秒は、あなたがアウトソーシングしていると思っていた生産性を奪っていきます。

現代のLLMには、モデルカットオフ日という組み込まれたハンディキャップがあります。これは、知識が数ヶ月または数年前の状態で固定されてしまうものです。Next.js、React、FastAPIのようなフレームワークは、6〜12週間ごとに大きな変更を行います。AWS、Google Cloud、OpenAIからのクラウドAPIはさらに早く進化し、パラメータを廃止したり、メソッドの名前を変更したり、認証フローを変更したりしますが、あなたのモデルは時間に取り残されたままです。

その不一致により、AIアシスタントは迅速に進化するスタックに対して信頼性のない語り手となります。Stripe Checkoutの例を求めると、2022年のAPIが返され、非推奨のフィールドも含まれているかもしれません。GitHub REST APIに呼びかけると、モデルは自信を持って存在しないエンドポイントや、そのカットオフ後に変更されたスコープを要求するエンドポイントを推奨するかもしれません。コードは妥当に見え、クリーンにコンパイルされますが、製品環境で静かに失敗します。

今日のほとんどのアドバイスは、より良いプロンプトでこれを覆い隠そうとしています。「ダブルチェックを依頼してみてください」「ドキュメントと照らし合わせて確認するように言ってください」「バージョンについて具体的にしてください」といった具合です。それは開発者に再び負担をかけ、彼らはスキーマを設計するのと同じくらい慎重にプロンプトを設計しなければならなくなります。それでも、最初に推測し、時々しか自分の仕事を確認しないシステムに依存しているのです。

エバースの仕事は、異なる答えを示唆しています。それは、プロンプトだけでなく開発スタックを変更し、モデルが現実にぶつかることなくAPIについて嘘をつけないようにすることです。

幻覚は神秘的に聞こえますが、開発者にとっては、あなたのアシスタントがどこでも動作しなかったコードを自信を持って返すことを意味します。大規模言語モデルは、トレーニングデータのパターンに基づいて次のトークンを予測しますが、ライブコンパイラやランタイムに基づいているわけではありません。そのデータがカットオフ日で凍結すると、AIは想像の中だけに存在するメソッド、パラメータ、設定フラグを喜んで作り出します。

今日、Stripe API統合を依頼すると、静的モデルは数年前に廃止されたv2スタイルの呼び出しを提案することがあります。OpenAIクライアントの例をリクエストすると、今では400エラーを引き起こす2023年以前の署名を使用するかもしれません。そのモデルは自分が間違っているとは認識しておらず、真実ではなく妥当性を最適化しています。

開発者はしばしば、チャットに一般的なウェブ検索を追加してこの問題を修正しようとします。それは通常、信頼を失った同じSEOが詰まったブログ投稿や2019年のStack Overflowのスレッドをスクレイピングすることを意味します。結果として得られるのは、jQuery時代のReactパターンや、`componentWillReceiveProps`の例、あるいはクラスターのバージョンよりも古いKubernetesのYAMLです。

検索エンジンはクリック数の最適化を行い、真実の文書には最適化していません。彼らは順位の高いコンテンツを表面化し、実際に使用しているライブラリの `v4.2.1` に対して正確なコンテンツを提供していません。あなたのAIはその混乱を要約し、古いアドバイスを新しい形式のナンセンスに変えてしまいます。

あなたが本当に必要なのは、三種類の情報を分けられるシステムです。一般的な背景、コミュニティの例、そして権威ある仕様です。一般的な文脈はブログやQ&Aから得られます。例はコード検索から得られることがあります。しかし、署名、フラグ、または動作が重要なときには、モデルは公式ドキュメントや型付きSDKにアクセスする必要があります。

静的なLLMは世界のスナップショットに存在しますが、ソフトウェアは週単位でリリースを行います。React、Next.js、Stripe、OpenAI、AWS、Kubernetesは、最も人気のあるモデルのトレーニングカットオフ後に重要な変更を出荷しました。このギャップは、あなたのAIが「知っている」ことと、実際のツールチェーンが行っていることの間にずれを生じさせます。

最新の情報源（APIリファレンス、変更ログ、移行ガイド）に質問をルーティングする方法がなければ、確率的なテキストジェネレーターにライブデバッガーのように振る舞わせることになります。これが、何時間ものデバッグや説明のない500エラーに対して「無料」のコードに対価を支払うことにつながるのです。

プロンプトエンジニアリングは、モデルを芸術的なコラボレーターのように扱います。一方、ツールオーケストレーションは、作業手順書に従う従業員のように扱います。巧妙なプロンプトでお願いするのをやめ、モデルが無視できない厳格なルールを環境に組み込むことを始めます。

Cursorの「常に適用」ルールは、そのスイッチを切り替えます。チャットに埋もれた臨時の指示の代わりに、あなたは常設の命令を定義します：すべてのリクエストはスクリプト化されたリサーチワークフローを通過しなければなりません。このルールは、モデルが気まぐれなチャットボットではなく、決定論的なエージェントのように振る舞うために、文脈、制約、厳格なツールの優先順位を注入します。

ロビン・エバーズの設定は、これがどれほど攻撃的になり得るかを示しています。彼のルールは、カーソルに対してほぼすべての場面でExa MCPを優先させるもので、Exaは「大抵の場合、十分に良い」上に「公式ドキュメントを調べるよりもずっと安い」ためです。Exa内では、新しい「コードコンテキスト」ツールが一般的なウェブ検索の前に実行されなければなりません。

そのチェーンが失敗した後にのみ、スタックがエスカレートします。ウェブ検索は二次的な選択肢として解除され、公式文書のための Ref MCP は最後に位置し、以下の三つの条件によって制限されます： - ユーザーが明示的にRefを要求したとき - Exaの結果が互いに矛盾する場合 - カットオフ後に文書が変更される可能性が高い外部APIやライブラリの修正に二度失敗した後

その条件はガードレールであり、提案ではありません。モデルは「雰囲気」を合わせることで答えに辿り着くことはできず、毎回同じ再現可能な研究の道を歩む必要があります。これにより幻覚を大幅に減少させ、コストを予測可能に保ちます。結果として、デバッグや洗練ができるワークフローが得られ、時々賢く感じるブラックボックスではなくなります。

裏側では、これはすべてモデルコンテキストプロトコル（MCP）によって動いており、LLMをExaやRefなどの外部ツールとクリーンに接続します。MCPは、モデルがツールを発見し、呼び出し、連鎖させる方法を標準化しており、モデルコンテキストプロトコル - 公式ドキュメントは、マーケティングよりもLLMを実際のエージェントに変えるための仕様のように読めます。

あなたの新しいスタックは、Exa MCP と Ref MCP の2つのMCPサーバーを直接エディタに接続しています。モデルに「どうかドキュメントを使ってください」と頼むのではなく、どのツールがいつ、なぜ実行されるかを決めるリサーチ戦略をハードコーディングします。

Exaはホットパスに座っています。ロビン・エーバースは、モデルが常にExaを最初に優先するようにCursorを設定します。なぜなら、それはほとんどの場合「十分良い」し、あらゆる質問に対して公式ドキュメントを叩くよりも「はるかに安い」からです。

Exaの内部では、新しいコードコンテキストツールが主要な作業を担っています。このモデルは、一般的なウェブ検索の前にその特定のツールを呼び出し、実際に使用しているライブラリやパターンに合わせたコード関連のスニペット、例、ディスカッションを引き出します。

Exaを、Stack Overflow、GitHubのイシュー、ブログ投稿に精通した優秀なジュニア開発者と考えてください。質問をすると、三つの実現可能なアプローチ、最近のコードサンプル、そしてバージョン5.2と5.3の違いについての大まかな理解が返ってきます。

Ref MCPは対照的な役割を果たします：より遅く、より高価で、はるかに権威的です。RefはAPIやライブラリの公式かつ最新のドキュメントに直接接続し、モデルの学習データのカットオフがあなたを妨げていると疑うときのファクトチェックレイヤーとして機能します。

ロビンのルールは、以下の3つのケースでのみRefを許可します： - ユーザーが明示的にRefを求めた場合 - Exaの結果が相反する場合 - ドキュメントが変更されている可能性のある外部APIやライブラリの修正に2回失敗した後

そのエスカレーションパスによって、Refはジュニア開発者の推測が成功しなくなると、公式APIリファレンスを開くことと同等になります。現実の世界で何かが動いたという具体的な証拠が出るまで、フルテキストのドキュメントにトークンを無駄にすることはありません。

Exa plus Refは、経験豊富なエンジニアが実際に働く方法を反映した二層のリサーチシステムを構築します。80％の問題に対してはコミュニティの知恵を活用し、バージョン番号、認証フロー、または重要な変更が重要になるときに標準的な文書に移行します。

モデルが2023年のnpmのスナップショットから「おそらく正しい」コードを想像する代わりに、あなたは指向されたパイプラインを手に入れます。Exaは安価でコードを意識したコンテキストを見つけ、Refはあなたのビルドが通過するか、さらに2時間無駄になるかを決定する正確なメソッド名、パラメーター、およびエッジケースを確認します。

このスタックの優先順位は非常にシンプルです：毎回、Cursorに最初にExaを使用するよう指示します。ロビン・エバースは「常に適用」ルールを設定し、モデルが厳密な階層に従うようにしています：1) コードコンテキストのためのExa、2) ウェブ検索のためのExa、3) 特定のトリガーに対してのみRef。モデルは自分のツールの順序を自由に設定することはありません。

Exaの内部では、新しい「コードコンテキスト」ツールが主役です。カーソルはモデルに対して、一般的な検索の前にそれを呼び出すよう指示します。これにより、AIはあなたのスタック、フレームワーク、最近の問題に一致するコード関連の結果を確認します。その特化したコンテキストが失敗した場合のみ、より広範なウェブ結果に戻ります。

この優先順位は経済的であると同時に技術的です。エクサは「ほとんどの場面で十分良い」と「リファレンスMCPや一般的なウェブ検索を使ってすべての質問を解決するよりもはるかに安価」です。ネットワークコールやレイテンシーに対しては支払いますが、モデルが不良コードを生成して2時間デバッグに費やすと、はるかに多くのコストがかかります。

専門的で安価なツールから始めることは、幻覚を抑えることにもつながります。カーソルが最初にエクサのコードコンテキストを強制すると、モデルは実際のリポジトリ、最近のギスト、および具体的な使用パターンを見ることができ、その後に推測します。それだけで「このAPIは…のように動作すると思う」といった虚構の大多数を排除します。

Ref MCPは、コストの高いエスカレーションとしてチェーンの最終段階に位置しています。カーソルは、次のいずれかの条件が発生した場合にのみRefを許可します： - ユーザーが明示的にRefを要求する - Exaの結果が互いに矛盾している - 外部APIやライブラリの修正に対する2回の失敗がカットオフ後の文書変更を示唆している

そのガードレールは、AIが単純でコード特有の答えを持つ問題に対して、高価で一般的なドキュメント検索にデフォルトするのを防ぎます。Exaのコードコンテキストが、人気のあるSDKにおける`fetch`の挙動を教えてくれるなら、ベンダーのドキュメントを完全に調べる必要はありません。現実とモデルの以前の情報が衝突する場合のみ、エスカレーションが必要です。

Cursorでは、そのロジックは小さくて無情なポリシーレイヤーのように見えます。ルールの擬似コードは次のようになるかもしれません:

{ "alwaysApply": true, "priority": [ "exa.code_context", "exa.web_search", "ref.docs" ], "usagePolicy": { "ref.docs": { "allowedWhen": [ "user_explicitly_requests", "exa_results_conflict", "after_two_failed_external_api_fixes" ] } } }

Refは、3つの厳しい「ガラスを割る」条件のいずれかを満たしたときにのみ出てきます。それ以外のすべてはExaで実行されるため、速くて「はるかに安い」とロビン・エバースが強調しています。Refは公式ドキュメントへの緊急ラインとして扱い、別の検索タブではないと考えてください。

最初のトリガー: 明示的なユーザーのリクエスト。開発者が「use ref」と入力するか、公式ドキュメントを明確に求める場合、スタックは直ちにRef MCPを呼び出さなければなりません。これにより、高コストまたはレイテンシのある処理を不透明なエージェントロジックの背後に隠すのではなく、人間がコストとレイテンシを管理することができます。

第二のトリガー：Exaは自己矛盾します。もしあるExaの結果がv4でメソッドが非推奨であると示し、別の結果がv5でそれを推奨パスとして示した場合、システムはその矛盾を指摘します。その時点で、Refが決定権を持ち、ベンダーの公式文書を参照してモデルがどの回答が現実と一致するのかを推測するのを止めます。

第3のトリガーはモデルのカットオフ意識を実行します。AIが外部APIまたはライブラリの問題を疑い、二度修正を試みて失敗した場合、トレーニング以来世界が変わったと仮定します。失敗した二度の試みの後のみ、そのルールはパッケージ、SDK、またはRESTエンドポイントの最新の公式ドキュメントを取得するためのRefコールを許可します。

これらの三つの条件は、「モデルはおそらく古くなっている」という漠然とした不安を具体的なワークフローに変えます。モデルは永遠に静かにランダムな修正を強引に適用することはできず、Exaを使って迅速に成功するか、厳格なルールの下でRefを通じてエスカレーションしなければなりません。この構造により、幻想的な移行ガイドや無効な設定フラグに対して午後を無駄にするリスクが大幅に削減されます。

このスタックをCursorで再現したい開発者は、Exa MCPとRef MCPにおけるツール使用を管理する「常に適用」ルールにトリガーを設定します。その背後では、モデルコンテキストプロトコルの上にデターミニスティックなオーケストレーションがあります。より詳細な実装情報については、モデルコンテキストプロトコル - GitHubリポジトリに、ツールの登録方法、優先順位の強制、正式なドキュメントへの最終手段としてRefを保持する方法が記載されています。

コストの話は通常、クラウド請求書が届いてから行われますが、午前1時に壊れたStripeの統合をデバッグしているときには行われません。ロビン・エバーズはそれをひっくり返します：Exaは「はるかに安い」ので、コストはワークフローの設計において重要な要素となり、後回しにされることはありません。MCPスタックは、Exaのコードコンテキストツールをデフォルトとし、絶対に必要なときのみエスカレーションすることで、そのバイアスをデフォルトで組み込んでいます。

Exa + Refを単なる精度のパッチとしてではなく、財務制御プレーンとして扱いましょう。すべてのRef呼び出しは公式文書を引き出し、迅速なExa MCPクエリに比べて、トークン、レイテンシ、ツール使用料を多く消費します。Cursorの「常に適用」ルールに優先ルールを直接組み込むことで、Robinはアシスタントに予算ポリシーをハードコーディングしています。

失敗した試みは、お金が静かに消えていく場所です。幻の解決策は以下を意味します：- バグを再説明するための追加のLLM呼び出し - より多くのExaやウェブ検索 - 最終的にカットオフの問題を疑ったときの潜在的な参照検索

リトライを半分に減らすことで、トークン使用量、ツール呼び出し、開発時間を一度に削減できます。Refに触れる前の二回の失敗は、単なる品質ゲートではなく、コストを抑える手段です。

インテリジェントなツールのルーティングは、あなたの財布にとってのレートリミティングの一形態となります。80〜90%の質問をExaのコードコンテキストを通じてルーティングし、ウェブ検索に頼るのは稀にし、3つの「ブレークグラス」トリガー用にRefを温存します。その結果、シニアエンジニアのように振る舞うシステムが出来上がります：まずは迅速な推測を行い、矛盾やAPIのずれが要求される場合にのみ高価な研究を行います。

ほとんどのAIワークフローはモデルの選択に執着し、このレイヤーを完全に無視しています。MCPスタックは、持続可能なAIコーディングがGPT-4対Claudeの選択よりも、誰が最初に回答するか、何度リトライするか、そしていつエスカレートできるかに関するものであることを示しています。

Reactで小さなダッシュボードを構築していて、AIの提案に従って`componentWillReceiveProps`を使用してpropsをstateに同期させることにしました。コードを貼り付けて保存を押すと、ターミナルが鮮やかな赤い警告で明るくなります：このライフサイクルメソッドは非推奨であり、React 18では無視されます。あなたの「無料」のAI助手が、地雷を手渡したようです。

ロビン・エバーズのExa-firstルールの下で、モデルの最初の動きは推測をしないことです。カーソルはExa MCPのコードコンテキストツールを通じてエラーをルーティングし、現代のReactにおけるプロップの変更をどのように扱うかの最近の例を求めます。Exaはさまざまなチュートリアルを返します：1つは`UNSAFE_componentWillReceiveProps`を推奨し、別の1つは`getDerivedStateFromProps`を押し、3つ目は「フックを使えばいい」と言います。

AIは最も人気がありそうなものを選びます：`UNSAFE_componentWillReceiveProps`を使用したクラスコンポーネントのリファクタリング。再度実行します。Reactはコンパイルされますが、状態の更新が失敗し、新たな警告が表示されます。このメソッドは古いものであり、避けるべきです。2回の試行が終わっても、ターミナルはまだ壊れたままで、AIへの信頼は下がる一方です。

ちょうどその時に「二度の不成功な試み」トリガーが発動します。カーソルルールは現在、高価なRef MCPパスを許可しています。さらにブログ投稿をスクレイピングするのではなく、モデルは非常に特定のクエリを用いてRefを呼び出します：「プロップの変更に対応するための現在のReact 18+公式ドキュメント; クラスコンポーネントvs関数コンポーネント; 推奨API。」

Refは公式のreact.devドキュメントにアクセスし、標準的なガイダンスを提供します：`componentWillReceiveProps`やその`UNSAFE_`バリアントのようなクラスライフサイクルメソッドは廃止されており、新しいコードは`useEffect`を使った関数コンポーネントを推奨します。「Effectsとの同期」ページから最新のシグネチャと依存配列に関する注意事項を含む正確なコードスニペットを提示します。

それを活用して、AIはあなたのコンポーネントを関数として書き換えます：

• 1プロップはJSXに直接流れ込む
• 2ローカルで派生した状態は `useState` を使用します。
• 3関連するプロパティにキーを付けた `useEffect` 内の副作用

新しいコードを貼り付けてアプリを実行すると、警告が消えます。非推奨の呼び出しも、幽霊のライフサイクルメソッドも、2018年のブログからの古いパターンもありません。Exaが安価で広範な検索を処理し、Refはモデルが自己解決できない可能性のあるカットオフ後のAPIの変更を証明した後に介入しました。

決定論的エージェントが静かにおしゃべりなコパイロットを置き換えています。単一のモデルがコードベースの中で推測をするのではなく、特定のタスクに特化した専門的MCPが用意されるようになりました：検索、ドキュメント、課題、リポジトリ、さらにはデプロイメントまで。

ロビン・エバースのExa + Refスタックは、そのアーキテクチャのほんの一部に過ぎません。Exaは検索リクエストの90〜95％を処理し、Refは公式な文書のための厳格な「ガラスを割る」ポリシーの背後に位置しており、かつての感覚に基づいたプロンプティングを予測可能なリサーチパイプラインに変えています。

ズームアウトすると、彼の他のMCPでも同じパターンが見えてきます。GitHub MCPは「問題について話す」わけではなく、それを取得し、PRをリンクし、失敗を特定のコミットにマッピングします。コードコンテキストMCPはあなたのリポジトリを要約するのではなく、具体的なファイル、シンボル、コールグラフをモデルの作業メモリに読み込みます。

一つの巨大なチャットボットの代わりに、狭く決定的なツールのメッシュが得られます。各MCPは小さく型が定義されたインターフェースを持ち、「このコードを検索」「その問題を引っ張る」「これらのドキュメントを取得」などの操作を行います。そして、LLMはそれらを厳しいルールとコスト上限の下で連携させるオーケストレーターとなります。

これは「何でも聞いて」アシスタントモデルからのクリーンな切り替えです。Cursorにおいて、ロビンの常時稼働するルールはエージェントをワークフローエンジンに変えます。それはExaコードコンテキストに到達し、次にウェブ検索、最後にRefの順に進む必要があります。そうでない場合、それは誤作動しています。アドホックなブラウジングや、すべての安価で確実な方法が失敗しない限り、幻のAPIはありません。

そのように見ると、将来の開発スタックはChatGPTよりもUNIXパイプに近いように見えます。あなたは次のように配線します： - コードとウェブのためにExa - 標準的なドキュメントのためにRef - 課題とPRのためにGitHub MCP - フルツリーコンテキストのためのRepo MCPs

各パーツは小さく、監査可能で、置き換え可能です。検索プロバイダーを変更したり、ドキュメントのソースを変えたり、同じオーケストレーションルールを異なるモノレポに適用したりしても、再トレーニングは必要ありません。「インテリジェンス」はルーティングやポリシーに存在し、神話的な全知のモデルにはありません。

**カーソルドキュメント**のようなドキュメントは、もはや人間が読みやすいヘルプだけでなく、これらのエージェントのAPIインターフェースとしても機能します。この転換、すなわちチャットボットUXから決定論的でコンテキストに応じたMCPネットワークへの移行こそが、AIに信頼できるコーディングの責任を負わせるものであり、創造的な推測ではなくなります。

まず、エディターを開いてください。まだインストールしていない場合はCursorをインストールし、その後設定に移動して「ルール」を選択します。新しいルールを作成し、外部API、フレームワーク、またはSDKに触れるコーディングセッションに対して「常に適用」を設定してください。

次に、ツールを接続します。 exa.ai のドキュメントに従って Exa MCP サーバーをインストールし、Cursor MCP 設定に追加します。同じように、Ref MCP をそのリポジトリまたはマーケットプレイスのリストから追加しますが、これはセカンダリで高コストのオプションとして保持してください。

優先順位をボイラープレートとしてエンコードしてください。Cursorがモデルへの指示として解析できる言語を使用してください。例えば：

• 1常にコーディングやデバッグ作業の際は、最初にExaのコードコンテキストツールを使用してください。
• 2さらに情報が必要な場合は、Exaの一般ウェブ検索を使用してください。
• 3明示的に要求された場合、またはExaの結果が矛盾している場合、または外部APIやライブラリを修正する試みが二回失敗した後のみRefを使用してください。

このようなテンプレートをルールに追加することができます：

「このツールの順番に従う必要があります：1) Exaコードコンテキスト、2) Exaウェブ検索、3) 以下のトリガーに関する公式文書の参照：ユーザーが明示的に要求する、Exaの結果が矛盾する、モデルのカットオフ後にドキュメントの変更が疑われる外部APIまたはライブラリの修正に2回失敗する。可能な限り安価なツールを優先してください。」

これをインフラとして扱い、一度限りのハックとして見なさないでください。ルールを保存し、すべてのコーディングワークスペースで有効にし、ドットファイルにバージョン管理して、チーム全体が同じガードレールを共有できるようにしましょう。

このスタックが稼働すると、あなたのAIは推測をやめ、情報を取得し始めます。2時間のデバッグの迷路を数分でツールによって導かれる回答に交換し、モデルの迷信ではなく、最新のドキュメントを追跡するコードを出荷します。その結果、幻覚と戦う時間が減り、ようやく信頼できるAIアシスタントと共に信頼性のある機能を推進する時間が増えます。

記事で説明されているMCPスタックとは何ですか？

一般的でコスト効率の良い検索にはExa MCPを使用し、公式文書の取得にはRef MCPを使用する二つのツールスタックで、すべてはCursorエディタ内の優先ルールによって管理されています。

なぜこのスタックは他のツールよりもExaを好むのでしょうか？

このルールは、Exaを優先します。なぜなら、Exaは代替手段よりも大幅に安価であり、ほとんどのコーディングクエリに対して「十分に良い」からです。最初はExaの特定の「コードコンテキスト」ツールを使用し、その後ウェブ検索に切り替わります。

スタックは公式ドキュメントのためにRef MCPをいつ使用しますか？

Refは、以下の三つの特定のケースで最後の手段として使用されます：ユーザーが明示的にリクエストした場合、Exaの結果が矛盾している場合、または古いドキュメントが疑われるライブラリ/APIを修正するために二度の試みが失敗した後です。

このMCPスタックはどの核心的な問題を解決しますか？

AIコーディングアシスタントがトレーニングデータのカットオフにより、古くなったり不正確なコード（ハルシネーション）を生成する問題を解決し、開発者のデバッグ時間を大幅に節約し、コストを削減します。