AI 写代码不可怕，可怕的是你不再思考
Beyond Recall and the Illusion of Competence
关于 AI 编程，人们要么觉得它生成的代码烂到无法修复，要么认为它将彻底取代程序员。但我觉得这两种观点都错了，因为它们只盯着“谁在写代码”这件事。事实上，我们从未真正靠记忆写出所有代码，也从未只拥有自己亲手写的系统。真正的风险在于，当我们把调试和解决问题的过程也外包给 AI 时，我们失去了构建系统心智模型的机会。这种“能力幻觉”会让开发者在遇到 AI 无法解决的难题时束手无策。对于初级开发者而言，跳过那些痛苦的调试过程，意味着永远无法积累真正的经验。AI 应该用来处理样板代码和语法，但架构决策、问题理解和系统设计必须掌握在你自己手中。
你并不是通过成功修改系统来学习它，而是当你能够解释系统为何失败时，你才真正具备了成功修改它的能力。
HN 评论区
31- MarkusQ
> 所以从 Stack Overflow 复制一段有用的代码一直以来都是被接受的？
这并非“一直以来都被接受”；“复制粘贴”（copy-pasta）不久前还是个贬义词，而且确实有人仅仅因为从 SO 复制代码并在不理解的情况下使用而被解雇。
- kayo_20211030
> 脱颖而出的开发者将是那些理解系统的人。
这一直以来都是真理。AI 并没有改变这一点。它只是重新排列了通往这种理解之前的一些要素。数量和速度是挑战，但理解和判断力才是区分优秀与卓越的关键。
顺便说一句：在我所处的领域，“系统”不仅指技术组件，还包括操作、调整和管理所有这些部分的人，以及控制一切的流程。
- WillEMac
我觉得软件中所需的冗余性确实有些令人烦恼。
例如，我在清洁技术领域工作过，那里的 PLC 编程控制着涡轮机，这里需要完全的理解。每一个 Bug 和每一行代码（LOC）都必须有人介入，这是值得花时间的。
另一方面，我也做游戏开发，我认为理解完整的调试过程并没有价值。例如，我在多人游戏中不小心把空格键释放绑定到了两个操作上，导致了合作模式的故障。我不需要去大海捞针般地查找这个 bug，那是时间的浪费。
> 如果编写代码变得廉价且人人可及，那么编写代码就不再是主要的差异化因素。脱颖而出的开发者将是那些理解系统的人。
我同意，尤其是关于限制和边界条件。在我正在开发的游戏里，要成为一名优秀的架构师，必须从根本上理解屏幕上 500 条由 GPU 控制与 CPU 控制的鱼及其局限性，否则游戏只能跑到 10fps。
- jebarker
我处于作者所描述的开发者光谱的中间地带。我每天使用 AI 进行有限的代码编写和大量的调试。我同意作者的观点，当你停止真正审查其输出，只是点击“接受”以体验生产力带来的快感时，事情就会脱轨。不过，我认为使用 AI 进行调试并不意味着你必须那样做，这仍然是一个选择。作为一个人机协作团队，我现在有很多次这样的经历：调试一个复杂系统中的问题，单凭我自己根本无法完成，或者无法在合理的时间内完成。我认为这并非反映我能力低下——而是因为 AI 带来了我永远无法具备的技能，比如阅读并关联在集群中不同计算节点上多次运行同一系统产生的海量日志。一旦它在 haystack 中找到那根针，我仍然可以花时间理解并推理它所发现的内容。
- ssivark
作者关于所有权的重要观点被淡化成了代码理解和调试。真正重要的不仅仅是已编写代码的所有权，还包括问题识别和解决方案选择的所有权。我最近从对话节奏的稍不同角度写过这一点 [1]，但共同的核心在于：我们希望 AI 充当认知伙伴，帮助我们理解局势、识别问题并做出决策——而不是让 AI 抢先“解决”问题，然后把负担甩给用户，让用户去搞明白到底发生了什么，以及这与初衷只有微弱的关联。
[1] https://woventhought.substack.com/p/ai-assistants-need-adapt...