代码行数又有了更好的公关

代码行数指标的回归

• 评论者指出，在 AI 时代，LoC 作为成功指标正在卷土重来，尽管它长期以来一直备受批评。
• OpenAI 的“由代理生成的百万行代码”博客文章被视为这一现象的代表：大篇幅强调 LoC，却几乎没有说明产品价值。
• 与 Linux、Chrome 以及大型 monorepo 的比较凸显出，巨大的 LoC 数字本身并不一定值得炫耀，也不一定是好事。

AI 垃圾代码、技术债务与可维护性

• “AI slop” 与传统“技术债务”形成对比，被认为更具体：大量代码很少有人能看懂，而且往往远远超出目的所需。
• 有人认为每一行代码都是负担；LoC 应该被视为“成本”而不是资产。
• 人们担心 LLM 编写的代码库会呈现出可识别的模式：看似合理的代码、薄弱或虚假的测试、不清晰的抽象。

生产力与瓶颈

• 许多人表示，“写代码已经不再是瓶颈”；真正的限制在于决定要做什么、代码审查、测试以及组织流程。
• 个人开发者通常会感觉更快，尤其是在测试、样板代码和理解遗留代码方面，但由于下游瓶颈没有改变，团队或公司层面的收益却很有限。
• 对“每位工程师每月 100 万行代码”之类的说法存在争论；有人认为这指的是自动迁移，也有人认为这不现实，而且很容易被操控。

指标、刷分与古德哈特定律

• 例子包括：基于代码行数的绩效考核、按 PR 数量进行评估、以及用生成垃圾来刷代码覆盖率配额。
• 评论者反复提到古德哈特定律：当 LoC、PR 数量或“AI 编写代码占比”成为目标时，它们就不再能衡量真实生产力。

采用压力与文化分裂

• 有人坚持认为，每个工程师都必须每天使用 AI，才能保持可雇佣性和竞争力；也有人将这视为炒作或“拿枪逼着用”的采用方式。
• 现场反馈混杂：非技术用户或初级用户起初会很惊艳，但在用 AI 处理自己熟悉的任务时，往往会感到失望。
• 在 HN 上，不同参与者把这里同时看作“AI 粉丝”与“AI 憎恶”的阵地，反映出社区的两极分化。

安全关键领域与“真正”的产品

• 安全关键和嵌入式行业被描述为基本没有采用 LLM 代码生成；有一项被引用的研究发现，存在大量对指南的不符合。
• 更广泛的对比是：一类行业必须交付可用且有利润的产品，另一类则被视为专注于“伪生产力”。