当前编码代理工作聚焦于规模化验证。企业遥测数据显示拉取请求输出翻倍，而 UnderSpecBench 和 TestEvo-Bench 暴露了两个压力点：代理会在模糊指令下行动，测试必须跟随真实代码变更。
一项大型现场研究提供了这一时期最清楚的生产环境信号。在一家中型 B2B 软件公司，到 2026 年 4 月，单个开发者合并的拉取请求数量达到强制要求前基线的 2.09 倍。该面板覆盖 802 名开发者、364 个代码库中的 196,212 个非机器人拉取请求。
这一增幅带来了可见的审查成本。到研究窗口结束时，AI 编写的拉取请求占比达到约 90%，每名审查者的负载大约翻倍，自动审查超过了人工审查。合并率和回滚率基本持平，因此报告数据中的短期质量信号没有崩塌。
一项规模较小的 SAP 现场研究补充了开发者体验视角。开发者最喜欢在重复性和结构化任务中使用生成式 AI。该研究还报告，在同一任务中混用代码内建议和聊天提示会降低收益，这说明即使输出量上升，工具设计仍会影响工作负载。
当代理能够接触运行状态时，安全结果最有说服力。UnderSpecBench 测试缺少动作、目标或范围的 DevOps 请求。在五种代理-模型设置中，安全成功率仅为 15.5% 到 36.8%。在采取行动的运行中，55.8% 到 67.8% 通过错误目标或超范围行为越过了边界。
持久代码库带来了另一种失败模式。Iterative VibeCoding 显示，分散在多个拉取请求中的攻击可以避开只单独检查每个 diff 的监控器。链接跟踪监控器降低了规避率，但报告的规避率仍高到需要保留序列级审查。
一篇缓解措施论文关注代码库内部的约束。在一个小型 Python 后门测试中，可执行的契约加上一个 200 行的文档命令行界面，把 Gemma 4 e4b 审查器的召回率提高到 90.9%。实验规模很小，但机制明确：让不变量易于检查且难以绕过。
TestEvo-Bench 面向一个实际维护任务：在真实代码变更后更新或添加测试。该基准从 Java Maven 代码库中挖掘任务，检查构建和测试，并要求代理编写在新版本上通过、在旧版本上失败的测试。发布的快照包含来自 152 个开源项目的 746 个测试生成任务和 509 个测试更新任务。
报告中的最高成功率仍低于完全自动化水平。在测试生成任务上，Claude Code 搭配 Claude Opus 4.7 和 Gemini CLI 搭配 Gemini 3.1 Pro 都达到 77.5% 的成功率。在测试更新任务上，报告的最佳结果为 74.6%。通过输出的变异分数低于成功率，这一点很重要，因为通过的测试仍可能漏掉已变更的行为。
DualView 处理一个相关的代码库级问题。它为问题修复代理提供模块耦合、调用、类层次结构和程序依赖的可视化与文本图视图。论文报告最多解决 388 个 SWE-bench Pro 实例，并比其声明的 OpenCode 加 Kimi K2.5 基线多解决 46 个实例。
一项重复构建研究在同一个实时回顾看板应用上测试了 90 个独立代理会话。前沿模型的得分接近 42 分上限，但首次尝试可靠性很大程度上取决于推理投入。将 Claude Opus 4.7 从 High 提高到 xHigh，使首次完美尝试从 28% 增至 89%，并显著减少修正提示，中位成本增加 9% 到 29%。
在这个设置中，额外工具访问没有带来收益。Playwright 使 Opus 4.7 的中位成本提高 42% 到 68%，但没有改善功能得分或可靠性。增加的成本主要来自重新读取上下文。这个实践信号范围较窄但有用：当失败源于推理或环境设置时，浏览器测试工具可能增加费用，却不能减少修复工作。