在最近的Dwarkesh 播客采访中，Andrej Karpathy (现在) 曾说过这样一句话：
总的来说，模型还不够完善。我觉得这个行业想得太高了，还试图假装这很了不起，但事实并非如此。这简直是一团糟。
AI 代码很粗糙。
我认为代码应该是“草率的”（slop） 。不仅是AI代码，即使是人类编写的代码也应该如此。“草率”才是代码的理想形式，是我们一直追求的巅峰。亲爱的读者，这可不会让你感到舒服。所以，我们慢慢来吧。
什么是 slop？
在一篇关于定义该术语的史诗般的博客文章中，John David Pressman (@jdp) 这样说道：
写得潦草是为了填补字数。
拖沓是指你拖延大学论文的写作，并在截止日期当晚把一些东西弄糟了。
斜率是追逐算法的逻辑结论。
泔水是本我蒸馏出来的挤压精华。
当你有一个公式并坚持执行时，就会出现混乱。
失误是指您可以猜出警察程序中发现凶手的确切时间，因为每集都一样。
当生成器的 k 复杂度足够低时，您便可以推断出其模式，这就是 Slop。
邋遢就是每天在学校吃午餐，直到吐为止。
偏差是指某项措施不再是一个好的目标。
《Slop》是第 12 部超级英雄电影的续集。
作者之前所写的内容都是空洞的，没有新的想法或证据。
Slop 是盖尔曼失忆症。
斜率处于分布状态。
当作者写作的目的是为了赚钱时，就会出现“草率”的情况。
粗俗是指未能说出任何有趣的事情。
你在激励梯度的底部发现了松散的东西。
斜面的模拟层次比它所声称的要深。
泔水就是氛围。
烂片无聊透顶，毫无惊喜，老套，毫无新意。哈欠……
代码应该是草率的
回顾一下古代历史，比如 2-3 年前，软件工程师会说这样的话：
- Dan McKinley， 《选择无聊的技术》 （2015），“创新代币”的起源，你只能做出这么多“酷”的选择
- Charity Major， 《选择无聊的文化》 （2023），内容与此相同，但扩展到管理原则
- Robin Rendle， 《三种类型的代码》 （2020），其中第一种是“无聊的代码就是好代码”
- Chris Prijic， 《无聊的代码是一种美德》 （2022）
- 戴夫·切尼， 《清晰胜于聪明》 （2019）
- Stephen O’Grady， “你不会因为使用 Apache 而被解雇” （2011 年）
- Alex Payne， “没有人会因为选择 Java 而被解雇” （2013 年）
有趣。好的代码是无聊的、毫无惊喜的、可预测的、毫无启发的。
糟糕的。好的代码应该是糟糕的。
Karpathy 没有这么说！！
是的，他做到了。
在采访的整个过程中，Karpathy 一直坚称 AI 编码代理对他帮助不大，因为他的代码“超出了发行范围”。换句话说， Karpathy 是自作自受：
我想说 nanochat 不是其中一个例子，因为它是一个相当独特的代码库。我构建的代码并没有那么多。它不是样板代码。它几乎是智力密集型代码，所有内容都必须非常精确地安排。这些模型存在很多认知缺陷。举个例子，他们一直误解代码，因为他们记忆中充斥着互联网上所有典型的做事方式，而我根本没有采用这些方式。例如，这些模型——我不知道是否想深入探讨细节——但他们一直以为我写的是普通代码，而我并没有。
Karpathy 认为 AI 工具没什么用，因为他故意选择了一些不正常的模式。他甚至承认，这些工具在其他项目中也很有用。
这并不是对 Karpathy 的批评，他为自己的程序设定了一个目标。他要把它打造成一个教育资源库。他不想要“普通”的代码，他想要的是能够最大程度实现教育目标的代码。
原始代码不是目标
大多数时候，雇主的目标是尽快创造价值。高质量且可维护的代码只是一种代理，一种在较长时间内快速交付价值的策略。
如果代码变得杂乱无章，即使是一些微不足道的修改也会耗费太多时间，最终导致价值交付变得缓慢而繁重。即使是枯燥的代码，也只是避免代码无法维护的一种策略。
最终目标依然如故。快速交付价值。Karpathy 有一个例外，其目标也极其奇特。你不是 Karpathy。
人工智能快速创造价值
最近我概述了我如何处理人工智能编码：
- 拥有主人翁意识
- 抓住机遇
最近，我在给别人解释组织动力学时，用了“自然力量”这个词。如果一个组织倾向于自上而下的沟通方式，那么从基层开展工作很可能会耗费大量精力，甚至可能失败。因为这违背了组织的本质。
2014年，Tim Ewald发表了题为“用手工工具编程”的演讲，他将编程与木工进行了非常相似的类比。你需要观察木材的纹理，并且只进行符合材料这一基本特性的切割。
AI 编码代理能够快速交付价值，但显然在某些场景下会失败。所以不要这样做。不要做那些行不通的事情。这并非火箭科学。成为一名工程师，抓住机遇，避免陷阱。
卡帕西：
所以，如果你在做样板工作，代理会表现得非常好。那些只是复制粘贴的样板代码，代理在这方面非常擅长。
真正的工程师会把这看作一个机会。 “如果我能最大限度地利用样板代码，就能从人工智能中获得更多优势。”比如，添加一个免费的 monad可能不是一个好主意，我不知道。
这并不是什么新鲜事。这就是软件工程师的工作。当某些东西无法正常工作时，你会重构代码库，或者将团队重组为更小、更专注的团队。这就是设计模式存在的原因。像微服务这样的权衡取舍，会让你的代码在一个维度上变得更糟，以便在另一个对你的团队更重要的维度上变得更好。
是的，但我是个例外
也许你和 Karpathy 一样，发现自己处于一种极其罕见的境地，你的目标并非快速交付价值。不妨这样做：年度考核季即将到来，告诉你的老板你不会使用 AI 工具，因为你认为你的目标中没有快速交付价值这一项。
试试看吧。我相信一定会成功的。
结论
我一直想写一篇关于“如何编写人工智能程序”的文章，但感觉已经写得太多。Karpathy 的“粗略”评论似乎恰好引出了真正重要的事情：抓住机遇。我反复问自己： “我们还能做得更好吗？”，以此来扭转团队的局面。为什么这不适用于人工智能工具呢？
作为软件工程师（或者说任何类型的工程师），我们的工作不是编写代码。很多职业都需要编写代码。软件工程师要做更重要的事情。编写代码所耗费的时间似乎分散了我们对核心工作的注意力，而我认为人工智能提供了一个机会，让我们重新理清工作的重点。