論文の概要: When Modernization Breaks Working Code: A Single-File Study of LLMs on Legacy PHP

• arxiv url: http://arxiv.org/abs/2610.40269v1
• Date: Thu, 29 Oct 2026 15:29:45 GMT
• ステータス: 翻訳完了
• システム内更新日: 2026-11-02 07:45:04.663048
• Title: When Modernization Breaks Working Code: A Single-File Study of LLMs on Legacy PHP
• Title（参考訳）: モダナイゼーションが動作コードを破る時 - レガシーPHP上のLLMのシングルファイルスタディ
• Abstract要約: 5つのLCMがWordPress 4.0 PHPファイルをPHP 8.3に近代化するよう求められた。 我々は630個の隠れ行動チェックと511個のRector検出された近代化結果を用いて全ての出力を評価する。 モダナイゼーションスコアが最も高いモデルは、最も近いライバルと互換性がない。
• 参考スコア（独自算出の注目度）: 2.437869752261983
• License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
• Abstract: Pasting a legacy file into an LLM and asking it to "modernize this" is an easy shortcut. But is the result better than leaving the code alone? In this paper, we study this single-file setting with five LLMs, each asked to modernize 100 WordPress 4.0 PHP files to PHP 8.3 while preserving behavior, with no project context or execution feedback. We evaluate every output with 630 hidden behavioral checks and 511 Rector-detected modernization findings. We compare against two baselines: the unchanged originals and the rule-based tool Rector. Often, the answer is no. Untouched, 83 files already pass every check; the best LLM leaves only 59. Each model breaks 32-51 working files while repairing at most 10, whereas Rector breaks 7 and repairs 6. Most of this damage is unnecessary. Only 37 findings (7 percent) require a change under PHP 8.3, yet in compatible files with no required change, the LLMs break 36-60 percent (Rector: 8 percent). The model with the highest modernization score is no more compatible than its closest competitors. Most regressed checks come from files that no longer load at all, often because of type declarations PHP itself rejects. These are errors that need no project context to avoid. Evaluations of LLM-based modernization should therefore measure against a no-change baseline and report modernization and behavioral preservation separately.
• Abstract（参考訳）: レガシーファイルを LLM にペーストして "近代化" するよう要求するのは簡単なショートカットです。 しかし、コードはそのままにしておけばよいだろうか? 本稿では,この単一ファイル設定を5つのLCMを用いて検討し,プロジェクトコンテキストや実行フィードバックを伴わずに,100のWordPress 4.0 PHPファイルをPHP 8.3に近代化するよう要求した。 我々は630個の隠れ行動チェックと511個のRector検出された近代化結果を用いて全ての出力を評価する。 変更のないオリジナルとルールベースのツールであるRectorの2つのベースラインを比較します。 多くの場合、答えはノーです。 タッチなしの83のファイルはチェック毎にパスしており、最高のLCMは59.5%しか残っていない。 それぞれのモデルは32-51の動作ファイルを破り、少なくとも10は修復するが、Rectorは7を破り6を修復する。 この損傷のほとんどは不要である。 たった37の発見(7%)しかPHP 8.3での変更を必要としていないが、互換性のあるファイルでは必要な変更は必要とせず、LCMは36～60%(レクター:8%)を破っている。 モダナイゼーションスコアが最も高いモデルは、最も近いライバルと互換性がない。 ほとんどの回帰チェックは、PHP自体が拒否する型宣言のため、もはやロードされないファイルから来ている。 これらは、プロジェクトコンテキストを避ける必要のないエラーである。 したがって, LLMに基づく近代化の評価は, 変化のないベースラインに対して測定し, 近代化と行動保存を別々に報告すべきである。

関連論文リスト

• Codebook Agent: Amortized Topology Design for LLM Multi-Agent Systems [67.04448659688579]
  クエリ非依存の16エントリのコードブックを開発し、上位のデコード候補を1回のバッチフォワードパスでランク付けする。 反復検索がなく、テスト時にメッセージパッシングがないため、Codebook Agentは6つのベンチマークでもっとも正確な方法である。
  論文  参考訳（メタデータ） (2026-09-02T08:10:22Z)
• Don't Let the Model Write the YAML: Deterministic, Minimal-Diff GitOps Remediation from LLM-Proposed Field Changes [0.0]
  GitOpsでは、モデル作者に編集されたファイルや差分を持てば、最初に実践者が到達できる。 ファイルを編集する構文的行為から意味的決定(リソース、フィールド、値)を分離する代替案を提案する。 ファイルは再シリアライズされないため、diffは構成によって最小限であり、編集はモデルから独立して正確で決定論的である。
  論文  参考訳（メタデータ） (2026-08-31T18:37:12Z)
• Exploration Structure in LLM Agents for Multi-File Change Localization [7.536387580547836]
  ほとんどのAIエージェントは、リポジトリを線形に探索する。 非線形・ドメインスコープ並列エージェント探索に対する線形シーケンシャル探索の比較を行った。 単一のベースコミットに固定されたGitHubイシューの永続化セッション評価のためのアプローチを構築します。
  論文  参考訳（メタデータ） (2026-06-10T11:54:14Z)
• MEME: Multi-entity & Evolving Memory Evaluation [76.57263966646404]
  MEMEは、マルチエンタリティと進化する軸によって定義される全空間にまたがる6つのタスクを定義している。 3つの記憶パラダイムにまたがる6つの記憶システムの評価。 デフォルト設定の下では、すべてのシステムが依存性の推論で崩壊しているのが分かります。
  論文  参考訳（メタデータ） (2026-05-12T17:55:10Z)
• How Far Is Document Parsing from Solved? PureDocBench: A Source-TraceableBenchmark across Clean, Degraded, and Real-World Settings [56.70440596502351]
  昨年は20以上のオープンドキュメントパースモデルが見られたが、ベンチマークはほぼOmniDocBenchにのみ依存している。 HTML/CSSのドキュメントイメージをレンダリングするベンチマークであるPureDocBenchは、10のドメイン、66ページ、1,475ページをカバーしています。
  論文  参考訳（メタデータ） (2026-05-08T09:30:31Z)
• Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM-Specified Library Versions [52.50730821321986]
  大規模言語モデル(LLM)におけるバージョンレベルのリスクの大規模評価を初めて行った。 我々は1000のStack OverflowプログラミングタスクのベンチマークであるPinTrace上で10のLLMを評価した。 LLM バージョン選択は LLM ベース開発における第1級, 以前は見落とされたリスクサーフェスとして確認された。
  論文  参考訳（メタデータ） (2026-05-07T13:52:59Z)
• ProgramBench: Can Language Models Rebuild Programs From Scratch? [59.40748183470308]
  ProgramBenchは、ソフトウェアエンジニアリングエージェントがソフトウェアをホリシックに開発する能力を測定する。 エンドツーエンドの動作テストはエージェント駆動ファジィによって生成される。 モデルは、人間が書いたコードと大きく異なるモノリシックでシングルファイルの実装を好む。
  論文  参考訳（メタデータ） (2026-05-05T09:17:02Z)
• Understanding Robustness of Model Editing in Code LLMs: An Empirical Study [1.5624785508022727]
  本稿では,5つの最先端モデル編集手法の体系的研究を行う。 これらの手法を3つの主要なオープンソースコードLLM、CodeLlama、CodeQwen1.5、DeepSeek-Coderに適用する。 インスタント編集はモデル性能を常に劣化させ、構文的妥当性は86ポイントまで低下し、機能的正しさは最高のパフォーマンス設定でも45ポイントまで低下する。
  論文  参考訳（メタデータ） (2025-11-05T04:58:13Z)
• Can Language Models Replace Programmers for Coding? REPOCOD Says 'Not Yet' [9.48622608877252]
  大規模言語モデル(LLM)の機能を評価するために、多くのリポジトリレベルのコード生成ベンチマークが登場した。 これらのベンチマークは、短い補完、合成例、または限られたスケールのリポジトリに焦点を当て、現実世界のコーディングタスクを表現できない。 実世界の大規模プロジェクトで現実的な依存関係を持つ複雑なタスクを含むPythonコード生成ベンチマークであるREPOCODを作成します。
  論文  参考訳（メタデータ） (2024-10-29T01:21:05Z)
• Progressive-Hint Prompting Improves Reasoning in Large Language Models [63.98629132836499]
  本稿では,プログレッシブ・ヒント・プロンプト(PHP)と呼ばれる新しいプロンプト手法を提案する。 事前に生成された回答をヒントとして使用することで、ユーザとLLM(Large Language Models)間の自動多元的対話を可能にする。 我々は7つのベンチマークで広範囲かつ包括的な実験を行った。その結果、PHPは高い効率を保ちながら精度を大幅に向上することが示された。
  論文  参考訳（メタデータ） (2023-04-19T16:29:48Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。