问题不在于 AI 代码，而在于不了解系统架构或意图
生成式 AI 工具正越来越多地编写生产环境中的大量代码，但许多工程师认为，真正的瓶颈只是从“敲代码”转移到了“理解”：系统架构、意图以及长期可维护性。评论者描述了一些组织，其中规格说明、工单、代码甚至高管备忘录都由 AI 生成，这侵蚀了人的所有权、心理模型和责任感，并激励“vibe coding”和快速功能输出，而不是可靠性。也有人反驳说，只要团队坚持人工审查、清晰的架构抽象，以及仍然知道系统做什么、为什么这么做的“负责的人在回路中”，AI 就可以成为强大的加速器，甚至帮助理解遗留系统。
AI “解决了编码” vs 现实
- 有人认为 LLM 已经实际上“解决了编码”：你可以通过自然语言（需求、规格、测试）交付功能，让代理编写代码，而且往往比人类团队更快。
- 也有人强烈反对：LLM 生成的代码被视为不安全、低效、充满 bug 的“slop”，也许能编译，但在健壮性、性能和长期质量上都不合格。
- 还有一种折中观点：LLM 大幅降低了机械性编码的成本，但软件工程（需求、权衡、架构）并没有被解决，如今反而更重要。
架构、意图与可维护性
- 许多人认为真正的瓶颈是系统架构、意图和可维护性，而不是逐行编码。
- 担忧在于：如果 AI 生成了大块代码，却没人深入理解它们，所有权以及对系统进行推理的能力就会退化。
- 也有人反驳说，AI 可以大大帮助理解遗留系统（摘要、交叉引用）并进行重构，只要使用得当，维护反而会更容易。
组织激励与虚无主义
- 若干评论描述了这样的环境：高管要求“AI everywhere”，使用 AI 写文档、工单和备忘录，并通过表面的 KPI 衡量产出。
- 这会鼓励“slopmaxxing”：不加审查地交付 AI 输出，把责任推给工具，并把工作看作在不可避免的裁员前的临时捞一笔。
- AI 被视为一种方便的方式，用来漂白承诺、责任和功劳：产物看起来很精致，但缺乏清晰的人类意图或可追责的作者。
理解、学习与心理模型的流失
- 广泛的担忧是：持续依赖代理会削弱心理模型；人们通过把内容粘贴进 AI 来调试，而不是靠推理，因此从未内化系统如何工作。
- 一些工程师表示，上手和做功能在一开始感觉很容易，但几个月后才发现自己仍然不理解代码库。
- 另一些人认为，有动力的人仍然可以把 AI 当作导师深入学习；缺乏理解被描述为心理和文化问题，而不是技术上的必然结果。
变化中的角色与职业路径
- 有人预测，角色会从“打开 pull request 的人”转向更接近产品管理或“技术人员”的混合角色，负责引导代理和系统。
- 也有人担心传统的从初级到高级的培养路径（数千小时的实操编码）会崩溃，使未来的技术负责人基础不够扎实。
- 分歧在于：这究竟会带来对高层次系统思考者的更多需求，还是导致商品化和裁员。
积极体验与乐观
- 有人报告生产力提升了 10 倍：快速功能开发、devops 任务、测试，甚至对丑陋遗留系统的复杂改动，都因 AI 而变得可行。
- 在拥有巨大旧代码库且语言冷门的领域，AI 被形容为“天赐”，用于分析和现代化改造。
- 少数人预见 AI 会让维护和重构更便宜，从而支持持续重写，而不是背负深重的技术债务。
历史连续性与抽象漂移
- 多条评论指出，这只是长期趋势中的又一步：从汇编到 C，到高级语言，再到 AI，每一波都隐藏了更多复杂性，并缩小了理解底层的人群。
- 也有人认为，大型组织在 AI 出现之前就已经存在不透明的决策和脆弱的系统；AI 主要是加速并暴露了既有失能，而不是从零创造了它。