昨天，我们介绍了吴恩达对 AI 时代工作效率的观点。他认为，随着人工智能的发展，未来不仅会出现“10 倍工程师”，各行各业都可能诞生“10 倍专业人士”——这些人将通过对 AI 的利用在各自领域创造出远超常人的价值。但在这种光明的前景背后，似乎还潜藏着另一面现实。
最近，一篇题为《新的初级开发人员实际上无法编码》（New Junior Developers Can’t Actually Code）的文章在硅谷科技圈引发热议。这篇博客文章短短几天内就获得了几十万人围观，马斯克、Deedy Das 等行业大佬也参与到了这场讨论之中。
在文章作者 Namanyay 此前的另一篇文章里，他提到了自己的一次经历。在不久前一次 ChatGPT 服务中断期间，当 Cursor 编辑器无法使用时，他发现面对 AWS 的错误提示竟束手无策。“在 12 年的编程生涯后，我居然在自己的专业领域变得更糟糕了。这不是夸张，这是软件开发者们正在面临的新现实。”作者在文章中写道。
这种能力的衰退是一个潜移默化的过程。首先是不再阅读技术文档，因为 AI 可以即时解释一切；然后是调试能力的下降，开发者们开始不假思索地复制粘贴错误信息；最终，深度理解能力受到影响，程序员们不再花时间去理解解决方案的原理，而是简单地实施 AI 的建议。“我变成了一个人形剪贴板，仅仅充当了代码和大语言模型之间的中介。”作者如此形容这种现象。
在最近的文章中，作者又进一步指出软件开发行业正处于一个关键的转折点。当下的初级开发人员普遍依赖 Copilot、Claude 或 GPT 等 AI 工具进行日常编程工作。表面上看，这些新手程序员的代码输出速度确实比以往更快，但当深入探讨他们对所写代码的理解程度时，问题就显现出来了。“代码能运行，但是问他们为什么要用这种方式而不是其他方式来实现？一片沉默。问到边界情况的处理？一脸茫然。通过与问题搏斗而获得的基础知识，在他们身上完全缺失了。”
作者通过对比新旧两个时代的学习方式，展现了这一现象的成因。在 AI 工具普及之前，程序员遇到编程难题时，需要首先在 Google 上搜索，然后在 Stack Overflow 这样的技术社区中寻找类似问题的解答。这个过程虽然耗时，但程序员能从其他开发者的思考过程和详尽讨论中获得深层次的理解。
作者用自己 12 年前在 Stack Overflow 上提出的一个关于 JavaScript 中一元加号运算符的问题为例，展示了当时社区中开发者互助的深度。解答者不仅详细回答了问题本身，还扩展了大量相关知识点，帮助提问者建立起更完整的知识体系。
“我的原始问题当然得到了彻底的回答，但他并没有就此止步。我学到了很多新的事实。有些我甚至不知道存在，还有一些我本来不想知道。但现在它们永远地刻在我的大脑里了。”
然而现在的情况却大不相同。“新一代开发人员甚至可能都不知道 Stack Overflow 的存在。”作者写道。他们只需将错误信息复制粘贴给 AI 助手，就能立即得到解决方案。有些人甚至觉得切换到浏览器标签页都很麻烦，而是选择使用集成了 AI 功能的编辑器，在一个界面内完成所有操作。这种即时反馈虽然便捷，但导致他们失去了通过深入思考和探索获得全面理解的机会。
作者通过一张对比图展示了这种差异：使用 AI 能够更快地得到答案，但获得的知识往往流于表面。相比之下，通过阅读专家讨论虽然速度较慢，但能够帮助开发者理解不仅是“是什么”，更重要的是“为什么”。“想想你认识的每一个优秀的开发者。他们是通过复制解决方案成长起来的吗？不是的。他们是通过深入理解系统和理解其他开发者的思维过程才达到今天的水平。而这正是我们正在丢失的东西。”
这种依赖甚至正在改变程序员的情绪和学习体验。作者观察到，以前解决新问题是编程过程中的一种乐趣，而现在如果 AI 无法在 5 分钟内给出解决方案，开发者就会感到沮丧。“我们不是在借助 AI 成为‘10x 开发者’，而是在变得对 AI 十倍依赖。这两者是有本质区别的。”作者警告道。
作者本人也在开发一款 AI 驱动的开发工具。正是这种双重身份，让他对当前的局势有着切身的思考。“说实话，我无法摆脱一种感觉，那就是我可能正在助长侵蚀我们集体技能的问题。”他在文章中坦言。
不过，作者并不主张完全抛弃 AI 工具，这在当前环境下也不现实。他提出了一种平衡方案：“无 AI 日”。具体来说，就是每周选择一天完全依靠自己的能力编程：仔细阅读每一条错误信息，重新使用调试器，从零开始编写代码，通过阅读源代码而不是询问 AI 来理解问题。“老实说，这个过程确实很痛苦。我感觉自己变得更慢、更笨拙，也更容易感到挫败。但我也能看到区别：我与代码之间的联系更强了，对代码的主导权也在慢慢回来，这些在依赖 AI 的过程中都逐渐消失了。而且，我学到了更多东西。”
这种趋势对于新手程序员来说尤其值得担忧。“此时此刻，在某个地方，有人正在学习编程。他们可能永远不会体会到完全依靠自己解决问题的满足感，永远不会经历通过数小时与 bug 搏斗而获得的深刻理解。我们正在培养一代开发者，他们知道如何向 AI 提出正确的问题，但不理解答案的含义。每当 AI 服务中断时，他们就会暴露出越来越无助的一面。”
针对这种状况，作者提出了几点具体建议：首先，他强调要改变使用 AI 的心态。与其把 AI 当作一个简单的答案提供者，不如把它当作一个学习的工具。当 AI 给出解决方案时，我们应该追问它为什么这样做，理解每个决策背后的逻辑。这个过程可能会花费更多时间，但这正是学习的精髓所在。
另一个重要的建议是重新建立与同行的深度交流。在 Reddit、Discord 或 Mastodon 等平台上，经常能看到富有启发性的技术讨论。这些讨论往往能带来新的视角，让人恍然大悟：“原来还可以这样思考这个问题。”这种观点的碰撞和交流，正是 AI 无法完全替代的宝贵经验。
代码审查的方式也需要改变。与其仅仅关注代码是否能正常运行，不如将其转变为一次深度交流的机会。开发团队可以讨论：为什么选择这种实现方式？还考虑过哪些其他方案？这样的讨论不仅能帮助团队成员更好地理解代码，也能培养更全面的工程思维。
作者还特别强调了“从零开始”的重要性。以身份认证系统为例，虽然 AI 能够快速生成一个完整的方案，但不妨先尝试自己动手实现。也许写出的代码不如 AI 生成的优雅，但这个过程中获得的深入理解是无可替代的。像滚雪球一样，这种知识会逐渐积累，最终形成扎实的技术功底。而这些建议的核心，就是在保持效率的同时不放弃对技术的深入理解。
这组文章发表后在科技圈引发热议。一些资深开发者表达了类似的担忧，认为当前的发展趋势可能会导致整个行业技术水平的实质性下降。特斯拉 CEO 埃隆·马斯克评论：“人们现在也不知道如何在没有电子地图和 GPS 的情况下在城市中找路”。
前 Glean 和谷歌搜索创始团队成员 Deedy Das 回应道：“如果 Google 地图每五次就会出现一次幻觉，记住如何到达目的地就变得非常重要了！”他认为，理解代码的本质仍然至关重要，因为“AI 是一个有漏洞的代码抽象层”。
Deedy 通过 Python 和 C++的关系来解释这一观点：“Python 本质上是 C++ 之上的一个抽象层，它让我们不必关心内存管理。这个抽象是可靠的，因为它具有确定性，我们从不需要担心内存问题。但如果 Python 程序会因为内存问题而随机失败，那它就不是一个好用的抽象层。”他指出，当前的大语言模型就处于这样的状态——虽然能完成许多任务，但大多数开发者都知道，当代码库复杂度达到一定程度后，性能就会下降，这时候就需要真正理解代码才能找出问题所在。“这个抽象层漏洞太多，所以如果要称自己为软件工程师，理解代码仍然是必不可少的。”
正如 Namanyay 所说：“未来的问题不在于我们是否使用 AI，而在于如何使用它。也许，我们能找到一种方法，将 AI 带来的效率与我们需要的深度理解结合起来。当前的 AI 还没有强大到能完全取代程序员的地步，但随着它的进步，情况只会变得更加严峻。真正的问题不是 AI 是否会取代程序员，而是我们是否正在取代自己。”
AI 到底会让我们变成“职场超人”还是“文盲”？这个问题现在似乎也看不到答案。但比起担心这个问题，不如先试试作者建议的“无 AI 日”，做一天“AI 当道时代的手工异类”。花一天时间，把 AI 助手暂时关掉，完全靠自己写代码。没准这个小小的尝试就会让你对自己的能力，对编程，甚至对整个行业有新的认识。毕竟，真正的编程能力，从来都不是靠工具堆砌出来的。
参考资料：
1.https://nmn.gl/blog/ai-and-learning
2.https://nmn.gl/blog/ai-illiterate-programmers
3.https://x.com/deedydas/status/1891369030604525831
运营/排版：何晨龙