Transcription
“随性编程”对你来说意味着什么？
>> 随性编程与AI辅助工程不同，我觉得这种区别非常关键，因为我们不想贬低工程这门学科的价值。
你个人如何使用这些工具？
>> 我最近一直专注于“规范驱动开发”的理念。对我想构建的东西有一个非常清晰的计划。如果你乐于进行测试，这会是降低你在编码中使用大型语言模型风险的好方法。我已经在自己身上注意到的一件事是，我正在失去一点批判性。
[音乐] 对我们来说，能够思考事物如何运作，能够在不完全依赖AI的情况下解决问题，将继续非常重要。测试和重新测试你的批判性思维能力将很重要。
你正在一个更大的团队中工作，Chrome团队，以及其他团队。你在谷歌这样的公司观察到了什么关于AI的现象？
>> 我们意识到的是，谷歌等公司的专业软件工程师如何超越随性编程，利用AI加速他们的日常工作？艾迪·奥斯马尼已经在Chrome团队工作了13年。如果你曾打开Chrome的开发者工具，你肯定用过他开发的东西。他也是一位多产的作家。他的最新著作名为《超越随性编程》，面向专业软件工程师。今天我们将深入探讨随性编程与AI辅助工程，以及为什么随性编程除了快速粗糙地制作原型之外，用处不大。理解模型作用的重要性。为什么艾迪总是阅读他所用模型的思维日志，以确保在批准更改之前完全理解它做了什么以及为什么。AI驱动的新开发工作流程，例如规范驱动开发、异步编码后台代理以及多个代理并行编码等，都是软件工程中新的、未探索的领域，还有更多。如果你是一名软件工程师，希望在日常工作中更好地使用AI编码工具，并希望利用AI工具构建可靠的软件，那么本期节目就是为你准备的。本期播客由Statsig呈现，Statsig是一个统一的平台，提供特性开关、分析、实验等功能。查看节目说明以了解更多关于他们和我们本季其他赞助商的信息。那么，艾迪，欢迎来到播客。谢谢，很高兴来到这里。你写了很多不同的书，比如《领导高效工程团队》。这本书大约一年前出版，现在你的最新著作名为《超越随性编程》。在你的Substack上，你也写了很多关于你对随性编程/AI辅助开发的学习心得。在这本书和你的博客中，你谈到了随性编程与AI辅助软件工程。在你看来，随性编程具体对你意味着什么？它与AI辅助软件工程有何不同或相似之处？
>> 是的。所以，我一直倾向于告诉大家，我个人认为随性编程与AI辅助工程不同。我觉得这种区别非常关键，因为我们不想贬低工程这门学科的价值，也不想给那些刚进入这个行业的人一个关于构建健壮的生产就绪软件所需条件的片面印象。但我对它们大概有两个定义。我认为随性编程真正关乎的是完全沉浸在AI的创作流程中。因此，它非常注重高级提示，并且在很多方面忘记了代码的存在。所以，你知道，这可以追溯到安德烈·卡尔帕西最初的定义，但它关乎接受AI的建议，而不必进行深入审查，并专注于快速迭代实验。我个人认为它非常适合原型、最小可行产品和学习。而且，我认为在生产团队中，它在快速尝试想法和建立对一个想法可能是什么样子、一个组件可能是什么样子、一个最小可行产品可能是什么样子的直觉方面非常有用。这往往优先考虑速度和探索，而不是正确性和可维护性等我们可能在为大量生产受众构建事物时稍微关心的事情。我想说，随性编程和更接近传统软件工程的做法之间存在一个光谱。你知道，做更多的规划，更多的规范驱动开发，包含足够的上下文，以及真正贯穿整个软件开发生命周期的AI辅助工程。所以对我来说，AI辅助工程是AI作为一个强大的协作者，但它不能替代工程原则。因此，在这种模式下，它是一个力量倍增器，可以帮助你完成整个周期，无论是样板代码、调试还是部署。但最大的区别在于，人类工程师始终牢牢掌控着一切，你负责思考架构，审查模型，并理解AI为你生成的大部分（如果不是全部）代码。你真的有责任确保最终产品是安全、可扩展和可维护的。也许AI能帮助你提高速度，这很棒，但这并不意味着你可以在一天结束时推卸你对质量的责任。我倾向于认为，很多人都说他们发现AI和编码是一个力量倍增器，但我发现你在软件工程方面的专业知识越丰富，使用大型语言模型时获得的结果就越好。有时，如果你刚进入这个行业或者是一名初级工程师，可能有一些我们认为是传统最佳实践的东西，你可能还没有经历过或思考过。比如，如果你关心生产质量编程，你可能应该只将你能完全向他人解释的代码提交到你的仓库中，因为仅仅期望AI能帮助你解决以后发生的任何混乱，可能长期来看是行不通的。
你个人如何使用这些工具？无论是随性编程，尤其是AI辅助工程？
>> 我最近一直专注于“规范驱动开发”的理念，对我想构建的东西有一个非常清晰的计划。我认为，你知道，我肯定仍然会在某些地方进行随性编程，如果它是用于个人工具、一次性工具，或者你知道，在过去，如果一个工程师或产品经理有一个想法，我们可能会制作一个快速模拟图，或者一个线框图，或者一个草图之类的东西，也许会与用户体验团队合作，想出一些更精致的东西。现在，你可以随性编程一个原型，并实际向某人展示在一个拉取请求中或在聊天中说：“嘿，这是我心中这个愿景的一个更清晰的版本。”我认为这非常有力量，我喜欢随性编程这一点。它只是能给我一个更高质量的方式来分享一个想法。随性编程正当其时。在提示中描述一个应用程序，然后砰的一声，你就得到了一个运行中的东西。感觉就像魔法一样。但随性编程没有考虑到的是：机构知识。每个提示都源于你告诉它的内容，而不是你的团队已经知道的内容。真正的产品开发恰恰相反。它是累积的上下文。例如，每个错误都有某种历史。每个功能都与客户请求相关联。每个拉取请求都符合你团队的路线图。一个简短的提示不会分享所有这些额外的上下文供代理使用。Linear代理在这些额外的团队上下文中工作。它们存在于你的开发系统中，实际工作发生的地方。它们看到阻碍你冲刺的问题、相关的拉取请求、项目目标、你的团队已经就这个确切问题进行的讨论。而且因为Linear是你团队的共享工作区，代理不仅看到你的上下文，它们还看到你整个组织的上下文，来自支持部门的错误报告，来自你的产品经理的设计规范，来自技术负责人的架构说明。所以当你要求一个代理起草拉取请求或构建一个功能时，它不是仅仅根据一个提示即兴创作。它使用的是你的团队已经使用的相同上下文。这就是当你构建真实的东西时，AI驱动的开发的样子。不仅仅是快速构建，而是有目的地构建。在linear.app/agents上查看代理如何在Linear中工作。如果你想亲自尝试它们，请访问linear.app/pragmatic免费获取Linear商业版。这并不意味着我们把随性编程的原型或代码直接投入生产。一旦你对组件、功能或视图的愿景有了清晰的理解，你可能应该写下：“好吧，对此的实际期望是什么？我们实际认为的需求是什么？”这通常会让你从大型语言模型那里得到更高质量的结果。因为否则，如果你随性而为，你也在某种程度上放任自流，说：“好吧，你来决定架构，你来决定这应该做什么。”虽然这对于构思来说没问题，但对于生产级产品工程来说可能不够。所以对我来说，规范驱动开发一直是一件大事。我认为测试很棒。如果你乐于进行测试，这会是降低你在编码中使用大型语言模型风险的好方法，因为有时，即使你使用最先进的模型，你也可能陷入代码看起来比你预期更复杂，或者你的前几个提示生成了非常好的代码，然后出于某种原因事情脱轨的情况。但如果你能通过测试证明事情正在运行，并且如果出现问题，你能更清楚地知道那是什么，我认为这可以帮助你的项目始终保持正常运行。这对我帮助也很大。所以，规范驱动开发和测试，我还努力确保我正在利用，你知道，这大概是一个宣传。我的团队刚刚发布了Chrome开发者工具MCP。所以我使用……
>> 是的。所以我们刚刚发布了Chrome开发者工具MCP。我非常关心质量，我认为在过去几年中，我们看到了许多情况，如果你注意到有什么东西坏了。我会看到很多工程师会说：“好吧，嘿，大型语言模型，这个按钮好像不对劲，或者这个东西好像不太符合预期。去修复它。”这又有点接近于随性而为。但如果你能让像浏览器这样的东西参与进来，或者能实际看到页面的东西，这就是Chrome开发者工具MCP和相关解决方案所做的事情。它们在很多方面赋予你的大型语言模型“眼睛”。所以它能看到浏览器看到的东西。它能看到正在渲染什么或没有渲染什么。它能检测控制台中是否有警告、错误。甚至能更深入地了解哪里出了问题。这可以改善你的反馈循环。所以我一直对MCP感到兴奋，因为它能够帮助我们通过调用其他工具的想法，大大改进我们的工作流程。这很棒。否则，对我来说，总的来说，我发现你确实需要付出努力才能熟练使用这些工具，而且我仍然发现自己正在这样做，如果有新的模型、新的工具、新的平台出现。我通常每周都会进行大量的实验。我尝试鼓励我的团队与彼此和我分享，比如事情进展如何？有什么值得我们提出或我们团队应该尝试的见解吗？如果你的团队看到你非常乐于共同学习，我认为这可以创造一种良好的心理安全文化，为你的团队在经历这个重大变革时期取得成功做好准备。
>> 是的。我感觉，你说的学习这些东西需要时间，我通过使用它，有很多或大或小的顿悟时刻。很多人对此持怀疑态度，尤其是工程师，他们对大型语言模型持怀疑态度，无论是理论、能源足迹还是其他方面。但我发现很多持怀疑态度的人要么没有尝试过，要么没有花时间去尝试，因为它确实需要一些时间，一些摸索，而且你知道，就像渲染器一样，它并非处处都有效，它会犯错，它会搞砸。但它确实，我想如果你没有，我只能为自己说，但我发现了很多它能帮助我甚至更小的项目的方式。正如你所说，这取决于什么对你有效，什么对他人有效。说到这个，你正在一个更大的团队，一个更大的生产团队中工作。你知道，你有Chrome团队，还有其他团队。你观察到其他人如何使用它，以及一些有趣的方式，也许是意想不到的方式，甚至是那些对特定的人或工程师来说可能没有奏效的方式？
我想说，在谷歌这样的公司，我们有一种非常长期、经过实战检验的规模化软件工程思维方式。而对于AI，我们意识到，很多东西并没有消失。你仍然会关心质量。你仍然会关心尽职调查。我们发现有趣的事情，有点模仿了初创公司和其他类型公司所看到的情况。所以，掌握理解“提示工程”的重要性，对吧？比如，确保你正在构建正确的指令集，以从大型语言模型中获得最佳结果，然后是“上下文工程”，最近，你如何确保你正在优化上下文窗口，以增加这些结果质量更高的机会。我们花了很多时间思考这个问题。确保正确的描述、细节、文件、示例、任何额外的、特定于项目但大型语言模型训练数据中可能没有的内容。这在我们工作中一直非常有趣和重要。在过去几年里，我一直尝试在生活的方方面面探索使用AI。这在有意义的生产力提升方面以及模型质量或系统提示和工具质量尚未完全到位的地方，都非常令人大开眼界。所以，我也一直在朝这个方向推动我的团队。比如，如果你正在思考我们最终都将成为AI原生工程师这个想法，那么对你来说，一个提示是，在你尝试自己解决问题之前，如果你把这个问题交给一个模型，交给AI，它会怎么做？它真的会帮助你更快地实现目标，还是可能会拖慢你的速度？如果它会拖慢你的速度，那为什么会这样？但即使是这个提示，我认为也能帮助我们了解很多可能和不可能的事情。我们很多人都经历过这样的旅程，你知道，如果你是一个经典的软件工程师，如果你是一个网页开发者，等等，你可能对AI没有这种非常深入的理解。对我自己和我的几位主管来说，我给自己设定了这样一个任务：好吧，让我们开始在这些领域成为更深入的专家，这样我们就可以指导我们的团队，让他们知道在哪里建立这种专业知识也会有用。所以，在过去一年里，我花了很多时间思考评估基准，以及我们应该多大程度上关心RAG（检索增强生成）与微调等等。这最终也做出了贡献，因为在我们讨论AI辅助工程的同时，我们开发的许多产品也考虑到了AI是否会帮助你以某种方式提供更好的客户体验。所以我正在研究，我们为编码工作流程所做的工作如何也能惠及我们必须做的产品工作。所以这对我们来说是一个很好的学习。我认为，老实说，始终保持人工监督的重要性是更大的学习之一。我们当然，我知道很多人都遇到过这种情况。我们当然看到过这样的案例，人们，通常是外部贡献者，有时会非常热情地表示：“嘿，我想为你的项目做贡献！”但他们会使用大型语言模型……
>> 知道你要说什么了，是的，使用大型语言模型并提交一些东西，我认为Machal Hashimoto在社交媒体上大发雷霆，因为他受够了人们提交的东西，正如你所说，出于好意，但给维护者带来了更多的负担。我喜欢阅读关于不同开发者群体如何看待AI以及这对他们的团队意味着什么的研究。我最近读到的一项研究强调，如果你提高了代码和改进的速度，并且团队中有人工监督，那么人工审查将成为瓶颈。这就是团队开始意识到的：“哦，等等，我们开始看到更多的拉取请求，但谁来审查这些呢？”所以，我很高兴团队，至少有些团队似乎足够关心质量维度，会亲自进行人工审查。但这确实也意味着我们的工作流程可能需要演变。我看到很多关于“为什么我们不使用大型语言模型来做代码审查呢？”的讨论，这有点像一个滑坡谬误，因为如果AI编写代码，而你没有仔细研究它，但AI也在审查代码，你真的确定提交的是什么吗？所以，我认为代码审查的最佳实践仍在发展中，我很期待看到它会走向何方。就我个人而言，我使用很多工具。我最喜欢的一些工具包括在VS Code中使用Klein。很多人……
>> 如果人们关注你关于Klein的著作，你就是它的忠实粉丝。
>> 是的，我喜欢Klein。我认为现在人们也可以在VS Code中使用Cursor和Co-pilot做很多事情。但我喜欢做的一件事是，你知道，大多数这些工具都会在你构建解决方案时，向你展示幕后发生的思考过程。即使它发生得很快，我也会尝试回去，滚动浏览，展开并阅读：“好吧，你构建这个的思考过程是什么？你做了哪些决定？你生成了什么？”我会在它最终进入拉取请求之前审查这些代码。将来很可能我需要维护这些代码，我可能需要对这些代码进行一些调整，而大型语言模型将无法帮助我。就在昨晚，我正在解决一个问题，代码在纸面上看起来是对的。但它没有按预期工作。我几次要求大型语言模型：“嘿，你能用你的工具去找出问题所在吗？”它继续进行更改。但实际上并没有修复根本问题。所以今晚我必须卷起袖子手动调试它。如果我不理解那段代码是如何工作的，或者我没有阅读它，我就会感觉自己被扔进了丛林，不得不自己摸索。
>> 嗯，而且我，我的意思是，反思一下，对吧？我觉得这就是一个物有所值的软件工程师和一个不值得的软件工程师之间的区别，如果你只会提示和提示。我的意思是，任何人都可以做到。我有点夸张，但一个应届毕业生可以做到，或者一个还在上大学的人。但不是每个人都会付出努力去理解，去知道它是如何工作的，并且能够在这些模型失败时（它们确实会失败）卷起袖子去修复它，而且他们还能向人们解释，在会议中清晰地解释，不啰嗦。所以我感觉，你知道，这就是专业人士，对吧？在任何行业都是如此，他们知道事物是如何运作的。汽车修理工也是如此。其他任何事情也是如此。所以，也许这只是一个提醒，如果你不这样做，如果你有点放任自流，觉得“哦，它解决了我的问题”，那么你就有风险，好吧，如果你不知道它是如何工作的，我的意思是，我们为什么需要你？任何人都可以提示另一个大型语言模型。
>> 完全正确。完全正确。你知道，当我们开始更多地谈论，在过去一年里，人们在终端、命令行界面中工作再次变得流行起来，有了Cloud Code、Gemini CLI和Open Code等等。然后人们开始讨论：“好吧，我们如何协调多个并行代理为我们完成工作？”当我们开始思考每个工程师几乎都有自己的虚拟团队，能够去处理你的待办事项并同时完成所有这些不同的任务时，你会很快意识到，这一切在抽象和理论上听起来很棒，但你会加剧所有这些其他问题，即缺乏人工审查可能会导致一定程度的技术债务，也许不是立即，但在某个时候很可能会发生。我对此的经验在某个时候促使我写了一篇关于我称之为“70%问题”的文章。
我们来谈谈这个，因为你对此进行了广泛的撰写。我们实际上发表了一篇基于你文章的共享客座文章，我们也会在下面的注释中链接。什么是70%问题？你是如何发现它的？你认为自从你大约六个月前发表它以来，它可能发生了怎样的变化？
>> 是的，显然，模型质量和工具质量持续改进。所以70%问题实际上是关于这样一个想法：大型语言模型可以非常快速地粗略生成一个工作应用程序的70%，但它们往往在最后30%上遇到困难。这最后30%你可以认为是“最后一公里”，但它包含了许多不同类型的模式，你的受众可能会遇到，或者他们可能会遇到像“倒退两步”这样的情况。所以，你知道，你已经使用了几个提示来构建一些东西。你再给大型语言模型一个提示，它却完全走向了不同的方向。也许它完全重写了你的用户界面或组件背后的功能。诸如此类的事情。通常会有隐藏的可维护性成本，在你不够具体的地方。你将责任推回给大型语言模型。你最终可能会得到收益递减。你知道，正如我们在Hacker News上一次又一次看到的那样，安全漏洞，你知道，这正是我们看到人们不小心泄露API密钥、出现XSS问题、出现各种问题的地方，因为人们没有全面地思考他们正在解决的问题，只是随性而为。所以，一个随性编程的概念验证，你知道，对于最小可行产品和原型阶段来说是没问题的，但它很可能需要以生产质量为前提进行重写。如果你要将它提交到一个代码库中，与其他人、与团队合作，并且要处理一个真实的用户群，我认为安全和质量方面的问题，确实说明了需要让人工参与其中。
>> 是的。我们不断听到产品经理和技术背景较弱的创始人对随性编程感到非常兴奋的故事，他们快速启动一个原型或一个更好的版本，然后他们想构建一些可以投入生产的东西，但有很多故事。我会在节目说明中链接一个，关于他们如何陷入困境或花费很长时间。他们认为只需要一两天的事情，最终变成了10、20、30天。在70%问题中，你提到了一个相关的问题，你说经验丰富的工程师可以更容易地完成最后30%，而经验不足的工程师则更容易陷入困境或产生虚假的自信。
>> 是的。是的。完全正确。我认为，对于那最后30%，你经常会看到初级工程师、实习生或应届毕业生所做的是，他们真的不知道下一步该做什么，除了不断地重新提示大型语言模型来修复问题。如果模型无法做到，他们不一定具备所有那些调试问题或理解问题所在地的技能。所以这说明了拥有良好批判性思维和解决问题心态的重要性。你知道，我们总是谈论这对学习计算机科学的人的重要性。我认为现在仍然如此。但实际阅读代码、理解系统、理解所有这些部分如何连接在一起所需的严谨性，我认为这不一定会消失。正如你之前所说，有了我们今天拥有的工具和模型，几乎任何人都可以向工具提供一个高级提示，然后得到一些看起来能工作的东西，但我不一定会相信它能用于生产。目前已经看到太多事情脱轨的故事了。
>> 这让我想起，在AI工具出现之前，我有一个工程师加入了Uber，他来自一家小型初创公司，是一个新员工。所以一周后，我是这个人的经理，我问他情况如何，他非常沮丧。我说：“哦，这真的很难。”我说：“什么很难？”他说：“我正在努力阅读所有代码，这太多了。”我说：“你为什么要尝试阅读Uber的所有代码呢？”那可是我们的后端系统。它就像，你知道，移动应用程序，超过一百万行代码。他说：“我这样做是因为每当我加入新公司，我都会阅读所有代码来理解一切。”我说：“我理解你的出发点，我认为这很棒。我只是想向你解释代码库是如何运作的，你不应该阅读所有代码，但你应该理解结构，知道在哪里可以找到东西，因为这是一个我们有两三百名工程师在上面工作的代码库。”我认为这个人有很好的意图，那就是我来到一个新地方，我想理解，我将花前几周时间去理解，这些人会表现出色。我有点在想，我们一直在回到这个问题，但我从你这里听到的是，如果你能在某种程度上将这外包给一个大型语言模型，这有点碰运气，可能会成功也可能不会成功，但如果你这样做了，你现在就绝望地依赖它了。在某个时候，当上下文窗口填满，或者当模型状态不佳时（因为这些东西是非确定性的），你就会陷入困境。你知道，你最好的办法是尝试一个新的模型，或者清空上下文窗口，或者我不知道，做点别的什么，但这真的不像是你在掌控之中。
>> 是的。是的。你完全正确。我认为，无论你进入这个新世界的入口是随性编程，还是你是一名高级工程师，并且一直在改进你的AI工作流程，我认为每个人都应该记住一些事情，可以帮助你获得最佳结果。艾迪刚刚提到了获得最佳结果。以下是我对AI和随性编程的看法。这些工具可以给你带来惊人的速度。你可以比以前更快地发布功能。但没有精度的速度意味着你只是发布了更多东西，不一定是正确的东西。你如何知道你构建的东西是否真的有效？新的结账流程是提高了转化率还是损害了转化率？你发布的功能是帮助留存还是导致流失？如果在你推出和衡量方面没有精确性，你就是在盲目决策。这就是Statsig的作用。Statsig是我们本季的赞助伙伴，他们构建了一个与你的AI加速速度相匹配的精准工具包。这就是精准的样子。你在受控环境中向10%的用户发布一个功能，看看它是否提高了或降低了你的指标。如果转化率下降，你就能及早发现并在影响所有人之前回滚。你正在以与你发布代码相同的速度做出精确的数据驱动决策。以Graphite为例。他们使用Statsig将细粒度控制和快速迭代融入到他们的开发工作流程中。当他们推出一个新功能时，内置分析会准确显示它如何影响他们的关键指标。他们可以看到参与度是否上升，功能是否导致错误，或者用户是否流失。他们通过功能门和指标协同工作来实现这一点。他们随时都在运行300多个这样的受控发布。在生产事故期间，这种方法将他们的解决时间缩短了50%以上，因为他们可以快速识别是哪个功能开关导致了问题并立即修复。大多数团队会拼凑不同的系统，等待查询，并尝试关联不匹配的用户群。当他们知道某个东西是否奏效时，他们已经转向了下一个功能。有了Statsig，你拥有一站式服务。功能开关、实验和分析都使用相同的用户数据。Statsig提供慷慨的免费套餐，团队专业版每月150美元起。要了解更多信息并获得30天企业试用，请访问statsig.com/pragmatic。有了这些，让我们回到关于AI和开发工作流程的对话。理解，你知道，模型往往具有有限的上下文窗口。它们随着时间的推移变得越来越大。你可能需要在某种程度上采纳项目经理的心态。你知道，将任务分解成小的、可验证的块。我看到很多人会把所有东西都扔给大型语言模型，说：“嘿，是的，一次性构建所有这些需求。”但这不一定能达到最佳效果。所以，你知道，小的、可验证的块，清晰的期望，并准备好与AI迭代。不要觉得一次性完成就能给你带来最佳结果，因为它可能不会。而且这种分解实际上与规划冲刺或编写伪代码非常相似，这是我们过去会做的事情。它降低了上下文丢失和复合错误的风险。我认为软件工程中的许多最佳实践即使有了AI编码也仍然是永恒的。所以，关心模块化、可测试的代码，强制执行代码审查，你知道，AI会引入一些新习惯，比如思考输入和输出约束，并提供足够的上下文，但这并不意味着你无法从中获得好的输出。它确实意味着你需要在人工参与的情况下施加一定程度的严谨性，以确保你为成功做好了准备。你越是放弃对大型语言模型的责任，事情脱轨的风险就越高。
>> 是的。我从一位工程师那里听到一件事，实际上是Armin Ronacher，他是一位资深的Sentry工程师，Flask和许多开源框架的创建者。他告诉我，他观察到那些牢牢掌控自己工作、对自己任务非常有信心的工程师，他们在使用AI时取得了更大的成功。而那些觉得自己对工作、对任务没有太多控制权，只是被分配了任务，并且有点像“世界掌控我”心态的人，他们对AI以及它将做什么感到更加恐慌。这非常有趣，因为我们正在谈论它，我从我们的对话中感受到的是，你的很多建议都归结为：掌控一切，理解一切。自信，你知道，如果这个东西被拿走了，你也能毫无问题地取得进展，只是会慢一点。只要你拥有这种心态，感觉一切都更容易了。而且保持这种心态，你知道，就像你说的，你仍然会仔细阅读思考过程，你更喜欢那些能向你解释的模型，然后如果你愿意，你可以回去查看，而且你经常这样做。你仔细阅读以确保学习。此外，这还有点乐趣。你不断地专业学习。你每天都在进步。
>> 绝对正确。绝对正确。我想起，你知道，AI只是你工具箱中的另一个工具。你知道，我们随着时间的推移，经历了许多不同的时刻，工程和开发者体验在每一代都在变得更好。你知道，当我刚开始的时候，我记得当模板成为一种东西时，我感到很兴奋。
>> 你是说你可以用模板生成代码吗？
>> 哦，不。只是下载用于UI构思的模板，用于在网络上开始。
>> 在网络上，对吧？
>> 是的。在网络上，这只是最简单的事情。它就像一个压缩文件，对吧？别人创建的。但是，好吧，所以我改进了我的起点，然后我们有了更强大的命令行界面、脚手架之类的东西。然后你就不必担心确切的起点。我觉得这只是让我们向前迈了几步。它让我们更容易引导一个看起来能工作的解决方案，但仍然需要你真正理解你正在放入代码库、发布给用户的东西，而不是在一天结束时摆脱你的责任。我发现，至少对我来说，在过去一两年里，回到第一性原理总是很有帮助的。我一直在与Google DeepMind团队更密切地合作，研究Gemini及其编码能力，这对我来说是一个很好的提醒，让我理解这些东西在幕后是如何运作的。如果你记住，你知道，什么是训练数据？好吧，它很可能是在GitHub上或开放网络上宽松许可的代码。这些代码中的模式很可能反映了在许多情况下是最低公分母的东西，也许只是能工作。它们会是最安全、最高性能、最易访问的吗？可能不会。所以如果你记住训练数据本身仍然需要大量工作才能真正将事情达到生产质量的水平，你就会在与大型语言模型合作时稍微降低你的期望。你会意识到，是的，它可能比我只是从其他地方复制粘贴代码片段做得更好，显然，但我仍然很可能需要在此之上进行一定程度的手动工作或严谨性才能获得最佳输出。
>> 是的，这让我想起大约十年前左右，五到十年前，我们大量使用Stack Overflow，因为当你搜索某些东西时，它就在那里。所以，例如，对于电子邮件验证，你会搜索“我如何验证电子邮件地址？”Stack Overflow上有一个问题，有大约20个答案。其中一个评分最高。它是一个正则表达式。我所做的，我认为很多人也做了，就是我直接复制粘贴了，因为我不想费心去精确定义电子邮件的正则表达式，那比简单的事情复杂得多。所以我只是那样做了，如果不是为了什么重要的事情，它也奏效了。但后来出现了抱怨和警告，其中一些（不是这个具体的例子）是不安全的，或者没有考虑到边缘情况。很多开发者，当你在无意识模式下，或者不重要，或者你更了解时，你就会这样做。我想我们将在更大规模上遇到同样的事情：为什么会发生这个错误？你会回顾历史，是的，有人只是觉得那个大的拉取请求“看起来不错”，而那个拉取请求最终是由AI生成的。
>> 我认为这在很大程度上是一个较小的点，一个旁支讨论点，但我看到了一些案例，人们现在会说：“你知道，嘿，如果我能自己提示一个略微小一点的解决方案版本，我还需要使用第三方库吗？”这让我想起了Stack Overflow复制粘贴排名最高的回复这件事。如果你是一名高级工程师，你会意识到：“等等，那也意味着你现在承担了确保它能经受住未来的安全问题和各种平台问题的责任。”如果你依赖一个库，那么可能更容易有一个核心杠杆点，可以在那里进行修复，然后部署给人们。如果你自己拥有代码库中所有这些不同的模式，那也意味着你承担了这份责任，这完全没问题，但有时我看到人们只是没有意识到这需要额外的工作。
>> 我觉得这就是我们需要提醒自己，这只是工程，对吧？这是权衡。你是否承担维护这个东西的责任和风险，以及它可能存在遗漏的边缘情况或可能无法正确或安全地工作的事实？或者你是否承担一个有其自身问题的依赖，比如现在有了依赖安全等等。但说到软件工程的需求，有哪些新的工作流程，我们作为软件工程师以前无法做到的事情，现在我们可以用这些AI工具进行尝试，而且是全新的？
>> 是的。我认为对我来说，最让我兴奋并看到其发展的是“异步后台编码代理”这个想法。目前有许多团队正在尝试这些想法。Jules、Codec、CodeX，我们也看到GitHub也在尝试其中一些想法。我认为，你能够委托你的待办事项的一部分，并让一个系统能够异步实现这个想法，这是一个非常有趣的想法。如果我们能做到这一点，没有合并冲突，并且易于人工验证。所以又回到了人工参与。我认为这非常有趣。我发现，如果你让一个代理负责编写或更新你的测试，或者你有多个代理一起工作，尝试将你的代码库从一个库版本迁移到另一个版本，或者从一个依赖版本迁移到另一个版本，它们现在在这类工作上做得相当不错。较小的更改，比如我们都必须做很多事情，例如添加暗模式，这类较小的更改，如果能够将这些更改委托给代理，它们会做得非常好。我对此感到兴奋。我认为，对于确切的界面，如果你是这个管弦乐队的指挥，你管理所有这些事情的正确界面是什么，以及你同时管理任务的实际数量是多少，目前还没有定论。因为，你知道，即使是我，很多人都展示过：“嘿，是的，我打开了20个不同的终端，其中一半运行着quad code，然后Gemini也在运行。”这看起来很有趣，但现实是你的注意力是有限的。如果你真的要在代码审查和每个工作流程中投入严谨性，你可能只能同时做几件事。你知道，这一切都回到了多任务处理的最佳实践，但我对此很感兴趣。我很想看看它会走向何方。另一件非常有趣的事情是“随性设计”。我看到产品工程、产品开发的一部分正在发生一些演变。看到Figma的MCP朝着这个方向发展，非常令人兴奋。这些东西让设计师和开发者能够更紧密地合作，或者至少让设计师能够将他们的愿景转化为一个功能原型，一个可能更接近代码的东西，然后可以投入生产，而不仅仅是一个一次性演示。
>> 是的，我听说Shopify的一位工程主管或设计主管说，她的团队中每个设计师，所以不是整个Shopify，都使用Cursor，他们所做的是创建一个Figma设计，然后要求Cursor实现它，然后他们将其展示给工程师，这并不是说要发布它。这更多的是我们现在有了一个可以一起工作的交互式东西，而不是他们过去常做的只是分享一个Figma设计。
我当时想，嗯，这我以前没听过。就像真的 [笑声] 就像所有设计师，或者至少在一个团队中使用开发者工具，我无法想象设计师会使用 Visual Studio Code。我的意思是，我可以想象他们能够打开它，但我无法想象他们会用它，因为它根本不是为他们设计的。所以听到这个真的非常非常有趣，而且这也不是什么供应商广告之类的。是的，我要向 Shopify 团队致敬。老实说，我觉得他们中的很多人都非常乐意分享他们团队的成功经验，我一直很喜欢关注他们的故事。我认为，这些模式的进一步推广将有点取决于培训、治理以及原型代码和生产代码之间清晰的界限。但能够将静态的东西变成半功能性的原型已经非常酷了。我们会看到每个人都使用光标吗？我不知道。我认为，至少对我来说，我看到人们能够通过他们花费最多时间的工具，或者通过工具之间日益完善的桥梁，来达到相同的效果。但我仍然觉得这非常非常令人兴奋。
同样地，我们也看到了很多关于产品经理（PM）和工程经理（EM）角色变化的良好讨论。产品经理可能会花更多时间在问题框架、指标和代理策略上。工程经理则会花更多时间在评估和安全审查上，真正让他们的团队能够自信地使用人工智能。这不会改变对结果的责任，但我看到了很多关于产品工程中“品味”需求的良好讨论。这将会是区分人们的关键，因为如果任何人都可以查看你所构建的东西，并使用提示来完成类似的功能集，那么“品味”这一部分在未来将继续是人们关注的非常有趣的一点。
你我曾谈论过初级和高级工程师。我认为，对于应届毕业生和高级工程师来说，未来将充满有趣的挑战。人工智能无疑提升了下限，但它也提升了上限。初级工程师将能够更快地行动，但那些能够编写规范、分解工作、理解系统架构、有效审查的高级工程师，我认为他们将变得更有价值。我们谈论的最后那 30%，我认为那是杠杆作用。不仅仅是忙碌的工作，我真的认为那是杠杆作用。而且，许多调查显示，目前信任处于一种谨慎但乐观的状态。但这种谨慎的部分说明了人类监督仍然非常核心的必要性。
是的。如果我想到，我刚才就在想，当谈到这种并行代理的概念时，我认为它从未以开发者能够做到这种方式实现过。我的意思是，我们甚至无法启动并用自然语言与一台机器对话，让它吐出实际能编译的代码，我认为这也很新颖。但你能够用多个代理来做到这一点，这在编程中以前从未发生过，这非常……你知道，你处于心流状态，你在解决一个问题，当你停止解决它时，你切换过去，你获得你的上下文，几乎就像堆栈清空了，你知道，你加载了新的东西，感觉就像那样，对吧？但另一方面，当我回想我认识的最好的高级工程师以及他们的一天是怎样的，他们在一个团队中，有几个中级工程师，可能还有一些实习生或应届毕业生，他们在做自己的事情，然后他们就是那些收到 Slack 消息的人，消息说：“嘿，你能帮我解除阻塞吗？”于是他们进行上下文切换，审查代码，你知道，比如批评它，或者他们会预留时间，然后审查审查再审查。对于每一种高级工程师，或者通常是技术负责人，他们都有几个人，你知道，他们不是代理，他们是人，但他们只是审查他们的工作，并在站会中稍微协调他们，你知道，他们在规划会议中，他们会推动他们，指导他们。所以，从某种意义上说，我觉得我们高级工程师已经这样做了。如果我有一根魔杖，说几年后我期望谁能够管理多个代理？嗯，高级工程师肯定可以，应届毕业生可能……我的意思是，我觉得对他们来说会是一个挑战，但他们不被期望拥有这种能力。他们没有专业知识。所以我想知道这些技能是否在某种程度上是可转移的，你知道，为什么那个高级工程师能做得那么好？因为他们理解代码库。他们知道好的代码是什么样的。他们在审查中总是非常彻底。他们从不让事情溜走。他们甚至会指出最小的问题。
我完全同意你的看法，而且我认为关于团队中开发者教育如何在这种时刻演变，有很多值得探讨的地方。从历史上看，我记得在我成长过程中，导师制一直是一个重要话题，我们讨论过，特别是对于加入新团队的人来说，结对编程的重要性。我认为我们将看到，甚至可能出现三人编程的情况，即一个初级工程师、一个高级工程师和人工智能，也许高级工程师会在那里，要求你以某种方式解释人工智能生成的代码，或者引导你了解该代码如何连接到系统的其他部分，并真正再次将其作为他们工具库中的一个额外工具，以帮助建立对整个应用程序实际工作方式的信心和认知。我们还看到一些有趣的讨论，关于潜在的新角色或角色细化，比如前线部署工程师。我看到人们对那些更深入地与客户融合的开发者感兴趣，他们可以利用人工智能快速构建功能，同时反馈需求。这类事情可能会稍微模糊开发者、产品经理和设计师角色之间的界限。我很想知道这最终会走向何方。我也很感兴趣，总的来说，人工智能工程将如何演变，我们如何对待教育，无论你是在高中还是大学。比如，我们是否会教人们提示和上下文工程的最佳实践？这一切到底会是什么样子？我们如何继续让人们在思考时考虑到系统设计和工程？但我对这方面的教育发展方向感到非常兴奋。
所以，我们讨论过的一个领域是代码审查，以及它有多么重要。它是一个瓶颈，我们应该审查代码。我已经开始注意到自己的一点是，当我使用这些人工智能工具时，无论是云代码、代理，甚至是自动补全，我都有轻敲 Tab 键或接受，或者直接接受所有内容的倾向，尤其是在我处理一些并非世界上最关键的事情时。这有点容易，尤其是在我开始相信它大多数时候都能做对之后。最终，我知道我会审查，但我发现自己失去了一点批判性。我不再像第一次不信任它时那样批判，你知道，第二天、第三天。我有点担心，代码审查也会发生同样的事情。你知道，LGTM（在我看来不错）。我的意思是，我理解谷歌在你的代码审查工具中内置了它作为一个功能，据我所知，这是一个非常有趣的工具。但存在这种风险。当然，这种风险一直存在，就是你觉得工作量很大，看起来还不错，然后你就不会批判性地看待它。你认为，特别是在正规团队中，我们如何才能对抗，或者说我们如何才能进行这种对抗，比如，是的，给予它适当的审查，特别是如果我们没有写那么多代码的话？因为我觉得在编写代码时，你有两次审查。一次是你自己编写代码。你把它敲出来，而我们现在不再那么做了。然后别人在知道是你敲出来的情况下进行审查。
我的意思是，写代码总是比阅读和审查代码更有趣。
有点，对吧？
是的。而且我认为我们越来越多的工作将是阅读和审查代码。我曾向人们提出过一些想法。比如，对于某些功能或一周中的某些日子，你可能有意尝试不依赖人工智能或大型语言模型，只是试着看看，好吧，我是否仍然可以自己解决其中一些问题，以保留你的批判性思维能力，并强迫你思考，好吧，假设所有顶级大型语言模型提供商都停机了一天，你会怎么做？开玩笑地说，你知道，我可能会说，是的，我只是要去使用 Olama 和一个本地模型，我会完全没问题。我会找到一些备用方案。但现实是，我确实认为，我们能够思考事物如何运作，能够在不一定依赖人工智能的情况下解决问题，这将继续非常重要。模型将继续变得更好。它们从你的代码库中获取足够上下文的能力将继续变得更好。但在我看来，在你能够完全相信在每种情况下，无论你向它提出什么要求，它都能做对之前，还需要相当长的时间。而且如果你卡住了，如果你尝试了五次、十次，它仍然没有解决问题，你将不得不自己解决问题。所以，我认为，能够强迫自己进入测试和重新测试批判性思维能力的情境将很重要。我还认为，围绕这个问题做一些博弈论也有点价值。团队或个人可能会开始依赖人工智能来做更多的代码审查，以跟上变化的步伐和速度。这些工作流程会是什么样子？如果你有一个代理说：“是的，我审查了这个 PR，看起来可以合并了”，你真的会相信它吗？还是你会去做一个人力级别的审查，即使它可能比你历史上做的更浅？或者你可能愿意花 10、20 分钟左右进行审查，那工作会是什么样子？
就我而言，即使一个代理告诉我某件事看起来可以合并，那也只是一个信号。它类似于一个信号，比如，好吧，也许我团队中的一个初级人员也给出了 LGTM。如果它足够关键，我仍然可能会回去检查。
或者 CI/CD 通过了所有测试，对吧？它是绿色的。所有测试都通过了。
没错。没错。它是一个信号。信号很有用，但你仍然希望运用你对质量的视角去审视它，并仔细检查，确保你充满信心。像拥有这些测试，拥有你和你的团队讨论过的任何质量门槛，将它们落实到位，所有这些都是建立信心的良好信号。所以，你拥有的信号越多，就能建立起更多的信心，确保合并时不会出轨，我认为这很好。但是，我尝试着非常刻意地确保我不会在所有事情上都依赖人工智能。我可能会在日常生活的许多方面使用它，包括人工智能编码，但我仍然努力确保，你知道，无论是 20% 还是 30% 或者任何数量的任务不一定需要人工智能，我仍然努力确保我正在用我的大脑自己解决这些问题。我认为这种刻意性，就像主动维护你的批判性思维技能一样，我认为这将帮助人们。
是的。而且其中一件事是，你仍然亲自动手，这让我想到两件事。一个是云代码最近发布了。你可以改变模式。你可以有解释模式，它会解释事情，你还有一个叫做学习模式的东西，它会暂停并说你来做这部分，我觉得这非常聪明。我实际上为我正在构建的东西打开了它。它没有像我预期的那样工作，因为它给了我一个非常奇怪的任务去做，但我看到了潜力，我实际上很想更多地依赖它，我认为我希望其他工具也能这样做，作为开发者的一部分。就像我感觉我确实想知道我能做到，而且我能做到，但如果我不做，我怎么知道我能做到呢？当然，你会稍微摆弄一下。
我认为那是一个非常棒的主意。如果有人是初级工程师，或者你正在接触一个你不熟悉的代码库，请克服那种“我要做的第一件事就是尝试提供价值，我将直接通过提示来创造一个新功能”的感觉。也许可以使用大型语言模型来解释代码库是如何工作的，并花时间沉浸在代码库的丰富性中，了解代码库是什么，它是如何工作的，所有东西是如何连接在一起的，然后再开始通过提示来创造事物。我认为将其作为学习工具是一种非常强大的东西，我们需要更多。这也是你所说的，新加入者使用学习工具。我从一些公司那里听说，他们看到新加入者更快地融入团队。那些能够使用这些人工智能工具向他们解释事物的人，就像基于云的工具，它就像一个 24/7 的值得信赖的人。你可以向高级工程师提问，我的意思是你可以随时提问，但显然你不想在 8 小时工作日里问 8 小时，你会保持你的限度，而且有趣的是，这正在改变许多拥有这些工具的工作场所的动态。
当然。我认为，我的希望是，将人工智能作为学习工具进行培训将成为一种更标准化的事情，而且它不仅仅是为了理解新的代码库。它对于理解编程概念、框架或架构模式都非常有用。有时，我希望能够将一个功能从一个非常不同或用不同编程语言编写的代码库移植到另一个代码库。我发现人工智能在这些情况下非常不可或缺，它帮助我理解一个代码库以及如何将某些东西移植到新的代码库。因此，鼓励你的团队尝试人工智能工具，分享他们的最佳实践，让人们知道将其作为学习工具是可以的，这成为一种常态，我认为这对你作为领导和管理者来说，将是非常棒的。
是的。你也是一个团队的经理，作为其中一部分，你显然会进行绩效评估、晋升，基本上帮助人们在职业上变得更好。你认为，自从这些工具出现以来的三到四年里，你对一个真正杰出、扎实的软件工程师的定义，或者你在团队中看到的定义，发生了怎样的变化？什么是新的，什么又是相同的？我认为新的地方在于重要性，你知道，我发现有一件事一直都是真理，那就是成为一个终身学习者的重要性，这始终是真理，无论框架来来去去，工具改变，行业发展，成为一个终身学习者，并且非常乐于尝试新事物，即使失败，也要培养这些技能，我认为这仍然非常非常重要。我团队中那些我认为早期在利用人工智能进行编码和产品工程方面最成功的人，是那些抱着“我乐于学习新事物，乐于尝试，并拥有这种成长心态，如果它不起作用也没关系，至少我尝试过了，至少我理解了限制，也许将来我会为这些不同的用例尝试不同的模型”这种心态的人。我认为这在很大程度上一直是一个重要的、持续不变的事情。我觉得如果你是一名领导，现在是你帮助团队度过这个时刻的时候，通过展示你也乐于学习。我每周都会做的一件事是，我花很多时间，我喜欢阅读。我花很多时间阅读。我当然会经常阅读你的时事通讯。我还会阅读许多不同的论文、白皮书、博客，观看视频，观看课程，你知道，阅读关于人工智能有什么新进展，人工智能工程有什么新进展的公告，在这一周内，我会在时事通讯中把这些东西呈现给我的团队。我还会呈现……
哦，你为你的团队准备了内部时事通讯？
是的，我有一个内部时事通讯。我每周一写。所以在这之后我就会写，我会包括我在做什么？我在写什么？我在想什么？我认为对我们团队来说真正重要的事情是什么？在这个时代，你知道，你看到很多人都在努力跟上最新进展，如果你关注 Twitter 或其他社交网络，会感到非常不知所措。
因为每隔几个小时，就感觉有什么东西发生了根本性的变化。
能够筛选这些信息并帮助人们只关注真正重要的事情，我认为这是领导层现在应该做的一件大事，特别是如果你能引导人们，嘿，也许花更多时间研究这个而不是那个。
我只想说，我认为这简直是轻而易举的成功，因为你也更贴近行业，更贴近技术，也许说亲自动手有点夸张，但你通过跟上所有这些进展，已经非常接近了。
是的。是的。而且，你知道，我我会把话语权交给我的团队成员去说，但我认为我通常对这方面收到了很好的反馈。我甚至有其他高管说：“嘿，实际上，我发现很难跟上这些进展，你的时事通讯也帮助我度过了这个时期。”所以，我认为作为一名领导，能够跟上正在发生的事情，无论你觉得哪个层面舒服，或者你的带宽允许，我认为这对你的团队来说都是一件非常强大的事情，并且会帮助你保持自己的技能相对敏锐。你知道，我们一直在谈论人工智能辅助工程。如果你的团队确实需要开发人工智能功能，很多这些东西对他们来说也将继续具有相关性，因为你可以帮助他们将行业中与人工智能相关的重要事情与不重要的事情联系起来。我认为这在当前尤为重要，因为可能有些事情是他们历史上不必考虑的，比如，哦，模型 X 在图像生成方面非常出色，但模型 Y 在声音生成方面非常出色。我只是随便举例，但我认为你能够以更具体的方式突出其中一些机会，然后你的团队就可以自己去深入研究，而不是从零开始。另外，我想你只是在展示，看，我在学习。我花时间阅读、理解、消化。我在业余时间做一些事情，这有点像给了许可，表明这样做是可以的。而且，如果有什么的话，我的意思是，你知道，每个人都为自己，但我会假设，现在因为我们正在经历这项技术的巨大变革。它是一个新工具，有很多功能。在大多数公司和大多数团队中，除非你正处于紧急关头，比如周五要发布什么东西，否则工程师花一些时间进行实验，弄清楚，嘿，我能用这个东西吗？它会对我有效吗？这应该是可以的。你知道，当我再次与 Shopify 的人交谈时，他们做了很多这样的事情，最终实际上，有些人认为可能会发生的事情是，嗯，人们会减少工作。实际上，发生的是他们做了和以前一样的工作，但他们更有动力了。他们尝试了一堆新东西。有些不起作用，这有点像你认为的浪费，但实际上不是。那是学习，现在他们对什么有效，什么无效更有信心了。你知道，他们会自信地说，好吧，我们不会使用人工智能来生成代码库的这一部分，但对于原型设计来说很棒，等等。所以，我觉得每个人都在摸索。所以，不给予许可几乎是一种浪费。还有什么比展示你自己也在这样做更好的方式来获得许可呢？
是的。是的。绝对是。人工智能是一种工具，我认为能够压缩工作的工具也能带来清晰的时刻。尝试某些类别的想法比以往任何时候都快。而且我认为这种效率有时也能凸显我们人类品质的重要性，当涉及到判断我们应该推进什么，应该忽略什么，应该最小化什么时。我认为在这个时刻尝试拥抱人工智能，并找出什么对你和你的团队有效，是很好的时间利用。我想说的是，如果你的听众中有企业界的人，特别是，我知道在经历了这段旅程之后，有些团队可能会觉得，哦，天哪，感觉初创公司比我们行动快得多，或者他们能够使用所有这些很棒的新工具和模型，但我们仍在等待这些东西的企业友好版本。我曾与一些团队交谈过，他们有时会觉得我们一直在等待，等待，等待能够尝试更多这些工具。我最终在我的团队中所做的是，几年前，我们也同样在等待公司采纳官方做事方式。但这并没有阻止我们学习。所以我鼓励大家，我们很多人都在周末做副业项目。我们可以尝试任何第三方工具、第三方模型、我们自己的模型，我们可以尝试并学习，这不必成为你的一个大障碍。所以你仍然可以，你知道，帮助你的团队走上这条旅程，而不必做大量的等待。所以只是想让大家知道，有很多方法可以拥抱这个时刻。
是的。而且我认为共识是这些工具将非常普及。它们不断变化，并且已经为许多团队的代码库做出了贡献，人们正在使用它们。所以不如就使用它，因为最终这需要时间。所以你越早开始，无论如何你都会有很多东西要学习。
是的。完全正确。
所以作为结束，我只有几个收尾问题。我将直接提问，然后你告诉我你想到什么。你最喜欢的编程语言是什么，为什么？
我最喜欢的编程语言是 JavaScript。这就是……
我以为你会这么说，但我不太确定。
当然。
你写过关于这个的书。
我最喜欢的编程语言是 JavaScript。这并不是出于个人原因。嗯，可能还有更好的编程语言。我喜欢 JavaScript，因为它让地球上的任何人都能以一种不需要守门人的方式构建并发布东西到网络上。它非常开放。我认为这个想法非常解放。所以这是我最喜欢 JavaScript 的原因之一。我喜欢它。当软件工程师说 JavaScript 时，我总是很惊讶，因为我们知道与其他语言相比，它有很多限制，而且你知道，也有关于它的书。但我不能不同意。我喜欢它。这是真的。
你真正喜欢使用的工具是什么，它有什么用？
我想说，目前我最喜欢的工具之一，而且我有点偏心，我也有关于它的书，可能就是 Bolt。Bolt 是一种氛围编码脚手架工具，人们可以使用它。他们最近实际上增加了对使用自定义代理的支持。所以你可以使用，例如，Cloud Code 来构建你的氛围编码应用程序，而且输出通常质量很高，设计也很棒。所以我一直非常喜欢它，而且我认为团队一直在努力提供一些非常棒的集成。所以我一直很喜欢这个想法，即许多氛围编码平台现在开始考虑集成层。那么，我们如何自动化你需要使用，你知道，比如一个出色的数据库或一个身份验证提供商或这些其他东西的想法呢？当然，你仍然需要关注所有生成的代码，但我认为能够消除更多的设置摩擦是非常棒的。我想关于 Bolt.new 的一个有趣事实是，他们最初是一家名为 Stack Blitz 的公司，他们构建了一个非常酷的在线编辑器，非常先进，然后他们从那里转向了 Bolt。所以，背后仍然有真正了解自己手艺的软件工程师。
是的。是的。绝对是。
最后，你有什么推荐的书吗？
所以，我将推荐的书，我认为它以一种我发现非常引人入胜的方式涵盖了软件工程师的职业道路和最佳实践。它是你写的。它是《软件工程师指南》。当然，我这是在迎合大众，但它确实是一本非常非常深刻的书。从我读过的所有评论来看，其他人也觉得它是一本极好的读物。
嗯，它就在我的桌子上，但我们事先没有谈论过这个，所以这个推荐对我来说，就像对泰勒一样，是个惊喜。谢谢你。
确实是一本非常非常棒的书。我想，如果我当然不推荐那本的话，我认为如果你想在这个时刻更多地了解人工智能工程的基础方面，有一本很棒的书叫做《人工智能工程》，作者是 Chip Huin，也值得一看。它评价非常高，是一本非常非常全面的书，我也推荐大家去看看。
那真是一本好书。我觉得如果你了解那里的概念，你会做得很好。如果你不了解，你可能仍然在摸索。所以，对那本书大力推荐。艾迪，这次谈话很棒。非常感谢你做了这一切，以及这次非常棒的对话。
嗯，谢谢你。我非常感谢。我希望大家，你知道，如果你对这个领域感兴趣，《超越氛围编码》现在已经由 O'Reilly 出版了。希望它能对一些人有用。但很高兴能和你进行这次对话。
是的。而且我一直在读这本书。我真的很喜欢它深入探讨实用性。所以我也可以非常推荐它。
谢谢你。
希望你喜欢与 Addios [音乐] Manny 一起“超越氛围编码”（双关语）。我从这次对话中得到的一个体会是，作为一名工程师，我们持续准确地理解大型语言模型做什么以及为什么做，这真的非常重要。如果我们不理解它，我们就停下来，理解它，然后再继续。只要你理解大型语言模型，你就掌控着局面。
[音乐]
但一旦你停止理解，它就掌控了局面，你可能会变得无助，力不从心。有关如何快速掌握人工智能工程的更多技巧，请查看我在《务实工程师》中撰写的“深度探讨”，链接在下面的节目说明中。如果你喜欢这个播客，请务必在你喜欢的播客平台和 YouTube 上订阅。如果你也为节目留下评分，我们将特别感谢。谢谢 [音乐]，下期再见。