Can LLMs Fix It Without Code? Toward Automated Verification of No-Code Bug Fixes

📄 arXiv: 2610.11963v1 📥 PDF

作者: Utku Boran Torun, Veli Karakaya, Eray Tüzün

分类: cs.SE, cs.AI

发布日期: 2026-10-08

💡 一句话要点

提出自动化验证方法以评估无代码修复的有效性

🎯 匹配领域: 支柱九：具身大模型 (Embodied Foundation Models)

关键词: 无代码修复 自动化验证 大型语言模型 软件开发 执行基础管道

📋 核心要点

  1. 现有方法在验证无代码修复的有效性时，依赖人工审核，耗时且效率低下。
  2. 本文提出了一种自动化的执行基础管道，利用大型语言模型生成并验证无代码修复。
  3. 实验结果显示，LLM生成的无代码修复有效性不高，需在用户使用前进行验证。

📝 摘要（中文）

无代码修复通过指导用户更改设置、更新版本或调整工作流程来解决无效的错误报告。手动验证无代码修复的有效性耗费大量开发者时间。本文提出了一种基于执行的自动化管道，用于评估大型语言模型（LLMs）在真实浏览器环境中生成无代码修复的能力。我们评估了322个无代码修复，涵盖了错误报告的不同类别。实验结果表明，尽管在最佳执行者下，LLM生成的无代码修复仍需验证，且其有效性受执行者影响显著。

🔬 方法详解

问题定义：本文旨在解决无代码修复的有效性验证问题，现有方法依赖人工审核，效率低下且耗时。

核心思路：通过自动化执行管道，利用大型语言模型生成无代码修复，并在真实环境中进行验证，以提高验证效率。

技术框架：整体架构包括三个主要模块：生成器（LLM生成无代码修复）、执行者（执行修复指令）和检查器（验证修复效果）。

关键创新：提出了一种基于执行的验证方法，能够在真实环境中评估无代码修复的有效性，与传统的人工验证方法相比，显著提高了效率。

关键设计：实验中使用了三种执行者，分别为OpenCUA-72B、Claude Sonnet 5和Meta的Muse Glimmer，验证结果显示不同执行者对修复有效性的影响显著。实验还表明，执行者的选择会影响修复的成功率。

🖼️ 关键图片

fig_0
img_1
img_2

📊 实验亮点

实验结果显示，322个无代码修复中，只有17.6%的问题能够成功设置并通过验证。在不同执行者下，修复成功率在14.6%到49.7%之间，最佳配置下，Claude Opus 4.6在Claude Sonnet 5的环境中成功解决了74.1%的修复。执行者的选择对修复率的影响平均达到38.8%。

🎯 应用场景

该研究的潜在应用领域包括软件开发、技术支持和用户自助服务等。通过自动化验证无代码修复的有效性，可以显著提高开发效率，减少用户在解决问题时的等待时间，提升用户体验。未来，该方法有望推广至更广泛的自动化测试和质量保证领域。

📄 摘要（原文）

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.