y.y
Published on

AI: Accelerated Incompetence

AI:加速的无能

Doug · 2025-05-19

原文出处:https://www.slater.dev/accelerated-incompetence/

目录

在软件工程中,过度依赖LLM会加速无能。LLM无法取代人类的批判性思维。

本文完全未使用任何AI辅助写作。

显示LLM依赖性与智商之间推测性反比关系的图表

LLM依赖性与智商之间的推测性反比关系

自2022年末AI和LLM浪潮冲击公众意识以来,已经有大量文字对此进行了探讨。作为一名经验丰富的软件工程师,我想谈谈我观察到的关于LLM的两种令人担忧的工程观点。

"LLM是我的朋友"

我不认为有人会真的相信计算机程序是他们的伴侣,所以让我们来解释上述短语的委婉含义:即LLM为用户带来了巨大的好处。

将LLM视为盟友的工程师总是优先考虑或感到压力要优先考虑速度;对他们来说,产出胜过洞察力。虽然LLM确实可以快速交付大量代码,但它们的使用带有长期的_风险_。

使用LLM的风险

  • 输出风险。LLM可能给出明显错误的输出,比如无法编译的代码。更可能且更危险的是,它可能给出微妙且无法检测到的错误输出,比如逻辑错误。如果提示者没有资格评估输出,风险会加剧,比如项目经理为源代码写提示。

  • 输入风险。LLM不会质疑引导性1、假设有缺陷或上下文不完整的提示。例如:工程师提示:"在C#中提供一个线程安全的列表实现",并收到200行完美无缺的正确代码。但这仍然是错误的答案,因为问题应该是:"我如何让这段代码线程安全?"答案是"使用System.Collections.Concurrent"和1行代码。LLM无法识别XY问题2的实例,因为它没有被要求这样做。

  • 未来速度。这是典型的"技术债务"论证,但更加紧迫。AI可以_如此快速_地降低你代码库的质量。你见过囤积症的后果吗?从外面看,房子或公寓可能看起来很好。但里面是不卫生的、令人厌恶的和无法正常使用的。开发者发现,如果没有强有力的防护措施,LLM产生的代码就像这样的空间。

  • 用户幼稚化。将思考和问题解决外包给LLM的个人和组织将出现人才流失:

    • 当高级工程师被剥夺通过富有成效的挣扎学习的机会时,他们现有的问题解决和批判性思维技能会退化:
      • "微软对知识工作者的研究发现,AI驱动的信心往往以牺牲批判性思维为代价"3
      • "在一个推动'反射性AI使用'的世界中,我倡导的是不同的东西:与AI进行深思熟虑、有意图的协作,保持编码作为手工艺的本质"4
      • "LLM给我完成的思想,精美且令人信服,但没有自己发展它们所带来的智力成长"5
    • 初级工程师永远不会首先发展这样的技能,因此永远无法反过来指导未来的初级工程师。
  • 失去快乐。许多开发者报告说,使用AI剥夺了他们的心流状态和创造的快乐。6 AI生成的代码读起来和修改起来都很痛苦。

在未来的文章中,我计划写关于每种风险的缓解措施。如果这听起来有趣,请务必在下方订阅。

"我会变得多余"

来源7

不,你不会。话虽如此,确实有一些事情你可以做来进一步区分自己与LLM。为了保持主题,我将把这推迟到未来的文章。

LLM无法提供两种编程能力:程序理论_和_程序熵

程序理论

...编程应该被正确地视为程序员形成或实现某种洞察、理论的活动,关于手头的事务

-- Peter Naur,《编程作为理论构建》,1985年8

Naur是计算机领域的伟大人物之一。他反对当时的流行观点,认为程序不是它的源代码。相反,程序是一个共享的心理构造:一个_理论_或_设计_。从中,工程师派生出代码,但有价值的工作产品是设计,而不是代码。

为了帮助你思考程序理论和程序文本之间的区别,考虑这个思想实验:想象两个同等才能的工程团队A和B被锁在单独的房间里。每个团队都被告知不要与另一个团队交流。团队A的任务是编写一个程序,比如一个简单的基于终端的国际象棋游戏。团队B只是等待,下真正的国际象棋,或者做其他事情。当团队A完成后,他们的源代码被交给团队B。现在每个团队被要求并行地为程序添加一个功能,比如一个虚拟棋手,这样游戏可以单人玩。(我们让团队A在开始之前休息一下)。

问题:哪个团队会提供更好的解决方案?

答案:团队A,因为这些工程师对他们刚刚创建的程序有一个新鲜的心理模型,而团队B没有。

根据Naur的说法,理论很重要,因为程序不可避免地需要被_维护_,即在初始创建后进行修改。如果你只有源代码而没有对其设计的内化理解,这些修改的成本会更高。我想我们每个人都能记住被介绍到一个大型现有代码库的时候。起初我们的生产力接近零。当我们将程序理论加载到脑海中时,生产力就上升了。

LLM与程序理论

目前存在的LLM无法掌握理论、设计或心理构造,因为它们在上下文窗口之外不记得任何东西。只有人类能够获得和保持程序理论。

程序熵

复杂性是编程的基本对立力量9,它与熵相关。

...程序构建是一个熵减过程...程序维护是一个熵增过程,即使其最熟练的执行也只能延迟系统陷入无法修复的过时状态

-- Fred Brooks,《人月神话》,1975年

Brooks,计算机领域另一位杰出的历史人物,断言在初始构建之后,对程序所做的改变只能使源代码变得更复杂。然而,与设计和谐一致的改变将以较慢的速度这样做。

LLM与程序熵

LLM是一个令牌预测器。它只在文本层面工作。它不能在概念层面工作:它不对想法、图表或需求规范进行推理。每个向LLM提示大块代码的人都看到过LLM倾向于应用不必要和奇怪的更改,对话拖得越久,它偏离得越多。你多少次见过LLM_减少_一段代码的复杂性?

只有人类能够减少或抵抗复杂性。

结论

我们通过回忆我们学科的两位先驱对软件设计和复杂性的见解,为LLM时代找到了智慧。

如果你希望AI能将你的工程职业推向下一个水平,请注意它可能产生相反的效果。LLM可能加速无能。

如果你是一名熟练、有经验的工程师,担心AI会让你失业,请采取更细致的观点。LLM无法取代人类工程。

AI的商业吸引力是通过商品化工程降低成本,但就像离岸工程人才带来的结果好坏参半一样,LLM也有不足并带来风险。

AI炒作周期最终会达到顶峰10。现在过度使用AI的公司将继承长期的成本,它们要么转向要么灭绝。因此,人类在工程中的长期价值主张保持不变。世界仍然需要并愿意为工程中的技术技能和深度思考付费。

不过,AI会继续存在。将其作为工具而不是拐杖使用,并继续投资于在2019年被认为有价值的相同基本工程技能。

下一步...

在下方订阅我的邮件列表。我计划写更多内容。

参考文献

  1. 引导性问题
  2. XY问题
  3. ThoughtWorks技术雷达第32期
  4. 编码作为手工艺:回到老健身房
  5. 关于思考的思考
  6. AI编程的隐藏成本
  7. "我想知道我是否会变得多余"
  8. 编程作为理论构建
  9. Grug论复杂性
  10. Gartner炒作周期