衡量代码的草率程度
有人宣称 AI 已经“解决了编程”，但与此同时，人们越来越担心大型语言模型会生成大量低质量、难以维护的代码。评论者探讨了用行数、圈复杂度、冗长规则以及多步骤基准来量化这种“草率程度”的尝试，这些基准显示 agents 会在迭代中不断累积技术债。许多人认为，模型虽然常常能快速产出正确片段，但真正的代码质量——可维护性、架构、安全性，以及在人类或 agent 在大规模场景下的可理解性——仍未解决，而且如果不慎，还很容易陷入 Goodhart 定律。
SlopCodeBench 与“slop”累积
- 基准测试翻转了常见模式：多个迭代任务之间清空上下文，模拟真实的 agent 使用方式。
- 较差的早期设计决策会相互叠加；在严格标准下（所有检查点都通过），据称即使是顶尖模型也只能达到 0% 解决率。
- 使用了简单指标：LOC 增长、圈复杂度，以及启发式“冗长规则”来检测过长或冗余的代码。
- 许多评论者很高兴终于能用定量方式把他们在实践中看到的现象抓出来。
代码质量到底是什么？
- 一些人认为，正确性只是基础；质量还包括效率、安全性、可维护性、可读性、可观察性、可移植性等。
- 也有人指出，历史上大量人类企业代码本来就质量不高；AI slop 被看作只是“换汤不换药，只是更快了”。
- 还有人声称，代码质量从根本上就很难甚至无法衡量（类比停机问题），本质上依赖感觉。
LLMs 擅长编程吗？相互矛盾的体验
- 热情的一方：
- 对很多任务来说，LLM 的输出据说比普通或初级开发者更好，尤其是在有能力的人类指导下。
- 人们报告了更高的吞吐量且质量可接受，特别是在更高层语言和从零开始的新项目中。
- 怀疑的一方：
- agents 会过度生成代码、重复逻辑、避免删除死代码，并破坏现有架构。
- 它们常常在非局部修改、复杂系统和微妙 bug 上失败，或者需要大量手把手管理。
- 有人说，LLM 编写的代码库会“速通”到不可维护的状态。
全局设计、可维护性与心智模型
- 评论者强调，最难的问题是全局性的：关注点分离、分层、接口，以及长期演化。
- 编码被描述为人类构建共享心智模型的一种方式；如果 agent 全部做编码，人类可能会失去理解和控制。
- 也有人认为，未来工具也许会为庞大代码库提供“视图”，从而减少人类持有全局模型的需要。
指标、Goodhart 定律与评估想法
- LOC 变化被广泛视为一个出人意料地有效的“气味”指标，但也容易被优化/病态的“代码高尔夫”所利用。
- 建议包括：将 LOC/tokens 与圈复杂度、变更量、耦合度、内聚性、缩进深度、AST 模式以及 token 成本结合起来，以“理解”代码。
- 有人提出：
- 迭代式的“正确解决的轮数”作为核心指标。
- 使用一个单独的基线模型来判断另一个模型的代码是否可用。
- 领域/架构基准（例如逐渐更复杂的“counter”应用），衡量设计质量，而不仅仅是通过测试。
行业影响与开放问题
- 许多人区分“编程”和“软件工程”；他们认为前者会比后者更快走向自动化。
- 关于当前模型是否已经超过了“大多数”开发者，还是仍然远不如合格专业人士，存在争论。
- 成本和 token 限制是现实约束；有人报告因为费用和 slop 而回退了激进的 agentic 设置。
- 总体情绪是：衡量草率程度很有价值，但定义并优化真正的代码质量仍未解决。