研究チームは、レガシーなPHPコードをバージョン8.3へ移行する際のLLMの能力を分析することで、ソフトウェアのアップグレードにおけるLLM活用の信頼性を調査しました。この研究では「簡単な近道」というシナリオに焦点を当て、大きなレガシーの足跡を持つプロジェクトであるWordPress 4.0から単一のファイルを取り出し、元の動作を維持したままLLMに「これを近代化せよ」と要求しました。客観的な基準を確保するため、研究チームは5つの異なるLLMを、未変更のオリジナルファイルと、専用のルールベース近代化ツールであるRectorによって生成された結果という2つのベンチマークに対して評価しました。

調査結果は、現在のLLMがコードを改善するよりも、動作するコードを劣化させることが多いことを示唆しています。テストした100ファイルのうち83ファイルは元の状態ではすべての動作チェックをパスしていましたが、最も性能の高いLLMであっても、近代化を試みた後はわずか59ファイルしか機能しませんでした。対照的に、各モデルは以前は動作していたファイルの32から51個を破壊し、修復できたのは最大でも10個でした。7ファイルを破壊し6個を修復しただけのルールベースのRectorと比較すると、信頼性の差は顕著です。特に注目すべきは、PHP 8.3との互換性のために実際には変更を必要としないファイルにおいて、LLMは36%から60%のケースで破壊的なデグレードを引き起こしたのに対し、Rectorはそれらのケースでわずか8%のエラーしか引き起こさなかった点です。

これらの失敗の主な原因は、PHPエンジン自体が拒否する基本的な構文エラー、特に型宣言に関するエラーの導入です。この研究では、AIが内部構造は見ることができるものの、プロジェクトのコンテキストや外部依存関係を欠いている単一ファイルの設定を利用したため、モデルは変数がいかに広範なシステム全体で相互作用するかについて安全な仮定を立てることに苦労しました。研究チームは、LLMベースの近代化の評価において、成功した「近代化」（新機能や新構文の導入）と「動作の維持」を区別しなければならないと結論付けています。実行フィードバックや、AIが自身のミスを反復的に修正できるエージェンティックなワークフローがない限り、単一のプロンプトによる近代化は、安定したレガシーシステムに不要なダメージを与える傾向が依然として残ります。