2026年5月，一篇题为"AI正在把工程师变成农夫、医生和园丁"的个人博客在Hacker News引发热议。作者Aswin Mohan用三个精准比喻揭示了AI编程工具普及两年后的隐秘代价——代码生成速度越快，开发者的代码理解能力退化得越严重。
事件回溯：一篇博客引发的集体反思
2026年5月24日，独立开发者Aswin Mohan发表了一篇名为《AI is turning Engineers into Farmers, Doctors and Gardeners》的博客文章。这篇文章没有轰动性的数据，没有融资新闻的噱头，却在24小时内被HN社区频繁讨论，因为它触及了2026年AI创业者最不敢问的问题：我们用AI写代码，是不是在把自己写废？
Mohan开篇就是一记重锤：
"2022年之前，我们是软件系统的建造者。我们知道复杂系统如何运作，因为是我们亲手搭建的。即使多年后重返代码库，几小时的挖掘就能唤起创建时的记忆。每一次修改都让我们对系统的掌控更强——我们是代码世界的神。"
"而现在，我们从一句prompt的种子中'种出'代码库。大的复杂的树，小的个人化的植物，一切都是种出来的，而不是创造出来的。"
这就是"农夫"隐喻的核心：工程师不再建造系统，而是播种prompt，等待AI生成代码。表面上效率暴涨，但生成的代码对我们来说就像一片陌生的森林——我们知道它存在，却不了解它的内部结构。
三个角色：从创造者退化为旁观者
Mohan定义了AI时代工程师的三个退化阶段：
阶段一：农夫（Farmer）— 播种prompt，收割代码
用一句prompt生成整个功能模块。速度是手写代码的十倍，金钱成本是订阅费。但代价是：你对生成的代码近乎一无所知。
他说得非常直白："足够详细的spec就是代码本身。既然spec只能是一个近似描述，那么生成的代码必然需要修改才能符合真实需求。但如果你亲手写的代码，修改过程会奖赏你理解系统；而AI生成的代码，你面对它就像面对一个陌生的遗留系统。"
阶段二：医生（Doctor）— 诊断陌生代码，实验性修改
当你需要修改AI生成的代码时，角色从农夫变成了医生。医生面对的是自己没有参与创建的人体系统——只能学习、实验、观察效果、根据结果调整下一次尝试。
"你是带着手电筒在黑夜里摸索一个从未去过的地方，而不是在曾经到访过的地方凭模糊记忆行走。"
阶段三：园丁（Gardener）— 修剪枝叶，祈祷方向
最危险的是第三个阶段：你不再亲手修改代码，而是继续用AI来改。
"如果你想让蓝花开出黄色的花，园丁会嫁接枝条，然后祈祷自然力量把生长方向推到你要的位置。你失去了控制权，把修改能力外包给了同一个让你不理解代码的AI。这本质上是一个祈祷过程——不断向AI模型发出请求，期望输出符合你的需求。"
Mohan警告说，当一个团队高度依赖代码生成，最终会得到一个"全员零理解的陌生代码库"，团队编码能力显著退化。系统变得脆弱——它是种出来的而不是建出来的，修改靠实验而非深度理解，最终导致变更速度下降、安全漏洞增多、难以修复的bug堆积。
直接回应："唯一的解药是手写代码"
Mohan给出的答案简单到近乎粗暴：手写代码。
他正在独立开发的金融SaaS产品Cycle，95%的代码亲手写，只用Claude Code辅助拆分React组件等机械任务。
"这让我对一个处理客户财务的复杂系统有了更高的理解。整个过程变得有趣多了，回到了AI之前的水平。"
他不确定这是否是"正确的做法"，但确信一点：
"用AI写代码减少我对系统的理解，每次使用都让未来的修改更难做。在真正能'一次生成完美代码'的AI出现之前，我不愿意参与一个让我越来越蠢的工作流程。在此之前，我选择手工、自由放养的代码（artisanal, free range code）。"
为什么2026年这些问题集中爆发？
这不是孤立的声音。过去48小时，HN上出现了多个高度相关的讨论：
- "Ask HN：AI编程Agent在跑的时候，你在干什么？" — 4分5评论。有人回复"刷短视频"，有人坦白"在另一个窗口继续工作"。一位用户写道："Claude Code的200次限额，我在前10分钟就能烧完。"
- "编程Agent正在让所有人患上决策疲劳" — 独立博客文章讨论了AI生成代码选项过多导致的选择瘫痪。每次AI给出3-5个方案，审查和选择本身成了新的认知负担。
- "ClickHouse团队：一年用AI Agent写代码的8条经验" — The New Stack报道了ClickHouse团队的真实数据。核心发现包括：AI生成代码的review成本往往高于手写代码；复杂业务逻辑场景的AI采纳率显著低于简单CRUD；团队最担心的不是代码质量，而是"知识流失"。
- 高盛CEO亲自撰文反驳"AI就业末日论" — 在《纽约时报》发表署名文章，直言AI不会消灭工作岗位，但会"从根本上改变工作的性质"。
这些声音共同勾勒出2026年年中AI编程领域的核心张力：效率正在吞噬能力。
对我们AI创业者的启示
1. 区分"工具使用"和"能力替代"
Claude Code、Cursor、Reasonix等AI编程工具的最佳用法不是替代你的思考，而是替代你的重复劳动。Mohan的实践非常精确：手写核心架构和业务逻辑，AI只处理组件拆分、样板代码生成等"体力活"。
对于AI创业内参的读者——一人公司创业者和独立开发者——这个区分尤其关键。你自己就是整个技术团队，如果连你都失去了对代码库的理解，没有人能救你。
2. AI编程的速度陷阱
生成快不等于交付快。Mohan的核心论点值得反复思考：每次用AI写代码而不是手写，都会增加下一次修改的难度。 短期看效率提升，长期看维护成本爆炸。一人公司最怕的正是"技术债爆炸"——你没有团队分摊维护工作。
3. Review成本被严重低估
ClickHouse团队的经验印证了一个容易被忽视的事实：审查AI生成的代码往往比审查手写代码更累。手写代码遵循作者的思维逻辑，reader可以顺着思路走。AI代码是"零上下文生成"的——你不仅要在脑海里重建代码，还要重建它"本来应该有的"设计意图。
4. 建立"AI使用边界"是2026年的竞争力
Mohan的实践给出了一个可操作模板：
- 核心模块：手写。这是你理解系统的"锚点"
- 重复性任务：AI辅助。组件拆分、测试用例生成、样板代码
- 探索性工作：AI生成初版，但必须自己重构一遍才能真正"拥有"这段代码
- 文档和注释：AI生成，人工校对
行动建议
- 本周就做一次"代码理解度审计"：随机抽取项目中5个核心模块，不看AI对话记录，能否画出来龙去脉？如果不行，该补课了。
- 设立AI使用日志：记录每次使用AI写代码的任务类型、生成代码行数、后续修改次数。一个月后看数据，你可能会惊讶于"效率提升"的真相。
- 定义你的"核心模块"清单：明确哪些代码必须手写，哪些可以外包给AI。这是你作为独立开发者的护城河。
- 定期"裸写"练习：每周至少有一天完全不用AI辅助，保持手写代码的肌肉记忆。Mohan说得对——技能不用就退化。
- 团队层面建立"知识传递"机制：如果你是团队负责人，确保AI生成的代码有对应的设计文档和Code Review记录。不要让"没有人理解代码"成为团队的默认状态。
本文由AI辅助创作，经人工审核编辑发布