我们不再互相请教了。一份关于AI与工程文化的宣言。
摘要
一篇论文指出,AI的便利正在侵蚀工程领域那种以同伴为主导的文化——在这种文化中,相互学习和指导曾蓬勃发展;并警告说,将AI视为同伴会剥夺代码审查等实践所带来的人类成长。
暂无内容
查看缓存全文
缓存时间: 2026/06/02 19:36
# AI 不是你的同侪
来源:https://www.notyourpeer.com/
一份关于 AI 时代工程实践的宣言
白板前工程师的插画
## 工程是由那些愿意花时间的人建立起来的
入职第一周,资深工程师在一个他们有空的下午,和我们坐在一起,逐个文件地讲解代码库。
凌晨两点 Stack Overflow 上的答案,被陌生人编辑了十一次,直到解释终于站得住脚。
架构师预订了一块白板和一小时的时间,在我们写一行代码之前,就系统结构展开辩论。
Staff 工程师认真审阅了我们的设计文档,逐行逐句,提出实实在在的问题,哪怕那不是他们的项目。
**工程从来就不是一项独自完成的手艺。**它从来也不是真正的等级制度。它是一个由同行组成的社区:有我们团队里的人,也有我们永远不会遇见的人,所有人都属于同一块织物。那些我们信任其判断的人。那些我们有所亏欠的人。
我们接受了前人慷慨给予的一切。最终,我们也成为了他们。成为别人入职第一周时的那位资深工程师,挡住那一小时,坐在白板前。我们写下了凌晨两点下一个人会找到的答案。
我们站在巨人的肩膀上,所以我们成为了巨人。
白板前工程师的插画
## 然后,某种“更好”的东西来了
模型比坐在三张桌子外的同事更快。它不会反驳。我们不会因为问昨天已经问过的问题而感到愚蠢。它在凌晨两点也随时可用。
我们的同事并没有变得更差、更刻薄或更吝啬。没有人毁了任何东西。
我们只是不再互相询问了。
那位资深工程师仍然坐在三张桌子外。我们只是不再去找他们了。那位架构师仍然愿意预订那一小时。我们只是不再去问。向模型提问比打断同事更快。确实如此。**我们当时这么做并没有错。**
我们一次一个提示地进行了这个权衡,而集体的结果是我们谁也没有选择过的。
两位开发者一起工作的插画
一位开发者独自工作的插画
## AI 不是你的同侪
AI 模型缺乏我们所说的“同侪”应有的东西:激情、灵感、抱负、以及创造的能力。它们没有自己的观点。它们不会因为我们错了而提出异议。它们能干、耐心、不知疲倦,但所有这些都不是让一个同侪值得拥有的原因。
对 AI 生成的拉取请求进行的“同行评审”实际上根本不是同行评审。我们不是在评审一个同行。**我们是在审计一台机器。**这两者的感受完全不同。
而同行评审中有一半,一旦作者变成智能体,就完全消失了。同行评审存在的原因有两个,而非一个:在错误进入生产环境之前发现它们,以及学习。学习让*作者*和评审者都随着时间变得更好。这是一个循环,让初级工程师成长,让资深工程师保持诚实,让团队通过多年积累建立共同的理解和判断力。
当作者是 AI 时,那后半部分就消失了。智能体不会从我们的反馈中成长。它不会把我们对这次拉取请求的意见带到下一次。它明天和今天一样好,也一样差。我们可以给它不同的配置,写更好的指令,这是有价值的工作。但这不是同行评审。这是一项完全不同的工作。
当作者是智能体时,同行评审价值的一半都不再适用。
这就是你讨厌它的原因。
这就是为什么这部分工作不再像以前一样的感觉。那种分歧。那个让我们学到东西的问题。那个同事反驳后我们俩都变得更聪明的时刻。它没有被替代。它只是消失了,而在这期间我们只顾着变得更快。
剩下的只是审计。我们坐在一台机器产生的差异(diff)前,寻找机器犯的错误,而另一边没有人与之交谈。
这离我们学习如何做这份工作的方式相去甚远。离坐在三张桌子外的同事。离那些挡住那一小时的资深工程师。离那些在凌晨两点回答我们问题的陌生人。离那些愿意花时间的人们。
白板前工程师的插画
## 事情本不必如此
它感觉不对劲的原因是结构性的,一旦我们给它命名,出路也就随之自现。当我们使用智能体编写代码时,它产生的拉取请求融合了两样东西。第一:我们关于构建什么而做出的智能、深思熟虑的决定——我们要求的部分,我们有意见的部分,我们会为之辩护的部分。第二:智能体关于如何执行而做出的机械、常规的猜测——那些显而易见以至于我们懒得去指定的部分,那些没人选择的部分。
当我们试图审阅一个拉取请求时,我们同时在审阅这两者。在差异(diff)内部,我们无法区分哪一行是哪一种。而且我们本就不该区分。这正是使用 AI 编写代码的全部意义所在。
AI 让我们比以往更快地编写代码,原因是我们不再需要关心每一行。我们定义重要的东西,让智能体填补空白。这个权衡是正确的权衡。我们不想把它收回。我们只想审阅我们在意的那部分,而且仅仅是那部分。
做一名工程师的难处从来不是编写代码。它一直是理解问题,足以规划如何解决它。代码只是解决方案的表达方式。智能体拿走了表达。理解仍然属于我们——而真正的同行评审从来都是关于理解的。
很多人在研究这个问题。他们中的大多数试图让审计更快。我们认为他们找错了目标。值得评审的产物是我们在智能体写任何代码之前所写的计划。
所以从现在起,我们将把同行评审转移到我们给智能体的计划上,而不是它产生的代码。我们将把代码的评审委托给一个真正的同行——另一个 AI 智能体——来检查它是否有 bug,并确保它忠实地实现了计划。我们将收回作为团队做出决策的所有权,并且在这个过程中我们会更快地前进。
我们已经开始像以前那样,一起评审计划了。我们热爱这种方式。
我们这门手艺的未来正在此刻被决定。
## 让我们一起决定它
相似文章
认知依赖
一篇简短的评论文章,探讨依赖AI进行软件开发是否会导致工程师技能退化,并可能造成AI进展停滞,直至递归自我改进(RSI)成为可能。
AI需要更严格的工程纪律,而非更少
文章认为,尽管AI生成代码的能力日益增强,但工程纪律——尤其是代码审查和可靠性实践——变得更加重要,而非减弱。
AI并未消除工程工作,只是把难点转移到了别处。
AI让编写代码变得更便宜,却将难点转移到了设定上下文、审查和清理上,需要更熟练的监督。文章认为,团队常常把AI生成的代码当作成品,而实际上它只是一个快速的初稿。
AI热衷者与时间赛跑,AI怀疑者与熵增赛跑
一篇Substack文章探讨了软件工程领域AI热衷者与AI怀疑者之间日益扩大的分歧,认为双方都面临真实的生存威胁——热衷者担心被竞争对手超越,而怀疑者则担忧不加批判地采用AI会带来长期的混乱和技术债务。
我们是在培养AI工程师,还是仅仅是AI工具的使用者?
文章观察到,初级AI工程师倾向于专注于提示工程和低代码平台等高层次工具,而非深入理解基础知识,这引发了对面试中解决问题能力的担忧。