大型语言模型或将“切碎”开发者的饭碗？聊天式编程才是未来！

顽固程序员的终结

我在五月写了一篇博客，题目叫《初级开发者之死》。这引起了很大的争议。我的观点后来得到了许多大公司的支持，并且这种趋势不仅限于软件行业，也在其他行业有所体现。虽然这对大部分人来说都不方便，但这确实是一个真实存在的问题。

我那篇“捅蜂窝”帖子的核心观点其实很简单，可以将软件项目中常见的两种不同类型的任务通过图表或图像的方式呈现出来。

正如资深项目经理都知道的，每一个稍微复杂一点的项目都包含多个任务、子任务及其依赖关系，形成一个任务网络。

许多图中的节点是叶节点任务，比如“编写一个认证库”或“将这些单元测试现代化”。这些任务通常相对独立。我们通常把这些任务交给初级开发人员，因为任务规模较小。

另一种类型的任务是将各种叶任务结合在一起，以交付整个项目及其所有子项目。如果你在造一辆车，你可以让所有单独的零件通过3D打印制造，这与LLM生成代码的过程非常相似。但还是需要有人来组装这辆车才行。

那些高层的内部任务图节点通常需要大量的计划和协调工作。

关键是：从大约五月份开始，大语言模型现在可以执行大多数基础任务，甚至一些较高层次的内部任务，即使是大型软件项目。这真是太好了。但是，留给我们的主要是更难的规划和协调工作。这些任务通常是不会交给新手程序员的。

这些初级开发者到底该做些什么？他们现在怎么才能提升自己呢？

我的建议：他们最好学学聊天编程，不然的话。

那便是我的帖子，有点太简化了。今天这样也差不多了。它确实引起了不小的风波。但我觉得大家可能还没有完全明白的是，即使风波已经平息，问题本身还没有解决——它才刚刚开始呢。

这其实跟菜鸟程序员没什么关系

从现在看来，用“新手”来形容是不准确的。我跟很多人讨论过这里用“新手”来指代软件开发者的词，我们都一致认为这个词不合适。确实有一部分开发者被落下了，但这显然不仅仅是关于新手开发者的问题，情况要复杂得多。

不过新手程序员受影响很大，这确实是个问题。

初级开发者成长到高级开发者的路径似乎出了问题，要么断裂了，要么至少是受损了。我借用了一下马特·比恩博士的一个恰当比喻，他描述了由于手术机器人的出现，同样的现象也出现在了初级外科医生身上。情况非常相似：现在任务图中的叶子节点已经被自动化了，所以我们现在不需要那么多初级贡献者了。

然而，一些初级工程师很快上手了这些新东西，飞速提升了自己的等级。而许多高级工程师似乎在掉队。那么，究竟是什么原因呢？

我最近跟两家完全相反的公司谈过——一家是新员工采用了chop这种做法，但老员工坚决拒绝，说这是个花招。另一家则是老员工采用了chop这种做法，但新员工拒绝，理由是他们认为这会威胁到他们的工作。外面的世界真是够疯狂的。

要一下子指出哪些开发人员最麻烦，这很难。

我们已经将这个问题归结为一个原则：如果你不采用以聊天为基础的编程作为你的主要模式，你就跟不上了。

有几个正当的理由不用 chop，但这些理由却很快不再成为借口。

随便你怎么叫它都行，但对我来说，时间越长，那些死磕派只是显得更倔强。

以聊天为中心的编程

我特别强调基于聊天的编程方式，是因为通过和LLM聊天，可以直接让任务图叶节点被3D打印出来。这是整个过程中的关键一步。

所以聊天正变得越来越成为编写程序的主要手段，正如我们所说。说软件工程师的工作将永久改变也不算过分，所有的编程工作，甚至更新，最终都将通过聊天来完成。请记住，这是与一个会胡言乱语的家伙聊天，所以这并不是大家期望的那种坚实的飞跃。但这种推动如此之大，经济驱动力正在推动所有人朝这个方向前进。

在我的博客里，我称这种现象为“面向聊天编程”（简称 chop 或直接称作 chop）。chop 不仅仅是未来，它就是现在进行时。如果你没有使用它，你就已经开始落后于那些正在使用它的人了。

我不会再把这种说法当成个人意见，因为此时它已经接近成为公认的事实。在我们 Sourcegraph 这里，我们有许多合作伙伴和客户与我们分享他们内部研究的结果，涉及各种代码助手工具。这让我们比很多其他公司拥有更广阔的视野。

广泛而言，切换到chop工具或技术可以使企业工程师的生产力至少提升30%——即使工程师抱怨并且感觉使用它更慢也是如此。这个提升数据较为保守，有些人报告的实际提升更高。此外，很多这些研究是在初期阶段进行的。

生产效率的提升应该是基准的，并且随着基础模型、工具以及其成熟发展的继续，这种提升将持续增长。而且它没有上限，比如2倍。在某些情况下，这个增长可能会轻松地达到10倍、20倍甚至更高。

那个，朋友们，这就是上瘾了。这种随机奖励简直让人着迷！玩这款游戏《Chop》，单是那种肾上腺素飙升的感觉就足够好玩了。可以弥补你在玩得不顺时跺脚咒骂的时刻。

在我最后一次查看时，ChatGPT仍然是世界上使用最广泛的编码助手，不过它只提供“chop”功能，不支持代码补全。显然，“chop”已经是个现象了，也有很大的粉丝群体。

这里唯一存在分歧的地方是chop会持续多久（此处指代某种编程语言或技术）。凭我未经证实但有一定根据的猜测，它至少能持续三年。实际上，我认为它很可能持续长达十年，考虑到汇编语言消失所需的时间。

这就是我的看法：我们未来几年可能还得用这种砍。

也许短期内有更好的选择，这是个质疑的声音。

还有一群非常聪明的人持有与我不同的观点，我希望能公正地代表他们。我会尽我所能。他们并不否认它的存在。但他们倾向于认为这样的情况将是短暂的，因为它将被各种形式的自主代理所替代。

我认为分歧的原因有两个。首先，使用命令行很难。你需要熟练使用命令行，而不是必须是开发者，更像是黑客那样熟练。你需要打字快，阅读快，熟练使用工具，并且有能力手动处理大量文本和上下文信息。

所以很多人担心“剁手”不适合大众。而大众也拥有足够的购买力，这当然让这个问题在当下，特别是在2024年末，变得相当引人关注。

基于聊天的编程很难，但很多人认为自主代理很快就会出现，它们将为你搞定所有繁重的任务。你只需要写一些简短的提示并偶尔检查一下结果，这样涉及的劳力会少得多。

他们相信这些通用的自主软件机器人可以解决繁琐复杂的编程过程问题。事实上，有些人声称这些机器人可以完全接管任务管理图，也许至少对于小企业而言，可以让没有技术背景的CEO自己发布应用，而无需麻烦的技术人员。

我觉得那些人吸了不少烈性的可卡因。不过他们资金充足，所以有机会全力以赴地尝试，一路烧钱就像烧掉航空燃油。这让我想起了打车软件兴起的时代。不知道资金还能撑多久呢？

人们至少已经认真研究基于LLM的自主代理18个月了，Devin作为标杆案例在3月推出时引起了狂热的欢迎和追捧，但在此后的八个月里，我们几乎再也没听到关于它的任何消息，甚至是一声[屁]，。我还听说有许多类似的通用代理据说正在开发中。某个地方（据说）。据说是这样。

更新：在我发布这篇帖子的第二天，Devin 终于发布了 GA 版本，还附带了客户成功案例。有趣的是，客户正在使用它来进行批量重构和迁移。看来——这也支持了我在此处的所有论点——Devin 团队目前明智地降低了他们的雄心和承诺，专注于特定的使用案例，而不是“它无所不能”。他们的网站上写着这样：用于前端应用修复、生成“计划”以进行后端更改（不过 LLMs 已经能做到这一点了），以及批量重构。所以，基本上，他们是在其 web 应用生成器之上编写了一个批量重构工具。

事情是这样的：行业改变型的新技术，比如改变我们编码方式的技术，总是以相似的方式发展：逐步成长。它们一开始很小但够用——仅仅好到可以用。经过多次公开发布，它们逐渐变得庞大。当然，前提是它们一开始确实管用。

例如，比如IDEs、高级语言、网页编程、云计算、移动计算、CI/CD — 这些都是逐步发展起来的。甚至LLMs也是经过三十多年的公开可见改进逐步发展起来的成果。

所以你会觉得所有这些事情都会发生在普通的自主代理程序身上，是吧？

那它到底在哪里呢？如果我有遗漏的地方请告诉我。据我所知，还没有人推出任何可以实际迭代使用的产品。

此刻我怀疑，那些仍在游戏中的投资者正期待一次大飞跃，希望能一举成功，因为一点点进展都是灾难性的。

我的意思是……也许吧？这可能会发生？我自己也是比较偏向看空的。

但或许可以找到一些中间地带：某种比不那么野心勃勃的自主软件代理，但它仍然可能是一个提高生产力的工具，可以为你处理比普通聊天工具更多的任务。我的意思是，这还是有可能的。

找到一个折中的办法

在这里，有一个我很尊重的人持有我个人非常尊重的意见，他是 GitHub Next 的高级研究总监 Idan Gazit。他在今年的拉斯维加斯 ETLS 大会上做了一个非常吸引人的演讲。Idan 并不是很喜欢 chop。我们对此进行了深入的交谈，他真是个很酷的家伙。

我确实能理解他的想法。他本质上是一个HCI专家，所以他当然不希望Copilot用户去捣鼓任务图管理或上下文处理。他正在寻找一种每个开发者都能用的AI方式，一种不是只为高手设计的方式。

伊丹对这个问题的不满，或者说他对这个“切牛肉”的看法，是有道理的：大模型知道答案，但它实际上啥都做不了，只能告诉你。它能主动做事的程度，就像切好的牛肉一样，啥也干不了。作为程序员，你得自己动手，把上下文信息“处理”进聊天会话，再把答案“切”回代码库。

抱歉，现在已经很晚了。这就像打我自己和你俩一样，让我保持清醒的。

让我们从头开始。作为程序员，你必须承担所有搜集上下文信息和整合回复的工作。基本上就是这样。Chop需要不断地搜集和整合。在一个循环中反复进行。如果你正在做基于聊天的编程，这就是你现在工作中很重要的一部分。

Chop 的辛勤工作感觉更像是应该由你的工具来处理；我想大家都会认同这一点。有了这个想法，Idan 正在寻找比聊天更强大的东西，一个今天任何普通的程序员都可以使用而不需要学太多新东西就能使用的东西。

而这确实是一件大事。如果开发者不用学那么多东西，那将是个好消息。更多的程序员将会使用AI，更多的开发者将能够顺利过渡到大型语言模型。我觉得挺好的。Copilot Workspace 是 GitHub 在这个雄心勃勃的方向上的第一次尝试。希望他们能成功。

伊丹说得没错，每个人都会效仿那个偶然发现了神奇公式的那个人，不管那是什么。所以我们在某种程度上都是一起的，都在试图弄清楚明天编程会变成什么样。

虽然我在为他们加油，但我自己心里没底。我觉得可能要几年时间才能搞定足够靠谱的代理，让这些代理能顺利融入开发者的日常工作中，希望开发者可以直接用，不用额外培训或费劲。

一刀切也带来自己的问题

与此同时，你可以今天就开始使用chop，在任何支持聊天的代码助手里，更快地完成工作。这真是个好消息。

不太好的消息是，如果你急躁的话，你就得学新东西。这使得Chop的学习难度和新内容带来了连锁反应的问题。我们怎么教？你又怎么学？你又怎么面试？还有，像往常一样，我们怎么衡量？总之，一句话，这些度量标准在哪里？

我和出版商、研究人员、业内专家等各种人都聊过。大家或多或少都知道，这种聊天导向的编程将是编程下一个重要的发展步骤。上一次如此重大的转变是从汇编语言到高级语言，等等。

但没人知道如何教“切”。没有任何资源。一切从零起步。这发生在我们还不知道如何做的时候！这听起来很像当年的CI/CD，不是吗？那时是不是也像一堆最佳做法在篝火旁随意传播和分享呢？

对企业来说，没人知道如何衡量AI代码的影响。这是一个广泛的概念，涵盖了所有已知的方法，利用AI加速软件开发，包括代码切片。

如果你不确定公司在代码AI上的大规模投资是否见效，你怎么能解释呢？

代码AI的度量

運氣不錯，我和傳奇人物Gene Kim一直在商量如何幫助你。自從我們在今年夏天的ETLS活動上見面以來，我就一直在與Gene合作，我非常佩服他。他是你會遇到的最有正能量和鼓舞人心的人，他的熱情總是很有感染力。要不是Gene一直不斷地給我發短信說“發佈它！！”，我今天可能都無法發佈這篇文章。

但说重点，Gene 不只有一项超能力——包括备受追捧的无限能量 DLC，很少见到它与伤痕智慧和无限耐心同时出现。Gene 全部都具备了。

和我一样，Gene 也被 chop 对他自己的生产力以及整个行业内影响深深吸引。为了探讨教学上的问题，我和他做了一次 Zoom 代码协作会话，获得了许多宝贵见解。如果想深入了解，这会是一段相当复杂的旅程。在那次会话中，Gene 利用 chop 获得了新超能力，让他成为了世界上最快地从 YouTube 视频中摘取片段发推的人。这算不算小超能力呢？确实如此。

但他只用了不到三个小时就搞定了。看看吧！

为了帮助解决影响评估的问题，Gene 想要做同样的事情，就像他为 Code AI 和 CI/CD 所做的那样：DORA 指标。Gene 是这一改变行业的倡议的创始人之一，与 Nicole Forsgren 博士和 Jez Humble 一同。现在，Gene 计划为 Code AI 做同样的事。

这个想法是定义一套严格的行业标准指标体系，帮助公司了解他们是否在正确地做事。这些类似于 DORA 的指标需要集体努力。Gene，除了他其他的能力，与互联网共同发明者 Vint Cerf 一样，拥有一个神级超能力，他是唯一我遇到的拥有这种能力的人。Vint 曾经严肃地告诉我：“我的超能力是我能够召集人们。”Gene 也拥有召集并团结专家的独特能力。他正在组建的世界级团队也将致力于解决这个问题。

连伊丹也在参与。这是理所当然的。我们这儿可不是闹着玩的。

但这对这篇已经快速增长的文章来说，内容实在太多了。可惜。不过我来给大家一个预告，我们发现的一个最重要的与指标相关的维度是可选性。可能不会让你在已经很擅长的事情上变得快很多，但它会令你在那些你不太擅长的事情上变得极为迅速——那些你因为知道会比预期更费力而一直拖延的事情。

这样就可以让你在每个阶段同时探索多个选项。你不再局限于你熟悉的编程语言；你可以让大型语言模型用你想尝试的任何语言实现。同样的规则适用于数据库后端等等。如果合约大致相同，大型语言模型可以快速为这些合同生成多个子系统，你可以直接比较它们。

这极大地拓宽了你（和你的公司）愿意接手的任务范围，这在公司各级别规划中极为重要。而且，使结果更加可靠，因为你已经在每个关键点都尝试了多种选择。

我们觉得把这些东西量化和测量一下是个不错的主意，Gene 正在邀请其他领域的顶级 Optionality 专家来帮忙，所以记得关注他的推特哦！

故事的结尾

就这样！这就是我对当今形势的看法。我不看好通用型自主代理 （尽管今天Devin的发布看起来很有希望，因为他们放弃了疯狂的主张。） 我正在与几家专注于特殊用途自主或半自主代理的公司交谈，这确实是个有趣的概念。但这一切还处于早期阶段，有待验证。我给他们加油，但也不抱太大希望。

我没有试图描绘一幅美好的画面。Chop的采用在未来一段时间内仍将是充满坎坷的。从五月份到现在，我学到了很多关于它的缺点。比如说，它会出现幻觉，这使得它与普通的编程非常不同。人们对这种模糊程度的容忍度各不相同。你可能会以为Chop的学习曲线会变平缓，但实际上它似乎在变得更加陡峭。

这也超出了许多人的舒适区，他们对程序员工作应有的样子也有不同的看法。你必须花相当多的时间来适应，然后你的工作就会变得相当不同。这要求人们做出不少牺牲。

一旦你开始采用chop，你可能会失望地发现它的效益是明显且不舒服地不一致。一些人可能会比其他人看到更大的好处。拥有特定技能的开发者会更有优势。甚至在不同的任务之间，你也会得到不同的结果。我的朋友Eric Fritz博士，他自己从去年的怀疑者变成了支持者，对如何描述这些特点有一些有趣的见解。真的不亏一看，我保证。

但归根结底，Chop 这个东西，虽然它不可避免，但遗憾的是，它远没有人们想象中那么直线加速器。尽管它已经被证明可以提高生产力，Chop 同样已经被证明是一种令人讨厌的麻烦：难以理解、不一致、难以预料。难怪这么多人希望这只是短暂的一段时期，这也不足为奇。

我和 Sourcegraph 的同事们相信，您将会是处理任务图谱的人，而不会是模型。我们认为，掌控者将会是人类。我们不会坐等自主代理研究的结果，不会等待这些通用系统被研发出来并进行测试。

得了吧，我们只想给你们（包括你们在内）一些必要的能力，让事情变得更快。

这在实践中意味着什么呢？这意味着两件事，这同样适用于任何代码助手。首先，你可以通过加速上下文获取和提示重用来更快地输入到LLM。然后，你可以通过使用智能应用按钮（例如）等方法来加快输出处理。

毋庸置疑，语言模型的计划通常包括更多集成类型，比如运行工具或检查日志，而直到这种集成成熟之前，你只能通过手动处理来应对。但是拥有一个编程助手可以大大加速开发过程。尽管它们存在缺陷和不足，编程助手相比直接使用原始的Claude或Gemini/GPT会提供更好的体验，因为它们大大简化了与LLM输入和输出相关的许多工作。最重要的是，关键在于你的编程助手支持聊天功能的程度。

可以说，市面上涌现了大量的编码助手工具，正如伊丹所正确指出的那样，它们通过选择性地模仿彼此而逐渐变得相似。这就像选择一辆车或一家航空公司那样。它们都拥有大致相同的功能集，但可调的设置各不相同。

示例：一些助手会让你局限于特定的模型；另一些则会提供给你选择。一些目标是零配置一键式的便捷，让你无需思考即可使用，直接上手；另一些则会给你更多的控制权。一些更注重个别用户的需求；另一些则主要面向企业用户。一些要求你必须使用他们的集成开发环境（IDE）；另一些则作为插件运行在你的IDE中。

这些是一些非常基本的选择，对许多开发者来说意义重大。根据你的偏好和公司的需求，你可能倾向于选择某种编码助手，或者因为公司需求而不得不使用。请记住，虽然它们的功能可能大同小异，但它们展现功能的方式可能有很大差异。

不过我觉得有这么多选择真好！而且竞争能促进创新，这是真的。

人们常常问我：“编码助手X有什么特别之处？”我认为这不是一个合适的问题。如果你把它们看作是不同型号的车，它们同样繁多且复杂，就像悍马、兰博基尼和电动自行车一样各不相同。所以真正的问题应该是：“哪一个更适合你？”

最重要的事情是，它们全部超级酷，如果你用它们来做代码编写，你很快就能变得很牛。别再担心代码补全了。它们只有在LLM不为你写代码时才有用——这种情况应该永远都不会发生，或者至少是朝这个方向发展的。你能让LLM替你干活的程度上，任何支持对话的编码助手都会立刻让你成为更好的开发者，这事儿现在就可以发生。

而且反过来也是如此：如果你不使用 chop，那么你就是在慢吞吞地做事。你就像那些守旧的汇编语言死忠，在1990年仍然使用asm，因为编译器生成的代码还不够快。这些人真是死脑筋。这听起来是不是很熟悉？

他们既对又错，因为编译器生成的代码确实没有手写的代码可靠（听起来耳熟吗？）。一旦赶上了，他们就完了，他们的得意也烟消云散。

靴子一旦掉下来，你还在手动写代码，你就知道了。

这真是一个特别难接受的事实。药剂师告诉我，很多患者对他们的塞药感到困惑，试图吞下去。我觉得这里有一个很棒的比喻。Chop 不太直观，偏向于高手，它的生产效率提升也不一致，还没有得到很好的工具支持，并且难以衡量。而且你不应该吃这种东西。

这些确实是很棘手的问题。但除非你愿意孤注一掷，赌在自动化系统在未来短期内不会奇迹般地不再那么糟糕上，否则你需要立即采取行动。因为有很多东西需要学，而且大部分东西需要通过实践来掌握。

就是这样！如果你想了解更多信息，标题里就有提到。

这次我的号召与五月时一样，用来作为一年的结束：他们最好学学对话导向编程，“否则。”否则……他们就麻烦大了。如果你关注我的话。

喂，天都这么晚了，我要去睡觉了。

该轮到你们团队勇敢地尝试停止写代码了。

这就是大模型的用途。