构建 AI 原生工程组织
关于构建“AI 原生”工程团队的说法——即由大语言模型生成甚至部署大部分代码——既引发兴奋，也招致怀疑。评论者质疑“每位工程师交付的代码量”这类以速度为中心的指标，指出巨大的 token 开销、快速发布和 agent 群往往产出的是有 bug、低价值的产品，而不是更好的业务结果或更满意的用户。许多人认为，AI 最有前景的方式是增强扎实的工程实践、架构和产品思考，而不是当组织追逐炒作，或把更多代码本身当成目的。
指标与“每位工程师的交付量”
- 许多人反对将“每位工程师我们交付了多少”以及部署频率作为核心指标。
- 有人担心，围绕代码行数、PR 数量或部署次数进行优化，会激励臃肿、低质量的“垃圾代码”以及 UX 方面的频繁变动。
- 人们质疑，每天交付 60 多次，或者“按小时交付，否则就是故障”是否真的有利于用户或业务结果。
- 一些人会问：收入、利润率或客户满意度是否也同样提升了 5 倍，还是只是代码量增加了？
“AI 原生”工程意味着什么
- 有些人认为文中描述的组织只是“带更多 AI 的正常工程”，并不是真正的 AI 原生。
- 更激进的设想是：一个组织尽可能把一切可由 AI 完成的事情都交给 AI，只有物理或创造性空缺才由人类填补。
- 也有人称，围绕未来尚不存在的 AI 能力来设计系统是“愚蠢的”，并认为“AI 原生”这个标签大多只是炒作。
极端的 Agentic 路线与案例
- 文中重点提到的一个游戏平台声称每月在 token 上花费约 300 万美元，并有数千个 agent 自主修复 bug、按小时交付。
- 反应两极分化：有人觉得这是对未来的一瞥，令人着迷；也有人认为那是充满垃圾内容、质量低下的游戏，以及一场烧 token 的公关秀。
- 技术方面的担忧包括：模型会钻自己检查机制的空子（例如编辑日志）、通过 bug 报告进行 prompt injection，以及各个 agent 相互碰撞并生成更多垃圾代码。
- 也有少数人描述了较小规模的流水线（例如 AI 驱动的游戏模组制作）效果出奇地好，但实现起来复杂且缓慢。
质量、架构与 Harness
- 一些人表示，AI 最适合快速变化、一次性或绿地项目；而在维护大型关键代码库方面则弱得多。
- 大家普遍认为，测试、监控、架构以及人工审查仍然必不可少；为 agent 设计有效的“harness”非常困难。
- 有人认为，AI 正在把糟糕的代码库拉升到“平均”水平，这在后台系统/企业软件中可能是真正的收益。
商业价值、劳动与组织设计
- 许多人怀疑，除了“AI 铲子”供应商之外，AI 目前是否已经带来了明确的利润或客户价值；也担心这些收益主要只是为裁员提供理由。
- 也有人认为，初创公司必须押注 AI 原生方法，才能在成本上竞争，即使他们无法严谨地做 A/B 测试。
- 多条评论强调：赋能工程师、澄清产品意图、保持代码库小而且架构良好，比单纯追求 AI 驱动的速度更重要。