我们并非都是糟糕的开发者：AI 无法取代真正理解代码的人

我一直讨厌这种想法，认为我们都是糟糕的开发者，根本不知道自己在做什么。或者那个老掉牙的笑话，说编程就是从 Stack Overflow 上复制东西，直到错误消失，任何为自己的工作感到自豪的人都是在自欺欺人。我知道这通常应该是个玩笑。我只是从来不觉得它特别好笑。

当然，我写过糟糕的代码。我也花了多年时间学习如何写出更好的代码，如何阅读代码，如何调试代码，以及如何识别那些看起来完全合理的东西将会引发问题。许多其他开发者也一样。为什么我们谈论这些努力时，就好像它们都不算数？

现在我不停地看到同样的推理被用来论证 AI 将取代我们。反正你只是在复制代码。你使用的库不是你写的。你并不理解你技术栈的每一个部分。那么到底有什么可取代的？

嗯，其实有很多。能够阅读代码并真正理解它的作用，会是一个不错的起点。

我不相信 AI 会完全取代开发者，因为仍然需要有人具备那种理解力。我指的是真正理解它，而不是扫一眼 diff 就断定它看起来没问题。需要有人知道它为什么能工作，它会在哪里失败，以及当你修改它时应用程序的其余部分会发生什么。

否则一切就是个黑箱。你提出需求，代码就出来了，然后你希望它做了你想做的事。让工具也解释一下，当然可以，但仍然得有人理解得足够多，才能判断那个解释是否合理。这是一种技能，我厌倦了看到它被那些主张我们从来就没有任何技能的人所否定。

有人写了那个库

库这个论点对我来说尤其奇怪。你使用 PostgreSQL 却没有自己写过数据库，所以你从一开始就从未真正理解 SQL，现在你就没资格质疑 LLM 生成的 SQL 了？

理解 SQL 和实现数据库引擎是不同的技能。你可以在没有写过 PostgreSQL 的情况下理解连接、事务、隔离级别、索引和查询计划。你可以解释为什么一个查询会重复行，为什么索引没有起作用，或者为什么两个单独运行都完美的交易在同时运行时会产生错误的结果。这是真正的理解，而且需要付出努力才能培养出来。

具备这种知识的人可以阅读生成的 SQL，并发现一个返回看似合理但结果不正确的查询。他们能识别出连接改变了你正在计数的内容，NULL 的行为与作者假设的不同，或者一个在一百行上看起来没问题的查询在一千万行上会吃力。他们能解释问题、演示问题并修复它。作为他们理解自己在做什么的证据，你还想要什么？

如果你对理解 SQL 的定义要求你自己构建数据库引擎，那你就不再是在衡量 SQL 知识了。你是在要求另一份工作的专业知识，以便否定某人实际拥有的专业知识。

有人写了 PostgreSQL。人们设计它、实现它、调查 bug、争论权衡并改进它。编译器、框架以及你所构建的任何东西底层的操作系统也是如此。依赖他们的工作，就是承认其他人拥有值得使用的专业知识。

这怎么就成了没有人拥有任何专业知识的证据？

我在 zenkai 中使用 Qt，是因为我想要一个良好的界面，又不想先构建一整套 GUI 工具包。我仍然必须理解我的应用程序如何与它交互。当启动很慢时，知道哪些工作发生在布局期间、哪些工作发生在绘制期间，以及我在哪里请求图标，这些实际上都很重要。Qt 做了大量工作，并不会让这些问题消失。

没有人理解现代计算机的每一层。这从来都不是要求。你需要足够的理解，以便对你负责的部分做出决策，在假设不再成立时察觉出来，并知道接下来该调查哪里。有时这意味着阅读文档。有时这意味着阅读依赖项的源代码。有时这意味着去问比你懂得更多的人。

我不需要了解 Qt 的每一个细节才能使用它。但如果一个问题牵涉到 Qt，我需要愿意去读那些代码，或者找到能帮我理解它的人。安装一个依赖项并不会让那永远成为别人的问题。

查资料从来都不是丢人的部分

Stack Overflow 的那个笑话让我同样感到困扰。找到能帮你解决问题的解释，和粘贴一些你不理解的东西直到应用程序碰巧能运行，这两者是有区别的。

我从别人的代码中学到过东西。当然学过。我共事过的几乎每个人都是如此。有用的问题是，在你找到答案之后会发生什么。你能解释它为什么在这里有效吗？你能发现那个不适用于你应用程序的假设吗？当需求变化时，你能修改它吗？

这需要技能，而且这是一种你可以提升的技能。把整个过程简化为复制粘贴，就丢掉了某人真正学到东西的那部分。

这也会给编程带来一个糟糕的入门体验。想象一下，你终于理解了一个难题，正为此兴奋，却被告知其实没有人真正理解任何东西，大家都在装，在意把它做好是丢人的。我们为什么会希望这成为人们加入的文化？

我更愿意告诉别人：是的，这很难；是的，人们会越做越好。你不需要是天才才能胜任。你需要时间、练习、好奇心，以及愿意解释事情而不会让你因为提问而感到愚蠢的人。

总得有人能读懂它

想象一个 agent 生成了一项更改，用来重试失败的请求。正常路径的测试通过了。重试测试也通过了。但如果第一个请求成功了，只是响应丢失了，会发生什么？重试会不会向某人重复收费？系统在哪里防止这种情况，而生成的更改是否保留了这一点？

这些是关于代码如何融入系统的问题。我想要有人能够追踪这个请求，理解什么会被提交，并解释当网络在最糟糕的时刻失败时会发生什么。读一下函数然后判断它看起来合理，是不够的。

你可以让另一个 agent 来审查它、编写测试或解释它的推理。这可能有帮助，但如果团队里没有人能判断这个解释是否正确，那会怎样？我们要求了第二个答案，却不知道如何检验第一个答案。

这也适用于人类编写的代码。同事说它能用，从来都不是停止追问如何实现的充分理由。审查的意义在于，有人带着足够的理解来质疑这个实现，包括其作者遗漏的部分。

而软件在不断变化。理解当今实现的人，能在明天的需求使其中某个假设失效时及时发现。如果我们只有一个提示词和一个看起来能用的应用，那么每次变更都变成又一次请求，我们只能希望它能产生正确的结果。

这就是我看不到会消失的工作。AI 可能会改变开发者敲多少代码，或者一个项目需要多少人。我确信工作会变。但如果我要对一个应用负责，我就需要理解我们往里面放了什么。有更多代码要审查，只会让这一点更加重要。

我们发明了枪。你为什么还在练武术？

对我来说，这个论点本质上归结为：

既然我们发明了枪，为什么这些白痴还在练武术？

如果你认为一个人从武术中得到的唯一东西就是伤害他人的能力，我能理解你怎么会得出这个论点。但你错过了几乎一切让人们花多年练习它的东西。

掌握一项技能需要时间。在你以为自己已经理解基础之后，你还要反复练习它们。有人纠正你确信自己做对的事情。你练习，进步一点，卡住，然后还是回来。知道一个动作应该是什么样，和能够正确地做出它，是非常不同的两件事。

这需要耐心和自律，但它也教会你耐心和自律。你学会接受纠正而不把它当作侮辱。你学会今天做不好某件事并不意味着你永远不能擅长它。你还学会在每次练习后进步小到察觉不到时继续努力。即使你从不打架，这些也是值得带入余生的事情。

所以当有人问，既然有了更强大的工具，为什么还要费这个劲，我的反应是：为什么那会让那些年变得毫无价值？你仍然发展了技能。你仍然成为了一个能够坚持做一件困难的事足够久以理解它的人。你不会因为有人发明了通往某个特定结果的捷径就失去这些。

我对编程也有同样的感觉。花几个小时追踪一个 bug 可能极其令人沮丧，但通过形成解释、测试它、发现你错了再试一次，你会学到一些东西。最终你会更善于质疑自己的假设。你不再随机改动东西然后祈祷。你学会跟随证据，即使它指向五分钟前你还非常自豪的代码。

阅读最终的修复并不能给你所有这些经验。它当然能教你一些有用的东西，但看到答案和培养出找到答案的判断力是不同的成就。当你审查别人的代码，包括 AI 生成的代码时，这种判断力正是你所带来的东西的一部分。

我不是说每项任务都需要成为一场受苦的练习。使用工具。能跳过枯燥的部分就跳过。但不要把能够快速得到答案与已经培养出评估它的理解混为一谈。某人花在学习上的那些年仍然算数。

有了 zenkai，我可以花一个晚上做一个小优化，因为我想理解它。没有人在等我为这些时间开账单。我想要一个项目，让我能追随那份好奇心并不断变得更好。告诉我本可以跳过有趣的部分，听起来不像是多大的改进。

工具仍然需要判断力

这一切都不需要拒绝 AI。如果它能帮你构建一些东西，就用它。如果它能让你免于做你不喜欢的工作，那很好。我不认为手动输入每一个字符就能让人成为更好的开发者，就像使用一个库会让人变得更差一样。

但我确实在意对结果所做的判断。它解决的是正确的问题吗？当输入错误时会发生什么？对于它实际将被使用的方式，性能可以接受吗？下一个人能维护它吗？无论代码来自哪里，这些问题仍然需要答案。

假设一个 agent 产生了一个缓慢的实现。我想知道它为什么慢。是算法、配置，还是不必要的数据库查询？能够找出并修复它是有用的，无论第一个版本是来自一个 agent、一位同事，还是六个月前的我。

我宁愿阅读代码、检查配置并测量一个不同的实现，也不愿坐在一起附和说参与其中的每个人一直都是白痴。

而且，如果有人足够理解问题，能够修复输出，那正是这场争论试图否定的专业知识。

我希望人们关心他们的工作

我之前写过关于怀念好奇的开发者，那种因为想知道自己能否做到而构建一些东西的人。这是同一种挫败感的一部分。我不希望对新工具的热情依赖于对在它到来之前享受这项工作的人的蔑视。

我见过很多糟糕的代码。我也读过教会我一些东西的代码，并与那些能发现我会花几天寻找的问题的人共事过。我不会因为这样能让关于 AI 的争论更容易获胜，就假装这种专业知识不存在。

对 AI 让你能做的事情感到兴奋吧。给我看看你用它的有趣作品。解释一下它帮了什么忙，以及你仍然必须弄清楚什么。我更愿意听到那个故事，而不是又一次解释为什么我们从来就没什么技能。

我喜欢编程，我会继续做下去，因为我享受它。但我为开发者所做的论证不止于想保留一个爱好。如果我们要依赖一个软件，我希望有人能阅读它、质疑它，并解释为什么我们应该信任它。真正理解它，包括那些丑陋的部分。

让 AI 写代码吧。仍然需要有人知道我们构建了什么。

感谢您花时间和耐心阅读这篇文章