最近看到了两篇有意思的内容，一个是 DeepSeek 工程师刘胜与的文章，讲述 AI 编程导致他失去了「手写的浪漫」，另一个是 Matt Pocock 和 Uncle Bob（Clean Code 的作者，软件工程大佬）的访谈。Uncle Bob 开始用 AI 做他的变异测试，仍然玩得不亦乐乎。访谈中还提到，在 AI 编程的时代，代码基本功仍然重要。这两件事情以某种方式让我联想到了一起。
因为在最近公司的招聘过程中，我们也有类似的感受。随着 AI Coding 成为主要的编程方式，我们在面试中不再会考察 LeetCode 式的手写代码，以及传统的基础知识（即所谓的「八股」）。另外一方面，我们意识到「古法编程」经验在软件的可维护性上仍然是不可或缺的，所以我们会以某种方式考察候选人的古法编程经验，不太喜欢招经验只有 2~3 年以内，也就是在 AI Coding 覆盖的边界内成长起来的工程师们。
这两点看似有些相互矛盾，但实际上是一件事情的一体两面。这件事情就是：我们今天究竟该用什么样的方式去构建我们的软件？ AI 可以写代码，可以 review 代码，可以写文档，可以分配任务。在这个过程中，工程师究竟起到什么样的作用？这是目前软件开发当中至关重要的问题。
想到这个，我的思路不禁又回到了大学里面上《软件质量保障》课程的时候。老师跟我们讨论一件事情：架构师是否需要有写具体代码的能力。我的观点是肯定，因为毕竟整体的架构就是由细节的代码拼起来的，要能够构建一个大的乐高积木，显然需要对细节是清楚了解的。但是老师认为不是，架构师可能更多从宏观抽象的维度去考虑系统就够了，而不需要去管具体的代码细节。
现在想想，这两个观点其实说得都对。它正好对于了现在 AI Coding 开发当中的一体两面。现在 AI 与人的协作方式，实际上使得每个工程师都变成了原先架构师的角色。于是那个从前拿来问架构师的问题，现在变成了拿来问每一个人。带入从前架构师的视角，就能够理解这个问题的纠结之处了。
架构师究竟要不要掌握代码细节？对应到现在，AI Coding 的时候，我们究竟需不需要代码基本功？现在你完全不需要知道具体的语言的语法，不需要知道一些具体流程是怎么操作的，也能够很顺利地完成任务。毕竟现在 Agent 太过强大，完全可以为你代劳。这就是所谓的「架构师不需要写代码」。但是另外一方面，你又必须知晓个大概，知道应该选择什么样的语言、架构，每种技术方案的优缺点是什么，又该如何根据实际场景做权衡。如果这些不清楚，你很可能根本做不出正确的决策，即使有 Fable 或 Astra 辅助你。
你会发现这又是一个老生常谈的问题的延续，从之前的架构师是否应该写代码的争论，到现在工程师是否应该有手写代码能力的探讨。或许你只要翻开 20 年前那些经典的软件工程书籍，就能够找到答案。
然而，从另一个角度来看，关于如何让自己成为架构师、具备架构师的能力。在从前和今天也许并不相同。在从前，成为一个架构师是困难重重的，你需要去做足够多的事情，你需要冲破对于你资历和能力的不信任，冲破公司里螺丝钉式分工的阻碍，冲破日常琐碎的事务；然后，最关键的，你还要能够参与对自己的成长有帮助的项目，从中提升自己的能力。
在现在，这件事情已经变得足够简单了。AI 可以帮你处理很多琐碎的工作，你可以有更多的时间去思考宏观的决策。项目推进的速度也能够让你很快看到一个架构的生命周期演进。
但是这一切并非没有代价。AI 编程时代最大的问题在于你可以轻易地把自己的思考外包出去。你可以让 AI 帮你做任何事情，任何你不懂的地方都可以让 AI 去探索，去决策，自动找到合适的道路。人总是倾向于沿着阻力最小的路径前进，AI 不仅帮你完成了各种具体的事务，还帮你完成了所有的思考和判断。甚至你写的文档也都是 Opus 4.8 风格的诡异而扭曲的语句。你变成了 AI 的传声筒、审批机器，变成了 Agent Loop 中的一个工具。
如果你真的想成为足够好的工程师（或者说，架构师），你需要能够有所成长。也许一些任务在第一次做的时候依赖 AI 的探索。但是你需要去理解任务是如何完成的，理解其中进行了哪些关键的决策，理解系统究竟被搭建成了什么样子。你需要先去理解这些，然后下一次的任务你才能够做得更好更有把握。
你会发现这其实就是你的 daily work。没错，你只需要考虑如何更好地完成正常的工作，就可以不断提升自己的架构师能力了。只要跟上 AI Coding 发展的阶段，你就会自然而然地让 AI 去完成具体的工作，而自己去思考宏观抽象的维度。而随着 AI 能力的进化，它会有能力去做更多具体的工作，并且让你去思考更宏观、更抽象的维度，从而不断前进。
在古法编程时代，我所能做的最有心流的事情大约就是写出一个完美无缺的代码模块：高内聚、低耦合，通过了所有单元测试。我想它在性质上应该比较接近 LSY 所说的算子开发。写这样的东西确实可以非常投入，在没有会议和其他工作干扰的情况下可以写一整天，写到筋疲力尽。但奇怪的是，写完代码之后的快感却不剩多少，没有写的过程中那么有感觉。
我想，也许是因为这样的工作是「线性」的，大体上还是投入时间，按照有既定路线的最优解去做这件事情。对于一个代码模块来说，这个最优解就是 SOLID 原则。当然，能够做到 SOLID 已经足够优秀，很多平庸的工程师一辈子都做不到。刘胜与所做了算子优化，当然更有难度，也更吃智商和经验，但是某种程度上，仍然是这一类工作的范畴。
AI 的出现给了我们所有人一个耳光，告诉我们这样的工作是完全的简单工作。有确定性最优解的工作，AI 用强化学习就可以飞速地逼近，迅速进化到所有人都不必再手工做的地步。它告诉我，不要再去花一整天的时间去写一个完美无缺的模块。于是人们开始惊呼，自己过去的才华被埋葬了。
我也埋葬了自己过去的才华，在 Claude 3.7 以后，我就开始让 AI 去做这个完美的模块，即使自己写会更有意思。因为我可以腾出时间去体会更多我觉得有意思的事情。君子不器，我不希望总是沉迷在写一些有确定最优解的代码模块上，也不希望在简历上写一个虚无缥缈的「代码能力优秀」然后还需要自证。我希望能够每天做好自己的本职工作就能获得成就感，我希望能够像 Uncle Bob 一样，始终有兴趣去捣鼓自己喜欢的东西，无论是用古法编程还是 AI 编程。
作为一个工程师，处在当今的时代，无疑是迷茫的，因为时代像一团迷雾，你不知道下个方向该往哪里走，什么是确定要发展的方向。
但对于喜欢软件工程和软件架构的开发者来说，没有什么是比每个时代更令人兴奋的了。上一个令人兴奋的时代也许还在 40 年前。没错，软件工程从某种程度上已经固化了 40 年。你可以看到，那些软件开发的经典理论都是 70 年代的前辈提出的。在那个时候软件工程还是前沿课题，而在此之后软件工程领域的各种研究，无非都是缝缝补补，从一些砖缝里面抠出来一些东西。
我们有幸看到生成式 AI 让软件工程进入了一个全新的时代。站在今天这个时候，就仿佛回到了 70 年代那个软件工程理论波云诡谲的年代，不断有新的方法论提出。从 Harness Engineering 到 Loop Engineering，你可以。没有确定的答案或者一定正确的道理，因为 AI 的能力边界也在不断变化。你能够参与其中，用自己的实践去体会其中微秒的点，去肯定或否定任何一个方法论，或者你能够自己发明一个，然后等着它变成大家公认的观点。
软件工程的问题长期存在，而软件工程的转折点就在当下。毕竟能有一次体会到架构师的感觉，真的很不错，不是吗？