代码成本崩塌后的工程管理
随着大语言模型让生成代码变得极其便宜且更快，许多工程师认为，软件开发中真正的瓶颈如今是系统设计、组织结构，以及对复杂代码库的理解，而不是把实现代码敲出来。评论者们争论 AI 生成的代码究竟是可维护的，还是只会加速技术债的积累；一些人表示，当人类把注意力放在架构和审查上时，生产力和质量会显著提升，另一些人则看到可靠性和清晰度在下降。其背后是一个更大的问题：当“管道”工作几乎免费，而上下文、协作和长期责任仍然昂贵时，工程管理、团队构成和指标应如何演变。
LLM 对编码成本与瓶颈的影响
- 许多人同意，编写代码这一机械动作如今更便宜也更快了。
- 一些人认为，真正的瓶颈很少是写代码本身；协作、需求，以及对复杂系统的理解仍然主导着时间线。
- 另一些人则反驳说，实现工作其实一直是主要拖累，而 LLM 消除了大量“杂务”，让架构思考和迭代成为可能。
代码质量、可维护性与技术债
- 分歧很大：有人表示 LLM 现在能在许多语言中生成可用于生产、且经过良好测试的代码；也有人说输出总是要重写，并且不可维护。
- 有人担心 LLM 正在加速未审查、低质量“slop”以及巨大代码库的积累，从而加深技术债。
- 讨论的焦点还包括：LLM 写出的代码，未来是否能被后续 LLM 安全地“自我维护”，还是会变成晦涩、无法理解的黑箱。
- 还有人担心原型会变成事实上的设计，前期设计工作很少，糟糕的抽象却被固化下来。
LLM 在开发中的最佳用途
- 普遍支持将 LLM 用作代码审查、重构辅助、安全检查工具，以及用于小型脚本或迁移。
- 对规划的看法不一致：有人主张以规格驱动开发，让 LLM 负责计划和代码；也有人觉得 LLM 生成的计划含糊且不可靠。
- 关于 LLM 评估架构或预测变更成本的能力，反馈也很混杂；这些尝试被描述为高度依赖项目，且无法在不同仓库之间直接比较。
组织与管理层面的影响
- 许多人指出，真正的问题是团队结构、优先级和决策，而不是打字速度。
- 有些人担心管理层会借助 AI，把工程纯粹当作成本中心来对待，而忽视维护和长期质量。
- 另一些人则认为，好的管理基本原则（影响力、上下文、所有权）并没有改变；token 使用量和 LOC 仍然是糟糕的指标。
- 讨论还包括：管理本身是否比工程更容易被自动化，以及为什么仍需要人类承担后果并塑造抽象和激励机制。
写作、文档与“AI slop”
- 有人抱怨 AI 已经把长篇文本的成本压低，导致网络上充斥冗长、泛泛而谈的内容。
- 几位读者觉得所链接的文章在风格上很“AI 化”，并讨论其真实性，同时批评标题醒目但正文充水。
- 也有人呼吁写得更短、更密集，并使用更好的工具或训练方式，避免 AI 式的冗长。