論文の概要: Can LLMs Fix It Without Code? Toward Automated Verification of No-Code Bug Fixes
- arxiv url: http://arxiv.org/abs/2610.11963v1
- Date: Thu, 08 Oct 2026 13:44:53 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-10-10 02:36:54.06019
- Title: Can LLMs Fix It Without Code? Toward Automated Verification of No-Code Bug Fixes
- Title（参考訳）: LLMはコードを使わずに修正できるのか? コードなしバグ修正の自動検証に向けて
- Abstract要約: ノーコード修正は、ユーザが設定を変更したり、すでに修正済みのバージョンにアップデートしたり、ワークフローを調整したりすることで、無効なバグレポートを解決します。
本研究では,大規模言語モデルによる実ブラウザ環境におけるコード修正生成能力を評価するための,自動実行ベースのパイプラインを提案する。
- 参考スコア（独自算出の注目度）: 1.4465033892011254
- License: http://creativecommons.org/licenses/by-nc-nd/4.0/
- Abstract: A no-code fix resolves an invalid bug report by directing the user to change a setting, update to a version where the problem is already fixed, or adjust their workflow. Manually verifying whether a proposed no-code fix resolves the reported bug takes considerable developer time. This study proposes an automated, execution-based pipeline for evaluating the capability of large language models (LLMs) to generate no-code fixes in a real browser environment. We evaluate 322 no-code fixes generated by the 12 configurations released with the benchmark of a previous study, covering bug reports categorized as Faulty Configuration, Wrong Version, or External System & Dependency. An executor agent applies each fix by following its natural-language instructions, and an issue-specific checker determines whether the reported bug persists. We repeat the pipeline with three executors: two Computer-Use Agents, OpenCUA-72B and Claude Sonnet 5, and one multimodal agentic LLM, Meta's Muse Glimmer. Only 17.6% of the candidate issues could be set up and passed both sanity gates. Across the 322 fixes, 14.6% to 49.7% resolved the bug depending on the executor, and the strongest configuration, Claude Opus 4.6 in the Vanilla pipeline, resolved up to 74.1% of its fixes under Claude Sonnet 5. Changing only the executor shifted a configuration's resolution rate by 38.8% on average, and the three executors reached the same verdict on only 46.9% of the fixes. Compared with human execution, the executors matched the human consensus for 66.1% to 88.1% of the sampled fixes. Even under the best executor, fewer than half of the LLM-generated no-code fixes resolve the reported bug, so such fixes need verification before they reach users. Execution-based verification can provide this, but the measured capability depends strongly on the executor, which evaluations must report and control.
- Abstract（参考訳）: ノーコード修正は、ユーザが設定を変更したり、すでに修正済みのバージョンにアップデートしたり、ワークフローを調整したりすることで、無効なバグレポートを解決します。
提案されたノーコード修正が報告されたバグを解決するかどうかを手作業で検証するにはかなりの時間がかかる。
本研究では,大規模言語モデル(LLM)によるブラウザ環境におけるノーコード修正の能力を評価するための,自動実行ベースのパイプラインを提案する。
前回の調査でリリースされた12のコンフィギュレーションによって生成された322のノーコード修正を評価し、Faulty Configuration、Wrong Version、External System & Dependencyに分類されるバグレポートをカバーした。
実行エージェントは、自然言語の指示に従って各修正を適用し、イシュー固有のチェッカーは、報告されたバグが持続するかどうかを判定する。
2つのコンピュータ利用エージェント、OpenCUA-72BとClaude Sonnet 5と1つのマルチモーダルエージェントLSM、Meta's Muse Glimmerでパイプラインを繰り返す。
候補者の17.6%しか設置できず、両方の衛生ゲートを通過した。
322の修正全体では、14.6%から49.7%がエグゼキュータに依存してバグを解決し、最も強力な構成であるバニラパイプラインのClaude Opus 4.6は、Claude Sonnet 5の下で74.1%の修正を解決した。
執行官のみを平均で38.8%変更し、3人の執行官は46.9%の修正で同じ判決に達した。
人間の処刑と比較すると、実行者は66.1%から88.1%のヒトの合意と一致した。
最高の実行者の下でも、LSMが生成したノーコード修正の半分未満が報告されたバグを解決しているため、ユーザに到達する前に検証が必要である。
実行ベースの検証は、これを提供できるが、測定された能力は、評価を報告し、制御しなければならない実行者に依存している。
関連論文リスト
- Teaching Agents to Code Reliably [12.841316191115778]
リポジトリの問題を解決するために、自律的なコーディングエージェントを訓練する方法を示す。
トレーニングがこれらの行動を政策にどう移行するかを示す。
パス@1から43.0%に上昇し、パス@8から60.7%に上昇し、検証精度を26.8%から41.7%に引き上げる。
論文 参考訳（メタデータ） (2026-10-02T19:47:19Z) - Merged, Not Measured: An Empirical Study of Performance Issues Fixed by Coding Agents [8.274315021391745]
コーディングエージェントは、ソフトウェアをスピードアップすると主張するプルリクエスト(PR)を開く。
AIDev v4の71,677のエージェントPRから,582リポジトリの6エージェントによって修正された1,262のパフォーマンス問題を選択する。
私たちは各問題とそのテストをコーディングし、23の拒否と30の合併修正を再実行しました。
論文 参考訳（メタデータ） (2026-09-29T16:48:55Z) - MobileCybench: Evaluating Agent Vulnerability Discovery via Executable Probes [79.56668124357292]
本稿では,プローブを用いた脆弱性レポート評価フレームワークを提案する。
報告されたエクスプロイトは、アプリケーションに対してそれを再生し、プローブを実行することで評価される。
プローブが既知の脆弱性ではなくセキュリティプロパティをエンコードしているため、プローブがいつ書かれたか分からない脆弱性を検出することができる。
論文 参考訳（メタデータ） (2026-09-21T01:21:06Z) - ExecCritic: Learn to Test, Test to Improve for Coding Agents [68.42713285082912]
実行時のフィードバックは、コーディングエージェントを正しいリポジトリの修復に導くことができますが、テストが問題によって要求された振る舞いをキャプチャした場合のみです。
ExecCriticを導入し、テスト-検証-修正足場と、その中のトレーニングエージェントのためのロール固有の強化学習レシピを組み合わせる。
テストエージェントが独立してリポジトリネイティブなテストを生成し、フェイルクローズされたハーネスがそれらを調整して凍結し、リカバリエージェントがテストを変更することなく、ソースコードを実行フィードバックから修正する。
論文 参考訳（メタデータ） (2026-09-08T17:53:37Z) - AgentDebugX: An Open-Source Toolkit for Failure Observability, Attribution, and Recovery in LLM Agents [83.37969790806069]
LLMエージェントのエラーは、エラーが表面化するステップが原因ではないことが多いため、デバッグが難しい。
Agent DebuggerXはオープンソースのフレームワークで、デバッグをDe Detect, Attribute, Recover, Rerunのクローズドループとして整理する。
コアとなるDeep Debuggerは、グローバルな軌跡理解を通じてマルチターン根本原因診断を行う。
論文 参考訳（メタデータ） (2026-07-21T06:21:13Z) - DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks [1.7623000586936592]
DeepSWEは、コーディングエージェントを評価するための、113のオリジナルで長期のソフトウェアエンジニアリングタスクのベンチマークである。
タスクは91のアクティブなオープンソースリポジトリと5つの言語でスクラッチから書かれており、上流にコントリビュートされることはない。
SWE-Bench Proのプロンプトの約半分の長さにもかかわらず、DeepSWEのプロンプトは参照ソリューションが5.5倍のコードに触れるタスクを記述する。
論文 参考訳（メタデータ） (2026-07-08T21:45:34Z) - Automated Root-Cause Subclassification and No-Code Fix Generation for Invalid Bug Reports [0.0]
無効なバグレポートはコードの変更を必要としない。
我々のゴールは、ルートを指向した無効なバグレポートのサブクラス化のための標準化された分類を導入することです。
金標準ベンチマークで異なる構成がどのように機能するかを研究する。
論文 参考訳（メタデータ） (2026-05-17T17:45:13Z) - Constraint-Guided Multi-Agent Decompilation for Executable Binary Recovery [47.704311990064554]
脱コンパイルは、セキュリティ分析、マルウェアのリバースエンジニアリング、レガシーソフトウェアメンテナンスに不可欠である。
マルチレベル制約誘導型デコンパイル(MCGD)により,デコンパイルされたコードを再実行可能なソースに変換するマルチエージェントフレームワークを提案する。
本フレームワークは,84～97%の再実行性を実現し,28～89ポイントのベースラインデコンパイラ出力を改善した。
論文 参考訳（メタデータ） (2026-04-27T01:28:11Z) - Outrunning LLM Cutoffs: A Live Kernel Crash Resolution Benchmark for All [57.23434868678603]
Live-kBenchは、新たに発見されたカーネルバグのエージェントをスクラップし、評価するセルフ進化ベンチマークの評価フレームワークである。
kEnvは、カーネルのコンパイル、実行、フィードバックのためのエージェントに依存しないクラッシュ解決環境である。
kEnvを用いて3つの最先端エージェントをベンチマークし、最初の試行で74%のクラッシュを解決したことを示す。
論文 参考訳（メタデータ） (2026-02-02T19:06:15Z) - Where LLM Agents Fail and How They can Learn From Failures [62.196870049524364]
大規模言語モデル(LLM)エージェントは、複雑なマルチステップタスクの解決において有望であることを示す。
単一ルート原因エラーがその後の決定を通じて伝播する、障害のカスケードに対する脆弱性を増幅する。
現在のシステムは、モジュール的で体系的な方法でエージェントエラーを包括的に理解できるフレームワークを欠いている。
AgentErrorTaxonomyは、メモリ、リフレクション、計画、アクション、システムレベルの操作にまたがる障害モードのモジュール分類である。
論文 参考訳（メタデータ） (2025-09-29T18:20:27Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。