控制想法，而不是代码

LLM 作为编码代理 vs 阅读代码

• 许多人同意，LLM 现在已经是很强的编码助手，在使用得当时，能够处理大型重构、新模块和不常见的技术栈。
• 也有人表示，随着项目规模扩大（10 万到 100 万 LOC），模型会出现漂移、重复概念，并倾向于流行框架和惯用法，而忽视定制架构或 AGENTS.md 风格的文档。
• 有人认为，未来重点应该放在“控制想法”（架构、接口、测试）上，而不是逐行阅读每一行代码；也有人觉得，至少审查部分代码仍然是理解并指导系统所必需的。

代码质量、垃圾代码与规模化

• 一些评论者认为，LLM 生成的代码库臃肿、重复，并且容易发生概念漂移，尤其是在缺乏强约定、lint 和人工重构时。
• 另一些人则声称，他们在较大的 Rust/Lua 项目上取得了成功，依靠的是护栏、强类型以及激进的重构/测试。
• 还有人担心，随着 AI 生成的仓库主导训练数据，未来模型会因为更低的“熵”和平庸代码的反馈回路而退化。

技能、“技能问题”与教学

• 一派将糟糕结果主要归因于用户在“agentic engineering”和实验方面的技能。
• 另一些人批评这种说法傲慢且无帮助，强调 LLM 工作流是新的、记录不足的，而且如果没有紧密协作就很难迁移。
• 争论的焦点在于，这些问题到底是“技能问题”，还是“知识/经验问题”，以及专家是否有义务分享实用的工作流。

测试、安全性与可靠性

• 普遍同意的是，模型仍然会幻觉并夸大正确性；严格的测试、TDD、基于属性的测试，以及可复现的复现案例仍然至关重要。
• 有人认为测试和经验性 QA 在很大程度上可以取代读代码；也有人坚持，测试永远无法证明没有 bug，结构本身必须被理解。

许可证、Redis/Valkey 与超大规模云厂商

• 旁支讨论：对于 Valkey 是否“取代”了 Redis，还是只是获得了采用，以及这究竟是否由许可证而非 AI 使用推动，存在强烈分歧。
• 对超大规模云厂商从开源中获利却没有相应贡献的批评非常强烈，同时也在争论宽松许可证是否是一个错误。
• 有人认为“fair source”/open-core 许可证是必要的防御；也有人担心这会破坏可移植性和自托管。

职业、学习与可及性

• 人们担心，如果把编码交给 LLM，新手将难以建立架构和设计所需的心智模型。
• 有些人担心未来有意义的软件工作将需要付费访问专有模型和昂贵硬件，从而让这个领域更难进入。
• 另一些人则建议忽略网红，继续写代码和读代码，并把 AI 看作强大但易错的工具，而不是替代品。