多くの企業はAIの台頭に後押しされ、業務の自動化に急いで取り組んだ。それによって作業負担が軽減され、開発期間が短縮されることを期待してのことだ。そして、なぜそうしないだろうか？AIツールは数秒でコードを書き、数分でアプリを作成し、単一のプロンプトで完全なシステムを立ち上げ、少なくとも表面上は、ジュニア開発者をシニア開発者のように見せることができる。
しかし、彼らはすぐに、AIは確かに速くコードを生成するものの、実際の環境下ではしばしば機能しなくなり、システムは障害が発生するまで完璧に見えるという現実に直面した。こうしたコードの不具合が発生した際、その作成を担当したAIが説明を提供できないことが多い。そのため、チームは一見正しく見えるコードによって引き起こされた長いエラーチェーンを前に途方に暮れることになる。
この初期の期待は、ソフトウェアが実際にどのように機能するかについての深い教訓に変わりつつある。エンジニアリングの最も難しい部分は、これまでコードを書くことではなかった。それは常にデバッグ、つまり障害の原因を追跡し、何がそれを引き起こしたかを理解し、システムが意図した通りに動作できるように修復するという、遅く、しばしば綿密な作業だった。
AIはコード作成を速くしたが、システムの理解や保守を容易にしたわけではない。負担は単に開発の後半段階に移っただけであり、そこでは障害の診断がより困難になる。このギャップが現在、ソフトウェア開発におけるAIの真の姿を形作っており、新たなイノベーターたちが重要な転換点と見なしている部分だ。
大きなデバッグ問題
デバッグには、現在のAIシステムが把握するのが難しい程度の推論能力が必要だ。これらのモデルは、シーケンスの中で次に来る可能性の高いトークンを予測するように訓練されており、これは馴染みのあるパターンに従うコードを生成するのに適している。しかし、実際のソフトウェアはそのように動作しない。実際のソフトウェアは動的なシステムとして機能し、時間とともに進化し、状態を蓄積し、データと相互作用し、多くの暗黙の前提に依存している。
KodeziのCEO兼創業者であるイシュラク・カーン氏が説明するように、「デバッグは次のコード行を予測することではない。これは、何千もの可動部分を持つ複雑なシステムにおける障害の背後にある理由を再構築することを含む」。彼は、GPTやClaudeのようなモデルはパターンを完成させることはできるが、それらのパターンが一度デプロイされるとどのように動作するかを理解していないと主張する。カーン氏は、最先端モデルがコード合成ベンチマークで定期的に70%以上のスコアを獲得するが、実際のデバッグタスクでは15%未満に落ち込むという現実を指摘した。これはマイクロソフトリサーチによる研究でも顕著に確認されている。
最新のStack Overflow開発者調査では、AIツールがより一般的になっても、開発者はデバッグ、テスト、保守に多くの時間を費やしていると報告している。GitHubのエンジニアリングアップデートでも同様の懸念が認められており、AIアシスタントがコンテキストのギャップを生み出す可能性があり、コードが本番環境に到達した後により深い人間のレビューが必要になると指摘している。
カーン氏によると、この問題が彼を別の汎用LLMではなく、デバッグに特化したモデルの構築へと導いたという。KodeziのデバッグファーストモデルであるChronosは、何百万もの実際のデバッグセッションで訓練され、一般的なモデルがめったに見ないようなエラー、ログ、システム動作の種類に触れる機会を得た。カーン氏によると、その目標は開発者が問題をより早く特定し、なぜそれが発生したかを理解し、コードが破損した後の書き直しやパッチ適用に費やす時間を削減することだという。
速さの幻想
多くの組織がAIコーディングツールを採用したのは、ワークフローの初期段階で目に見える速さを提供したからだ。しかし、より速い作成は、より遅い納品を隠すことがある。開発者は生成中に時間を節約し、その後、統合、検証、修復中にそれを失う。カーン氏は、デバッグだけで開発者の時間の半分近くを消費すると推定しており、これが彼にコード生成が本当のボトルネックではないと早い段階で確信させた。
「開発者は時間を節約していない。作業は単に下流に移動し、そこではコストが見えにくくなっている」と彼は言う。これは私たちの会話から得られた最も明確な洞察の一つであり、多くのチームが現在経験していることと一致している。AIは開発のフロントエンドを強化したが、バックエンドには手を付けなかった。作業は消えたわけではなく、単にシフトしただけだ。
これにより、エンジニアやアナリストが複雑性負債と呼ぶものが生じる。これはコードベース全体に静かに広がる小さな問題の蓄積だ。わずかな不整合、微妙な論理の破綻、重複した機能が時間とともに積み重なり、チームは最終的に新しいものを作成するよりも多くの時間をクリーンアップに費やすことになる。企業はリリースの遅延、保守コストの増加を経験し、AIを通じて達成した初期の速さが完全に持続可能ではなかったという認識に至る。
以前報告したように、AIはシステムの完全なコンテキストを把握できない場合に機能しなくなる。デバッグはその制限が最も顕著になる場所だ。
次のフロンティア
業界がこれらの課題をより認識するようになるにつれ、注目はコード生成の後に何が来るかに移りつつある。投資家やエンジニアはデバッグをAIインフラの次の主要カテゴリとして見始めている。この移行は、魅力的なデモの背後にある隠れた問題に対処したため不可欠となった、オブザーバビリティ、DevOps、MLOpsなどの分野への以前のシフトを反映している。
カーン氏が私に語ったように、「生成は簡単な部分だった。デバッグは本当のフロンティアだ。なぜなら、それはAIに障害、メモリ、因果関係を理解することを強いるからだ」。ここでAIの長期的な経済性が明らかになる。企業はより多くのコードを生成することから本当のROIを得るのではなく、システムが成長するにつれて正確で予測可能、安定したままであるコーディングからROIを得る。
企業は、AIがどれだけのコードを生成できるかではなく、そのコードが実際の環境に到達した後どれだけうまく機能するかに本当の価値があることを学んでいる。繰り返される障害の減少、より速い修正、より安定したリリースは、生の出力よりもはるかに重要だ。コンテキストを保持し、過去の障害を記憶し、繰り返しパターンを認識できるデバッグツールは、デバッグを単なるクリーンアップ作業から継続的な学習プロセスに変えることで、エンジニアリングチーム全体を再形成する可能性がある。
外部の専門家も同じシフトを見ている。GitHubのCEOであるトーマス・ドームケ氏は最近のインタビューで、AIツールはソフトウェアの立ち上げを支援できるが、それらのシステムのスケーリングと維持には、実際の環境でどのように動作するかについての深い技術的理解が依然として必要だと述べた。これは彼がThe New Stackとの対話で強調したポイントだ。
より広い業界が現在、デバッグを信頼できるAIシステムを構築する上で欠けている主要な層として認識していることは明らかだ。これは自動化が独立して機能できるのか、それとも人間が引き続きその後始末をする必要があるのかについての洞察を提供している。
意味するもの
現在の本当のテストは、AIがコードが書かれた後に何が起こるかを処理できるかどうかだ。AIツールが自分の間違いを特定または修正できない場合、それは常に人間の監視を必要とする。障害を追跡し、説明し、そこから学ぶことができるAIツールは、日々のエンジニアリング作業においてはるかに有用になる。
カーン氏はメモリを欠けている能力として指摘する。「AIは単により多くの出力を生成するのではなく、自分の間違いを理解できるようになったときにのみ信頼できるようになる」と彼は述べた。KodeziのデバッグファーストモデルであるChronosは、何百万もの実際のデバッグセッションで訓練されており、一般的なモデルが通常見ないような障害パターンに触れる機会を得ている。それはデバッグを単一のプロンプトではなく、時間をかけた会話として扱う。失敗した試みから学び、その経験を前進させる。
他の専門家も、持続可能なソフトウェア、速いソフトウェアではなく、AIの次の段階を定義するだろうという点で同意している。安定性のない速さはコストを増加させる。学習のない安定性はシステムを脆弱にする。そして長期的な方向性は、開発者を置き換えるのではなく、今日チームを遅らせる絶え間ない保守負担を減らすことで、より少ない人間の介入で自己修正できるシステムに向かっていると、複数のエンジニアが主張している。
業界は一つの単純な真実に目覚めた：AIの未来は、システムがどれだけ速く作成できるかではなく、どれだけうまく回復できるかにある。デバッグはその物語が始まる場所であり、知性が現れる場所だ。そして、それは企業が自分たちのAI投資が本当に生活を楽にしているのか、それとも単にもう一つのコスト層を追加しているだけなのかを発見する場所だ。
