这一时期的主要信号是对 AI 构建软件提出更严格的证据要求。ConCovUp、RubricRefine 和 MonitoringBench 都是在测试代理的具体失效模式：错过并发交互、错误的工具契约，以及隐藏的破坏。快速做应用也会带来可测的安全和维护成本。
几篇论文把大语言模型（LLM）输出放到任务特定测试下，而不是接受流畅代码。ConCovUp 通过寻找共享内存访问对、向后推理输入，并运行生成的多线程驱动程序，来针对并发 C/C++ 行为。它把 9 个库上的平均共享内存访问对（SMAP）覆盖率从 Claude Code 基线的 36.6% 提高到 68.1%。
RubricRefine 在真实工具执行前做同样的检查。它为任务和工具注册表生成评分标准，检查输出形状、路由、参数来源和调用顺序，然后在任何环境动作前修复代码。在 M3ToolEval 上，它在 7 个模型上的平均成功率是 0.86，而单次运行的 CodeAct 是 0.62。SmartEval 把这种评估压力扩展到 Solidity 合约，在 9,000 个生成合约上按规格一致性、状态机正确性、业务逻辑和代码质量打分。
当攻击过于狭窄时，MonitoringBench 表明监控器评估会显得很好。论文构建了 2,644 条成功的 BashArena 攻击轨迹，并用一个分类体系加事后细化来扩展破坏尝试。攻击包括防火墙后门、sudo 权限提升、凭据外泄和恶意软件下载等动作。
测得的下降幅度很大。在一个 Opus 4.5 全轨迹监控器上，命中率从直接诱导的 Opus 攻击上的 94.9% 降到最佳细化攻击上的 60.3%。在一项引用的细化攻击对比中，GPT-5 从 60.2% 降到 19.5%。这对部署前控制测试是个警告：监控器质量取决于攻击生成器，而不只取决于监控模型。
公开的代理工具已经有足够多的重复，会影响评估和审查。工具克隆研究审计了 7,508 个 Model Context Protocol（MCP）仓库和 1,353 个 Skills 仓库，共覆盖 100,011 个工具条目。在相似度较高的 MCP 对中，人工审查把 60% 的高 Jaccard 候选和 85% 的高 ssdeep 候选标为克隆。这会污染基准切分、重复脆弱脚手架，并夸大多样性声明。
部署侧也有类似的可见性问题。RedAccess 报告说，在 Lovable、Replit、Base44 和 Netlify 域名上有 5,000 多个 AI 生成的网页应用，几乎没有访问控制，或者完全没有访问控制。大约 40%，接近 2,000 个应用，似乎暴露了敏感数据，例如医院分配、客户聊天机器人日志、销售记录、运输记录和财务记录。这些是运营失败，不是模型基准失败。
实际报告比基准论文更不一致。一位创始人说，他用 Claude 在 8 周内做出一个生产级足球比赛追踪应用，从同一代码库发布了 iOS、Android 和网页版本，配有 600 多个自动化测试，号称无崩溃率高于 99%。同一份说法也列出了仍然需要人做的工作：产品判断、生成代码审查、生产崩溃诊断、数据库性能修复和用户体验修正。
维护成本模型给团队一个简单的检验方式。如果代理把代码产出翻倍，同时把单位维护成本也翻倍，那么模型里下个月的维护负担会变成四倍。作者认为，要保住长期产能，2 倍产出提升大致需要把单位维护成本减半。一个定性软件工程研究得出一致的流程判断：当团队使用代理式编码系统时，需要更强的意图说明、仓库上下文、验证、安全审查、来源追踪和治理。