AI正在将工程师转变为农民、医生和园丁 · aswinmohan.me

# AI 正把工程师变成农民、医生和园丁 · aswinmohan.me Source: https://aswinmohan.me/ai-doctors-engineers 想想 2022 年之前的软件工程。我们是从零开始构建系统的。我们了解复杂系统是如何工作的，因为是我们亲手搭建的。即使我们不清楚整个系统的全貌，我们也知道该去问谁。哪怕几年后再接触同一套代码库，翻找几小时就能唤起当年创造它的美好回忆。 处理遗留代码库时，我们会尝试修改，观察结果，再继续调整。但每一次改动都是我们做的，每一次改动都会加深我们对代码库的理解和掌控。就像忒修斯之船，每一次修改都让这个陌生的对象离我们更近，更像我们自己创造的东西。我们曾像神一样，沉醉于创造的艺术。 如今，我们从一段 prompt 的种子开始“生长”代码库。无论是庞大复杂的树，还是小巧的个人植物，一切都被“培育”出来而非“创造”出来。我们播下种子，向神奇的 AI 实体缴税来加速过程。这些实体最初只能生成滑稽的杂草，但它们不断扩展自己的能力，最终长出了能卖钱的果实。这些植物的创造过程被加速了。而魔法实体的需求变得如此之高，以至于整个村子都在扭曲自己的经济模式来付钱让它们种更多的树。 生成代码的速度比手写快一个数量级，唯一的限制是你愿意花多少钱买 token。所需的时间和意识投入也下降了一个数量级，这一点从那些在 agent 替我们耕作时播放短视频的“脑腐” IDE 的兴起就能看出。 如果输出完全符合需求的规格，那这一切会很棒。但事实并非如此，因为足够详细的规格本身就是代码。所以我们用的是 prompt，它只是需求的近似。由于代码是从近似的 prompt 生成的，我们需要修改才能让它符合要求。 如果我们投入工程精力亲手创建系统，我们就能获得做出修改所需的理解。但生成的代码对我们来说就像遗留代码一样陌生。于是，我们从农民变成了医生。 医生在人体的复杂系统上工作，而他们并没有创造这个系统。他们也找不到创造这个系统的同事。所以他们必须先学习这个系统，然后再实验。他们尽力做出修改，观察这些修改的效果，根据结果调整下一步实验，并将学到的知识分享给自己和同行。这正是我们在自己不创建的代码库中做修改时所经历的过程：我们学习系统，然后实验。我们做出修改，观察效果，改进修改；如果效果不如预期，就撤销修改再试一次。 与之对比，如果我们是在自己创建的系统中做修改。我们会了解各个部分、它们如何交互、系统的瑕疵和脆弱点。这一切都是因为我们曾为这个系统付出过努力，从而获得了这种理解。我们会知道该做什么修改，修改会如何影响系统的其他部分，以及最适合做这个修改的位置在哪里。即使创造和再次访问之间隔了很长时间，模糊的记忆也能让我们处于更好的境地。这就像在夜间探索一个地方：是去一个从未去过的地方，还是去一个至少去过一次甚至多次的地方？显然，后者更容易。这使得在你自己创建的系统中做修改成为一个更愉快的过程，伴随着能力的持续提升。而现实中，我们却要穿越一个陌生的新系统。 如果我们用 AI 来替我们做修改，而不是自己动手呢？如果我们自己动手修改，我们对系统的理解会在每一次后续修改中提升。但如果把这个任务外包给生长出代码库的 AI 系统，我们就变得更像园丁。园丁通过修剪、照料和嫁接来改变植物。如果我们想要蓝色的花而不是黄色的，我们就嫁接系统的分枝，并希望支配系统生长的力量能推动它朝我们想要的方向变化。我们失去了更多的控制，实际上将按照复杂需求修改系统的能力降级为类似祈祷的过程：反复请求我们的 AI 模型生成一个可行且符合我们要求的输出。 基于 AI 的代码生成是不可思议的。我们能把高度专业化的、需要深度理解的编码工作复制成可重复、易生成的商品，这本身就体现了人类整体的能力。但每一次变革都有代价，我们付出的代价是能力的丧失。我们曾经是神，现在只是凡人，这在某种程度上让编码这件事变得不再那么有趣了。 如果我们将这种现象扩展到整个团队，尤其是那些严重依赖代码生成的团队，那么过不了多久，我们就会得到一个陌生的代码库，由一个对代码库零理解、且编码能力严重退化的开发团队来维护。这将造就一个脆弱的系统——它是被“培育”出来的，而不是被“建造”出来的；它通过实验来改变，而不是基于对整体的透彻理解。这会导致后续变革速度越来越慢，出现更多的安全问题以及难以修复的 bug。唯一的解决方案是手写代码。 我正在构建 Cycle (https://usecycle.co/)，一个面向中小企业的全能财务平台。与其做代码农民，我选择 95% 的代码由手写完成，Claude Code 只帮助处理一些单调的任务，比如将 React 组件拆分成更好的组件。这让我在处理这个将处理客户财务方面复杂系统时，获得了更高的理解力。同时，这也让整个编码过程变得更加愉快，回到了 AI 出现之前的水平。这样做对吗？我确实认为是正确的。 技术栈是 Elixir、Phoenix 和 Inertia，这套组合为兼职独立开发者提供了惊人的开发速度。但同时，手写代码让我对整个系统有了更多想法：哪里可以改进，如何改进——无论是作为代码制品还是作为商业产品。它也在提升我作为开发者的能力。它还帮助我设计出更加连贯的功能。我认为这是一种来之不易的竞争优势，会让后续每一次修改都更容易。 随着真正有能力的 AI agent 的出现，可能生成从一开始就完美无缺、不需要任何修改的系统，我的观点可能会改变。在那之前，我认为失去理解力是为产品速度付出的极其高昂的代价。我不想使用一种每次使用都降低我对系统的理解、让后续修改变得极其困难的工作流程。在那一天到来之前，我会坚持手写、自由放养式的代码。 ## 脚注 - 阅读此文可能会让你觉得我对农民和园丁的评价低于工程师，但事实并非如此。每次享用丰盛的饭菜时，我都对农民心怀感激，而我的母亲就是一位资深的园丁。这篇文章更多是关于工程师能力丧失这件事。