如果我们认为写代码已死，且AI正在生成所有代码库，我仍觉得更大的问题是人或整个团队不再了解系统架构或某些选择背后的意图。有评论称AI写的代码大概处于平均水平（取决于任务和规模），若代码库低于平均，AI能轻易将其提升到平均。对我而言问题不在AI代码，而是没人知晓任何事，大家都去问克劳德（Claude），结果根本没有任何计划。

如果认为"写代码已死"、AI 会生成所有代码库，那我认为更大的问题仍然是人——或者整支团队——不再了解系统架构，也不了解当初为什么做出某些选择。

我在一次讨论中的评论：

我觉得 AI 写的代码大概是平均水平（取决于任务和规模）。所以如果你的代码库低于平均水平，AI 可以轻松把它提升到平均。至少我观察到的是这样。

在我看来，问题不在 AI 写的代码，而是没人知道任何事，所有人都只会去问 Claude。最后你根本没有任何计划。

快速发展的创业公司的现状

这条推文很好地概括了快速发展的创业公司——或者大公司，或者中层管理者拼命推 AI 的地方——当下的状态：

我受够了。结束了。现在工程的状态糟透了。我在一家大公司入职才半个月。这里没人知道任何事。规格、代码、测试、PRD、工单、工单的解决、报告等等，全都是 Claude Code 做的。

我团队里没人喜欢这样。他们被迫尽量多交付。我从高层那里听过好几次：推代码不是瓶颈，那我们为什么慢？人们每天工作 12 到 13 个小时，只是在按回车。没人在读任何东西。公司里的人自己不干任何事。

每个人，真的是每个人，从 L1 到 L7 的工程师都在做同一件事：跟 Claude 说话。没有任何胜利感。没人在解决 bug。实际上，没人在思考了。一切都由 LLM 完成。

太耗人心神了。说实话，如果我们至少有时间看看代码、看看在往哪走，我不会介意。但没有，目标就是交付，不管发生什么。

数据工程不一样？

Hoyt Emerson 提到数据工程是不同的：

我觉得做数据的人不一样。我们从第一天起就必须了解产品/业务的一切。现在 AI 只是帮我们去掉了摩擦。

我认为在 AI 之前成长起来的数据人，确实必须了解一切（或者很多，或者拉上领域专家）才能把问题搞清楚。但 AI 让这件事变得过时，或者说看似过时。

所以今天才开始的人，或者包括我自己，如果在一个新领域里从今天开始一路提示下去，那些知识突然就没有了。

产品经理现在想做啥都能做

Sean Behan 说得很好：

我一直很钦佩那些不会写代码、但能带团队做出他们想要的软件的产品人。知道自己想要什么，一直是最难的部分。

可以说，一个好的产品经理现在想做啥都能做出来，找到市场，做得好看等等。但反过来说，如果你不会写代码，你本质上会给一个很难维护的产品打下一个很糟的地基（尽管 AI 在这方面也越来越强，尤其是你频繁迭代的时候；但如果你选错语言或选错心智模型，那你就从一开始就错了）。

无论如何，懂基本功仍然有帮助：既对编程和产品设计有帮助，也对一个知道需要什么、同时理解系统与架构设计的好 PM 有帮助。

最终的 boss 仍然是维护

用系统的、架构的方式思考，或者拥有意图和设计，都有助于成为更好的软件工程师。如今，手写代码可能已死，但它确实有帮助，而拥有品味（在 AI 时代）比以往更重要。

但最终的 boss 过去是、将来也永远是维护性。生成一条流水线、一个应用或一个 BI 面板越容易，你要维护的东西就越多。而如果没人知道任何事，那就会变得非常难。

AI 不能自己开车

是的，AI 没法给自己提示词，对吧？那我们为什么还需要人类？在我看来，这清楚说明仍然需要人来指挥和编排它。这也是为什么意图、品味、设计和架构在今天是杀手级能力。

但一旦这些东西缺位，更糟的是连基本功都丢了，那就真的很危险。我今天读到一种说法，说这是自作自受的问题，如果我们还在招初级工程师，这问题就不会发生。不过话说回来，事情也没那么容易。

社区普遍担忧 AI 编码代理正让团队丧失对系统的理解、埋下维护隐患，但分歧在于应归咎工具本身，还是人的滥用、纪律缺失与既有的管理痼疾。

认为 AI 编码正导致系统理解丧失与维护危机

• 长期人员变动与文档缺失叠加 AI 生成，团队已无人知晓代码初衷且不敢改动（较多人）
• 不理解系统则决策能力退化，虽不必审每行但须能描述高层结构，技术主管经验关键（高赞） > 若不能描述系统运作与高层结构，对未来工作的判断力会迅速退化（@simonw）
• 可维护性始终靠人类理解代码，AI 只写代码不写系统，维护是最终 boss（较多人）
• 当使用 AI 变成“孤注一掷”式盲信输出，即标志理解脱钩，须退后补缺（少数人）
• LLM 解决了编码层面，但未解决系统、协作与维护，代码作为抽象本身可能不当（少数人）

认为问题源于滥用、纪律缺失或既有组织顽疾而非工具本身

• 编码代理本擅长修 bug，许多批评实际是误用而非工具有限（少数人） > 大量帖子看似控诉代理，实则暴露的是人们如何误用它们（@benzible）
• 依赖 LLM 是心理与意志问题，自律者仍可得倍增效益（少数人）
• 此类混乱在 AI 前就存在于大厂与初创，AI 只是让“蹭别人工作”更明显（较多人）
• 只按回车不读代码是态度选择，善用以好奇心驱动反会读更多（少数人）

认为决策责任因 AI 多层生成而空心化

• 从策略备忘录、工单到代码全由 AI 生成，真实意图与决策者消失，组织基于揣测运转（少数人） > 环境中已没有真实具体的目标，全被投机与焦虑替代，恰似要避开的错乱超级智能（@zero_shift）
• 责任仍归工程师，出事背锅的不是 LLM，保持理解者反而更值钱（较多人）

编程写作是人内化理解与团队沟通的认知实践

• 写代码经重构内化方能推理交流，整个团队沟通才能从愿景到产品（较多人）
• 人必须为自我定义程序行为，若 AI 定义则人未真正写程序（少数人）
• 编程目的不仅是驱机，更是迫使程序员深化对问题的理解（少数人）

工程角色正演变为通才叠加 AI 杠杆

• 纯写 PR 的工程师角色萎缩，未来是兼具分析、架构与产品意识的“技术成员”用 AI 交付垂直切片（少数人）

有价值的补充

• 奥卡姆剃刀视角：变量只有 AI，问题就是 AI（@runarberg）
• 历史类比：1983 年担忧文字处理致写作干瘪，与今忧 AI 降编程质如出一辙（@Razengan）
• 长跑“负拆分”类比：纵容直接喷 AI 输出的公司短期领先，但坚守理解的团队长期可反超（@tangled）
• 需做“负责任的人在环”：不手敲但懂查错修复，避免沦为肉代理（@raahelbaig）