当天最强的主题是围绕 LLM 编码系统的控制。新工作尝试压缩到真正相关的代码，追踪自然语言/程序边界上的流动，并用更严格的权限限制代理动作。它们在修复和分析基准上都有可量化的收益，但证据也表明，单靠更强的定位或更多上下文，仍然补不上剩下的质量差距。
围绕 LLM 的软件工程工作把重点放在生成前缩小问题范围。SWEzze 学习了一个结构化的代码上下文压缩器用于修复问题，并报告了约 6 倍压缩、51.8% 到 71.3% 的 token 减少，以及在 SWE-bench Verified 上 5.0% 到 9.2% 的提升。另一项修复研究考察的是在定位已经很强之后会发生什么。给 Agentless、KGCompass 和 ExpeRepair 提供 oracle 文件和行跨度会提升结果，但原生成功率仍低于 50%，而最好的固定附加上下文探针只比三个系统的 Solved@10 并集多解决了 6 个实例。合起来的结论很直接：更好的检索和更小的提示有帮助，但 prompt 打包和补丁合成仍然限制着修复质量。
安全关注点集中在代码和模型调用之间的边界，以及代理工具的运行时安全。NL/PL 论文把 LLM 调用当作数据流边界，并标注输入有多少会保留下来，进入 SQL、JSON 或代码等输出。该基准上，这个基于分类法的流水线在污点传播上达到 F1 0.923，并且在占位符不传播时把反向切片的平均大小缩小了 15%。在工具层面，greywall 提出面向编码代理的默认拒绝沙箱，用文件系统、网络和系统调用控制代替完整用户权限。在实际审查工作中，当人工审查者把任务范围收窄并核对模型说法时，Claude Code 工作流就有用；这个案例还记录了一个需要纠正的具体事实错误。这里的主线很清楚：现在的模型辅助编码需要程序分析和运行时隔离。
生成的测试又回到代码生成流程中，但不再把任何单个测试看得太重。BACE 维护候选程序和生成测试的种群，然后用贝叶斯噪声模型同时更新两者的信念。在 LiveCodeBench v6 上，它用 GPT-5-Mini 比 CodeSIM 高 3.8%，用 Qwen2.5-Coder-7B 高 5.0%。这个想法符合当天更广泛的模式：评估信号被当作噪声证据，必须先经过过滤、加权或压缩，才能很好地指导生成。