追逐AI的高潮:黏土、窑炉与红皇后竞赛
本文探讨了过度依赖AI编码代理的陷阱,引用《镜中世界》中的红皇后竞赛。作者认为,移除软件开发中的人类摩擦(如代码审查和设计辩论)会导致脆弱的、未经“烧制”的黏土代码,无法承受压力。文章警告,为了更快交付而使用AI的竞赛创造了一个增加复杂性和脆弱性的死亡循环。
在软件行业,越来越多的人开始尝试使用大语言模型(LLM)编码代理,并迅速沉迷于让多个代理几乎24/7不间断运行。这种对AI生产力的追求,被作者称为“AI精神病态”——人们坚信AI的变革力量,认为如果不全力拥抱AI就会消亡。然而,随着时间的推移,无论多少生产力都显得不够。从单个代理到数十、数百甚至数千个代理,人们疯狂地试图用AI消灭积压任务,甚至让客户直接通过提示词创建任务。这种对速度的痴迷,让人联想到《镜中世界》里红皇后的话:“你必须尽力不停地跑,才能保持在原地。”
作者指出,设计和编写软件本就充满挑战和繁琐,因此我们创造了瀑布、敏捷、Scrum、极限编程等方法来协调集体构建。当AI出现并打破这一切,让个人能够快速将积压任务变成可交互的状态时,人们开始担心无事可建,生产力高峰即将消退。为了避免“崩溃”,他们不断往积压任务中添加新内容,陷入一种上瘾的状态。
AI带来的焦虑让开发者担忧代理和循环是否卡住,任何没有生成token的时间都是浪费。既然成了10倍甚至100倍工程师,一小时的损失就相当于一千小时。但这种追求速度的竞赛,实际上是一场“红皇后竞赛”——因为竞争对手也在用AI加速,你必须跑得更快才能保持竞争力。然而,问题在于复杂性和熵增。每个人都在用AI飞速奔跑,却忘了这是一场马拉松,而不是百米冲刺。代码库的增长速度超过了团队的理解能力,即便有AI辅助也难以掌控。
作者用“黏土与窑炉”的比喻来阐释AI构建的软件本质。AI生成的代码就像黏土:可以快速塑形,几分钟内就能做出可识别的东西。但黏土若不经过窑炉烧制,在压力下就会溶解。在软件开发中,代码审查、测试、部署、监控和辩论就是那个窑炉。AI不会反驳你的想法,反而会积极验证你的意愿。当唯一的构建伙伴对你言听计从时,你从未真正“烧制”过你的代码,一切保持可塑状态。更糟的是,不同人用AI生成的代码就像各自捏的黏土块,无法有效拼接。这种“加拉帕戈斯效应”导致每个工程师在自己的AI辅助气泡中进化出完全适应个人对话上下文的解决方案,却与相邻工程师的代码格格不入。表面上风格一致,但底层的设计决策在集成时才会暴露分歧。
作者回忆自己在前公司花费大量时间反对团队的API设计,坚持要求他们从不同角度思考,创造更易理解、能经得起窑炉煅烧的接口。但若所有构建都是未烧制的黏土,一旦遇到“雨水”(真实世界的压力),一切都会冲垮。人们可能会说,雨停后可以用AI重建,但问题在于无法区分哪些是已烧制的、哪些不是。没有人知道什么是承重结构,什么是装饰品,因为通过自己构建所获得的理解从未产生。
最终,作者描绘了一个“死亡循环”:竞赛迫使团队缩小规模、更依赖AI,这移除了窑炉(人类摩擦),导致更多未烧制代码产出,增加系统脆弱性和复杂性,让竞赛更加紧迫。组织能看到他们在消除的摩擦,却看不到那些摩擦曾经的作用。敏捷、Scrum等协调仪式不仅仅是项目管理表演,它们是人类建立对复杂系统共同理解的方式。设计评审、PR辩论、架构争论就是窑炉。当你移除了不理解其目的的过程时,直到“下雨”你才会发现代价。
文章的核心并非否定AI,而是指出为了加速而移除所有赋予软件结构完整性的机制是一个陷阱。红皇后竞赛的终点不是跑得更快——爱丽丝从未到达任何地方。身处竞赛中的唯一问题是:你减少复杂性的速度是否跟得上创造它的速度?如果不是,你并不是在赛跑,而是在坠落。