Transcription
人工智能编码,如果你自己写代码很糟糕的话,那真的、真的太酷了。这就是为什么我们只看到初级开发者在使用这些工具。像 React 的创造者 Dan Abramov,或者 Rails 的创造者 DHH,或者 Linux 的创造者 Lionus Torva,或者 Reddus 的创造者 Anti-Res 这样的人。等等,他们不是初级开发者。到底是怎么回事?哦,天哪。[吸鼻子] 感觉就像突然涌现出许多非常有才华的开发者,他们突然拥抱并接受了这些人工智能工具。这真是令人难以置信。一方面,他们有点晚了,但另一方面,感觉我们都还处于非常非常早期的阶段。而且,很多人,即使是我不是最喜欢的那种人,他们历来都很重视自己的手艺、细节和把事情做对。这就是为什么看到他们都以现在的方式拥抱人工智能,感觉有点疯狂。老实说,我不知道有多少开发者在不使用这些工具的情况下能交付大量代码,尤其是有经验的开发者。这有很多原因。我一直在思考 Eric 在 Cursor 上发布的这篇帖子。结果发现,高级工程师接受的代理输出比初级工程师多。这是一个非常有趣的观察。我有很多话要说。不过,我首先要说的是今天的赞助商。人工智能模型非常聪明,但当它们能够访问浏览器时,它们会变得更聪明。不,使用 curl 和 bash 不算。我说的是一个真正的浏览器,它们可以点击按钮、登录并完成实际工作。这就是为什么我喜欢今天的赞助商 Kernel。它们是让你的代理使用浏览器的最快方式。我说的快,是指很多不同的方式。它们在 400 毫秒内启动。开始使用它们只需要不到 10 分钟。是的,真的。另外,只是一个小插曲,我报告了一个他们旧版本软件包的 bug,因为我还没有升级。而且在 10 分钟内,请注意,是在晚上 9 点,在 10 分钟内,他们就发布了一个修复。这种响应时间对于真正的企业至关重要,这就是为什么 Cash App 等公司已经转向 Kernel。这是他们示例运行器中的一个示例操作。我们给它一个名字,为测试创建浏览器。在这种情况下,它是一个接受上下文的 Promise。它创建一个浏览器,然后将其保留,因为这是一个我们想要使用的浏览器。所以,你运行命令,现在你就拥有了一个在云端运行的真实浏览器的 URL,你或你的代理都可以使用。让你的代理访问整个网络,请访问 soy.v.link/link/kernel。是的,我还在生病。抱歉。我得了现在 SF 和湾区流行的那种可怕的上呼吸道疾病。希望很快就能恢复我的声音。DHH 发表了关于推广人工智能代理的博文后,我开始思考这个视频。他特别指的是这些代理在他日常工作中的作用发生了变化,他正在有效地将它们提升到在他工作和日常生活中更高级别的参与度。正如他所说:“我已经准备好给当前一批人工智能代理一次晋升了。它们不再仅仅是为了帮助我学习、回答我的问题或检查我的工作。它们完全有能力为真实的代码库做出生产级别的贡献。”目前,纯粹的“氛围编码”仍然是专业工作中一个有抱负的梦想。然而,监督式协作已经到来。我曾与代理合作修复小 bug、完成重要功能,并为重大新计划制定了几份草稿。范式转变终于感觉真实了。是的。所以,如果你把这些东西说成它们只对那些从事小型副项目的人有用,或者每个人最喜欢的评论,“Theo 对真正的大型代码库一无所知。他只做初创规模的工作。”你的上帝和救世主 DHH 现在在我们这边了。事情就是这样。这些工具不再仅仅是快速编辑页面上的 CSS、研究某事如何工作或回答问题的工具。它们正在指挥真正的系统并完成真正的工作。你如何选择使用和拥抱它们,会有很大的不同。例如,Lionus 最近说,“氛围编码”是可以的,只要它不用于任何重要的事情。具体来说,使用“氛围编码”的定义,即你不阅读代码,只是生成代码来做某事。他正在身体力行。他最近发布了一个用于数字音频效果、音频噪声的存储库,他想在其中做一些可视化。当他这样做时,他决定他对 Python 和可视化知识并不是他的强项。与其尝试自己学习和完成,或者进行大量的谷歌搜索,他实际上自己进行了“氛围编码”。我对模拟滤波器了解得比 Python 多,这不算什么。它开始是我典型的谷歌搜索和“猴子看,猴子做”式的编程,但然后我直接跳过了中间环节,直接使用谷歌的“反重力”来做音频样本可视化。虽然我不一定认为“反重力”是拥抱现代人工智能编码体验的最佳工具,但他能从中看到价值,这本身就意义重大。如果你还没有看过我关于不要在人工智能方面落后的视频,我强烈建议你观看,因为我深入探讨了许多关于如何拥抱和跟上这些事情的方面。我在这里真正想强调的一件事是“跳出框框思考”的想法。如果你有更多的时间和知识,但没有,你会建造什么东西?所以,你不能只是制造你希望存在的一次性小工具。那些可能是一个已存在的库,但它不能完全做到你想要的事情,或者一个用于管理你玩的游戏中的某些东西的 Web 应用。有哪些不存在的工具、配件、软件是你希望存在的?而且,你越能这样思考,意识到你在一个大型代码库中遇到的问题可能无法在该大型代码库中得到最佳解决,也许它在旁边的一个小型随机存储库中得到更好的解决,让你能够调试某事、研究某事或进行实验。如果你对某个库有一个理论,想在你的项目中尝试,但将其实现到该项目中太复杂了,你就会启动一个东西来测试它并测试它的极限。如果你好奇不同的人工智能模型的能力,你可以构建自己的评估和脚手架来测试这些东西,而无需实际查看、编写,更不用说自己阅读代码了。需要理解的是,人工智能可以编写有效且能解决有用问题的代码。它能解决多大的问题,以及你多大程度上接受这些代码,这取决于你自己去理解和决定。一种思考方式是,在值得阅读之前,你愿意让代码执行多少?如果你编写的代码只是在你的机器上运行一两次,谁在乎呢?如果你编写的代码是要实际部署到生产环境的,你可能更倾向于 DHH 的方式,将其视为一个你正在与之合作的同事,并一起阅读。还值得注意的是,DHH 几个月前并不认为这些东西特别好。他在 Lex Freedman 的播客上谈到了这一点,并说他认为除了人工智能自动补全之外,它们并不出色。实际上,他说即使是自动补全也不算太好。但现在有了像 OpenCode 这样的工具,他正在更广泛地使用这些东西。另一个很好的例子来自 Anti-Res,Reddus 的创造者最近提交的一个 PR。Reddus 中有一个对 FastFloat 的依赖,这是一个 C++ 依赖。他厌倦了代码库中这堆庞大的 C++,特别是如果你使用 C++,你知道管理外部代码有多烦人。这很艰难。他正试图从代码库中移除越来越多的 C++。他用一个最小化的纯 C 实现替换了这个 3800 行的 C++ 模板库。他在这里有一条注释:这段代码由 Claude Code 使用 Opus 4.5 编写,并经过仔细测试,包括手动测试和与原始实现的合成测试。代码审查由 Codeex GPT 5.2 独立进行。这不是很棒吗?他用另一个模型彻底审查了它。是的。他发布了所有结果。结果表明它速度明显更快,构建速度更快,步骤更少。所有这些都是好事。这还触及了我可能要专门做一期视频的主题,那就是我们现在所知的库将开始消亡,取而代之的是提示和规范。那么,为什么这些特定的高级开发者都在拥抱这些工具,而少数其他人却不呢?这就是我的“热点见解”要发挥作用的地方,我们将从 Eric 的帖子开始。正如 Eric 所说,高级开发者倾向于接受比初级开发者更多的代理输出。这有几个原因。他们编写更高信号的提示,具有更紧密的规范和最小的歧义。他们将工作分解为代理兼容的单元。他们对正确性有更强的先验知识,使审查更快、更准确。而初级开发者会生成很多东西,但他们缺乏验证启发式方法来自信地批准输出。此外,你会注意到管理人员和高管倾向于接受更多,尤其是在较高范围内。员工也接受更多。接受的代码量因你的级别而异。让我们来谈谈为什么会这样。我将问你一个假设性问题。是什么让一个初级开发者变成高级开发者?想一想。你会如何定义初级开发者和高级开发者的区别?我也会让聊天参与进来。我看到很多观点。大多数人说经验差异、自信和知识。高级开发者在一切方面都更好。一个有趣的观点是“说话更少”,我并不完全同意。我会这样定义差距:它是两件大事的结合。能力和清晰度。这些是你作为开发者进步时需要提升的关键技能。当你能在更短的时间内以更好的理解和更低的失败率完成更多工作时,你的能力就会提高。清晰度非常重要,因为你的沟通技巧会提高,你会更擅长谈论你正在做的事情,并以正确的方式与正确的人以正确的细节水平分享它们。下一个问题,从高级到员工的差距呢?是什么让这个变得更难?有些人说是在大公司获得了头衔。你现在是一名业务经理,能够找到大范围的工作,同时做更多的事情。有些人正在抓住要点。责任。有趣。要求加薪和升职的能力。嗯,我认为是授权和协调。残酷的现实是,一个程序员能做的毕竟有限。当你向上扩展和升级时,你会很快意识到作为一名在键盘上敲击代码的个人能力的上限。无论你打字速度有多快,或者你擅长什么编程语言和工具,在某个点上都是如此。如果你继续试图提升你个人的独立能力,你就会遇到瓶颈。有些人天生就有更高的上限,但一个人才华横溢的人要做到像一个组织良好、协调一致的团队那样快速和彻底,是不可能的,尤其是在有人拥有清晰愿景的领导下。所以这里有几个我想重点关注的点。能力是大多数人想到工程师级别时所想的。就像你的头衔越高级,你写代码的能力就越强。理论上来说,你在竞争性编程练习中的表现会更好,独立解决问题的速度会更快。我认为随着你的进步,所有这些技能都会有所不同。这是一个糟糕的看待方式。如果你用级别来衡量这些能力,这是我与行业内人士合作的经验中的粗略平均值。刚毕业的初级开发者的能力不会很高。他们清晰度在于他们能够清楚地描述他们正在做什么,为什么这样做,他们遇到了什么问题,以及他们的工作有多重要,同时他们的清晰度也会非常低,因为他们还不知道哪些细节重要,哪些不重要。我无法告诉你多少次我审查初级开发者的工作计划,他们会谈论语法、语言或其他东西。就像这些都不重要,特别是如果你在一个现有的代码库中工作。就像我不需要一个关于你如何格式化 React 代码中的 hooks 的部分。我不在乎。职业生涯早期人们非常普遍的做法。他们的授权和协调能力显然是零。他们还不知道如何分解工作,因为他们甚至还不知道他们正在做什么。高级开发者,你会看到能力上的巨大飞跃和清晰度上的有意义的飞跃。但授权和协调通常还不是他们的强项。但你会注意到,高级开发者在能力和清晰度方面已经非常接近极限了。所以,提高写代码的能力和提高写关于你写代码的能力并不能保证你什么。它不会让你升职。提高写代码的能力不会有有意义的改进,因为就像从初级到高级,这是 3 倍的提升。从高级到员工,即使他们是 10 分满分或 11 分满分,你从这两种之间的 3 倍提升到最多 20% 的增长。这根本不值得。显然,这之间有一个中间地带,但我不在乎。我们在这里是为了谈论这个。我试图澄清这些角色之间的区别。一个高级开发者在自己写代码方面有多好并不重要,因为大多数高质量的高级开发者不再做这件事了。他们现在更专注于工作如何完成,而不是他们将如何完成工作。理想情况下,一个好的高级开发者不会深入细节,远不如初级开发者。我职业生涯早期最美好的感觉是,当我还是初级开发者时,我所在的团队中的高级和员工开发者会意识到我足够了解我在做什么,他们可以把事情交给我。很多时候,这来自于我在职业生涯早期就超出了清晰度的期望,当时我更擅长描述发生了什么以及为什么,以及为什么某个特定的解决方案行不通。这让与我合作的员工和首席工程师建立了巨大的信心。这似乎是关于人工智能软件开发视频的一个奇怪的跑题,对吧?但如果我告诉你,当你做人工智能编码时,这项技能就不那么重要了呢?而这些技能则变得更加重要。嗯。结果发现,当你描述你想构建的东西、它出了什么问题、存在什么问题以及如何解决它们时,在清晰度方面做得好,在提示代理时非常有用。结果发现,当你试图将大块工作分解成可以由不同方(无论是代理还是早期开发者)独立解决的小块时,授权对于代理来说非常有用。而协调显然对所有这些都至关重要。残酷的现实是,我们的行业长期以来对能力过度依赖。你独立编写代码的数量一直是人们喜欢炫耀的奇怪资本,即使到今天,人们仍然喜欢吹嘘他们在 GitHub 上的贡献图表,因为你交付了多少代码一直是我们衡量你作为开发者的能力的方式。我一直不喜欢这一点,即使它是一个让我看起来不错的衡量标准,因为我过去交付了大量的代码。学习到其他方面,特别是授权和协调,对于你升级并构建更大、更重要的软件至关重要,这对我来说是一个非常、非常艰难的克服过程。但我也认为这就是为什么我一直如此享受这些工具,因为我在 2021 年辞职,创办了一家初创公司,现在我不断地阻碍自己和我的团队。这些是我需要提升的技能,才能完成我所做的工作。信不信由你,我们刚才谈到的所有人,Anti-Res、Lionus、DHH、Michael(Effect 的创造者),所有这些人也都非常专注于这些技能。他们中的许多人仍然喜欢自己写代码。但 Lionus 现在不再为 Linux 内核写太多代码了。他实际上做出贡献的次数非常少。通常,他会将一个想法发送到邮件列表,然后他信任的人会进行更改,将补丁通过电子邮件发送给他,如果他喜欢,他就会应用它。从这个意义上说,他实际上是第一个“氛围编码者”。他实际上在阅读代码。所以“氛围编码”的定义不一定匹配,但核心思想是写下你想要什么以及如何完成它的清晰、简洁的描述,看到结果,然后将其引入代码库。它是否由人工智能完成,还是由人类完成,这并不重要。这些都是一样的。我看到人们在聊天中有了这种认识。这是真的。那些过度依赖代码的人不理解工程师的含义,而不仅仅是程序员。是的。软件工程正朝着真正的工程方向发展。这种协调性非常重要,而这正是正在发生的变化。我不想点名任何人,但如果你去看看那些对人工智能编码非常反感的人,我不会说他们能力如何,因为他们中的许多人都是非常有能力的工程师,并且建造了令人难以置信的东西。但如果你看看他们的历史,看看他们做过的工作,看看他们工作的方式,他们担任过的职位,以及他们领导的团队(如果他们领导过团队),你会发现他们往往缺乏这些其他领域,特别是授权和协调。这并不意味着他们是初级开发者。这仅仅意味着那些让你非常擅长使用这些工具的技能不是他们的强项。如果你是一个 10 分满分的能力工程师,你可以写出令人难以置信的代码,但你在管理团队或在员工之间授权方面不够好,这对你来说会困难得多。幸运的是,这就是我们在软件开发中为头衔所做的,高级是你能获得的最高级别,完全基于你写代码的能力,然后其余的则来自你沟通、运营和管理团队的能力。而代理是早期提升这项技能的一个很棒的方式。这就是我最喜欢的部分。你可以通过这种方式成为一名优秀的经理。我认为这将迫使大量开发者在清晰的需求、并行管理工作以及拒绝不达标的工作等方面做得更好。它唯一不会教会他们的是礼貌。因为告诉代理“你的 PR 很糟糕。我关闭它”比告诉团队中的一个人要容易得多。但这些技能非常重要。就像在人类层面一样,如果你想做得更多、更有能力,你就必须擅长授权和协调。你必须提高你将他人引入工作的能力,他们可能不像你一样擅长写代码。因为这是你第一次拥有它时会有的最奇怪的感觉之一。我仍然会时不时地有那种奇怪的感觉,当我有工作时,我知道我该怎么做,我可以在一天内完成,但我选择把它交给团队中的某个人,而这个人不会花一天时间。他们会花三四天时间,第一次的结果可能不如我做的,然后我需要给他们很多反馈,然后等待下一次修改,而这件本该花我一天时间的事情可能会花费一两周时间。这感觉像是一种失败。如果你衡量你的能力,衡量你的价值,通过你交付了多少代码,感觉会更糟。如果你整天都在开会,把本应花你一天时间完成的任务分解成需要几周时间才能完成的任务,你会觉得自己没有做什么,而且会很糟糕。但当其中一项工作成功并交付了,然后出现了 bug,写代码的人去修复那个 bug。这时你就会明白为什么你要这样做,因为你不可能完成所有那些一天就能完成的任务,然后随着时间的推移维护那些一天就能完成的部分。但如果其他人以他们理解的方式构建它,它就能在团队中传播所有权和理解,让你能够更有信心地交付更多内容,并分配工作。这不仅仅是团队的工作,也是所有权。而这正是你与人工智能失去的一点。Claude Code 不会为它犯的错误承担责任。它不会理解为什么会出现问题并自动为你解决。你可以尝试协调工具来实现这一点,但由于上下文窗口的工作方式,它们不会记住它们为什么做某事。所以,有些技能你无法通过这种方式学到。但总体的想法是放手,认识到你的时间最好花在思考系统以及各个部分如何协同工作上,而不是花在编辑器中的代码文件里写代码。让细节不再是你的问题。这是关键。我认为最好的人工智能开发者是那些已经认识到这一点的人。那些在这些工具上走得最远的人不是那些刚刚学会编码的人。而是那些已经编码了很长时间,并意识到这些工具比雇佣一个 20 人的团队并让他们全部入职要容易得多、便宜得多的人。所以,尽管这样说很糟糕,但我真的认为那些反人工智能的人只是没有很好地管理过团队,也不理解这一点。这没关系。大多数开发者都不理解。历史上,这个专栏里的人数大约是那个专栏的 50 倍。大多数开发者不具备这些技能。这种情况必须改变。越来越多的开发者需要提升他们清晰解释他们正在做什么以及为什么这样做的能力。更多的开发者需要擅长将他们的工作分配给其他人或代理,协调所有这一切,并将其整合在一起。我们现在都是经理了。如果你不想当经理,那没关系。我不知道你的工作能持续多久,但我们都需要这样做。你做得越多,在这方面做得越好,这些工具对你就会越有用,你就能应对越大的事情。我确信这个评论区不会是一场灾难。说真的,我希望你把它看作是一个机会,来提升你的沟通和清晰度,当你描述你想要完成的工作时,而不是对你编写软件的能力进行攻击。未来是令人兴奋的,但前提是你允许它如此。我真的对未来的发展感到兴奋。让我知道你们的想法。下次再见,各位宅男。