Code Smarter, Not Harder
18:30 Share

Greylock 合伙人 Corinne Riley 阅读了她的文章“更聪明的编码，而不是更努力的编码：解决开发 AI 工程师的未知问题”。构建用于代码生成和工程工作流程的 AI 工具是当今初创公司最激动人心和最有价值的项目之一。但关于必须解决的技术难题，才能使编码工具在生产环境中与（或优于）人工工程师一样有效，仍然存在许多悬而未决的问题。Riley 探讨了这些核心问题，并分析了目前开发 AI 编码工具的初创公司生态系统。您可以在此处阅读这篇文章：https://greylock.com/greymatter/code-smarter-not-harder/ 了解更多关于您的广告选择的信息。访问 megaphone.fm/adchoices</context> <raw_text>0 欢迎收听 Gray Matter，Greylock 的播客。我是 Corinne Riley，Greylock 的合伙人。今天的节目是我撰写的一篇文章的音频版本，标题为《更聪明的编码，而不是更努力的编码：解决开发 AI 工程师的未知问题》。您可以在 Greylock.com 上阅读这篇文章，它也链接在节目说明中。解锁用于代码生成和工程工作流程的高保真、可靠的 AI 是一项巨大的机遇。

工程任务非常适合 AI 增强或替代，原因如下：编码本质上需要工程师将问题分解成更小、更容易管理的任务。存在大量的现有训练数据。任务需要判断和基于规则的工作相结合。解决方案利用可组合的模块，例如开源库。在某些情况下，工作结果可以根据经验测试其正确性。

这意味着可靠准确的 AI 编码工具可以提供可量化的价值。鉴于这些因素，仅仅在过去一年中，对 AI 编码工具的尝试就激增了。但关于必须解决的技术难题，才能使编码工具在生产环境中与（或优于）人工工程师一样有效，仍然存在许多悬而未决的问题。

在这里，我将介绍我们在 Greylock 看到的初创公司生态系统中的三种方法以及这些工具面临的三个悬而未决的问题。首先，如何从这些代码库中提取相关的上下文？其次，如何使 AI 代理更好地用于端到端编码任务？最后，拥有特定于代码的模型是否会导致长期差异化？市场的现状。在过去一年中，我们看到初创公司采用了三种方法。

首先，AI 副驾驶可以增强工程工作流程，通过坐在工程师和他们工作的工具旁边来增强工程工作流程。其次，可以替代工程工作流程的 AI 代理，通过端到端执行工程任务来替代工程工作流程。第三，特定于代码的模型。这些是使用特定于代码的数据进行训练的定制模型，并与面向用户的应用程序垂直集成。

即使在解决总体问题之前，我们也相信上述每种方法都可以在短期内产生有意义的影响。让我们仔细看看每一种方法。一、增强现有工作流程。

如今，绝大多数 AI 代码初创公司都采用 IDE 副驾驶或聊天界面的形式来增强工程工作流程。虽然像 Tab9 这样的公司多年来一直在从事代码辅助工作，但编码 AI 工具的重大时刻是在 2021 年发布 GitHub Copilot 时出现的。从那时起，我们看到大量初创公司致力于工程师需要完成的各种工作。获得牵引力的初创公司正在追求以代码生成或代码测试为中心的工作流程。

这是因为它们是工程师工作的重要组成部分。它们可能只需要相对较低的上下文就能足够有用。在大多数情况下，它们可以捆绑在一个平台中。最后，在一个可靠性稀缺的世界里，将输出放在用户面前（即在 IDE 中）允许他们拥有任何必要的更正。

房间里的大象是应对 GitHub Copilot 的挑战，它已经在 Mindshare 中拥有相当大的分销份额。因此，初创公司正在通过寻找可以作为其切入点的差异化领域来解决这个问题。例如，Codium（C-O-D-E-I-U-M）正在采用企业优先的方法。

而名称相近的 CODIUM（C-O-D-I-U-M）则从代码测试和审查开始，然后从那里扩展。我们还认为，针对代码重构、代码审查和软件架构等任务的工具存在巨大的机遇。

这些任务可能更复杂，因为它们不仅需要对代码中更大的表面区域进行理解，还需要理解不同文件之间的知识图谱、外部库的知识、业务上下文、软件的最终使用模式以及复杂的工具选择。无论切入点如何，我们在这一层看到的一个反复出现的挑战是访问相关的上下文，以解决公司代码库中范围更广的任务。

具体如何做到这一点是一个悬而未决的问题，我稍后会详细介绍。二、AI 编码代理。如果增强工程工作流程是有价值的，那么更大的机遇在于弄清楚哪些工作流程可以完全替换。可以端到端执行工程任务并在后台工作的 AI 编码产品，可以在人类工程师做其他事情的同时创造一个全新的生产力和创新水平。

AI 编码代理是超越 AI 副驾驶的一大飞跃，它可以将我们从销售工具的领域带入销售劳力的领域。在一个编码代理非常优秀的时代，你可以让一个人同时监督多个 AI 工程师。AI 代理的基本能力不仅仅是预测代码行中的下一个单词。

它需要将此与执行包含数十个步骤的复杂任务的能力结合起来。并且像工程师一样，从用户的角度考虑产品。

例如，如果提示修复错误，它需要知道错误的位置、问题的性质、它如何影响产品、修复错误可能导致的任何下游更改等等，然后才能采取第一步操作。上下文必须来自诸如提取 JIRA 票证、更大的代码库块和其他信息来源等内容。

能够编写详细的代码规范和准确的代码规划将成为采用 AI 工程师的核心。我们在这个领域看到的公司和项目包括但不限于 Devon、Factory、CodeGen、SWE Agent、OpenDevon、AutoCodeRover、Trunk 等等。那么问题是，为了让代理能够端到端完成大部分任务，需要做些什么？

我将在我的开放性问题部分讨论这个问题。3.特定于代码的基础模型公司一些创始人认为，为了在代码应用程序层构建长期差异化，你需要拥有一个为其提供动力的特定于代码的模型。这并非不合理的建议，但似乎有一些悬而未决的问题阻止了其他初创公司采用这种资本密集型方法。

主要是不清楚特定于代码的模型是否会被基础模型层面的改进所超越。首先，让我们回想一下，大多数基础 LLM 并非专门针对代码进行训练，许多现有的特定于代码的模型（如 CodeLlama 和 AlphaCode）都是通过获取基于 LLM 的模型、提供数百万个公开可用的代码点并将其微调到编程需求而创建的。

如今，像 Magic、Poolside 和 Augment 这样的初创公司正在尝试通过训练他们自己的特定于代码的模型、生成他们自己的代码数据以及使用人类对编码示例的反馈来更进一步。Poolside 将此称为来自代码执行反馈的强化学习。

其论点是，这样做将导致更好的输出，减少对 GPT-4 或其他 LLM 的依赖，并最终创造尽可能持久护城河。这里核心问题是新团队能否超越前沿模型的改进。

基础模型领域发展如此之快，以至于如果你确实尝试深入研究特定于代码的模型，那么在你新的模型完成训练之前，就有可能出现更好的基础模型并超越你。鉴于模型训练的资本密集型程度，如果你在这个问题上出错，就会面临巨大的时间和金钱风险。

我知道一些团队正在追求一种非常有吸引力的方法，即在基础模型之上针对特定任务进行特定于代码的微调，这使他们能够从基础模型的进步中受益，同时提高代码任务的性能。我将在下一节中进行更多解释。开放性问题。

无论采用哪种方法，都需要解决一些技术挑战才能解锁具有低延迟和良好用户体验的可靠代码生成工具。首先，我们如何创建更强大的上下文感知能力？其次，我们如何使 AI 代理更好地用于端到端编码任务？第三，拥有模型和模型基础设施是否会导致长期差异化的产品？

开放性问题。无论采用哪种方法，都需要解决一些技术挑战才能解锁具有低延迟和良好用户体验的可靠代码生成工具。首先，我们如何创建更强大的上下文感知能力？其次，我们如何使 AI 代理更好地用于端到端编码任务？最后，拥有模型和模型基础设施是否会导致长期差异化的产品？

让我们检查一下如何创建更强大的上下文这个问题。上下文问题的关键在于，某些编码任务需要的信息和上下文存在于工程师正在处理的开放文件中之外，并且不能仅仅通过增加上下文窗口大小来访问。

从代码库的不同部分甚至外部检索这些信息不仅具有挑战性，而且还会增加延迟，这在即时自动完成的世界中是致命的。这为能够准确安全地查找和提取编码任务所需上下文的初创公司提供了巨大的机遇。

目前，有两种方法可以做到这一点：持续微调和上下文感知 RAG。我会谈谈两者。持续微调。我听说客户告诉我，我希望有一家公司能够在我的代码库上安全地微调他们的模型。

虽然从理论上讲，将模型调整到您自己的代码库可能是有意义的，但实际上有一个问题。一旦你调整了模型，它就变得静态了，除非你正在进行持续预训练，这既昂贵，也可能导致延续现有偏差。如果没有，它可能在有限的时间内表现良好，但它实际上并没有随着代码库的演变而学习。

也就是说，微调越来越容易，因此定期在您的代码库上微调模型可能是可行的。例如，带 E 的 Codium 表示他们确实提供客户特定的微调，但他们明确表示应该谨慎使用，因为最佳方法是上下文感知 RAG。上下文感知 RAG。

RAG 可能是当今改进上下文以检索代码库相关片段的最佳可用方法。这里的挑战在于，在非常大的代码库中检索中的排序问题并非微不足道。诸如代理 RAG 和 RAG 微调之类的概念越来越受欢迎，并且可能是更好地利用上下文的有力方法。

例如，带 E 的 Codium 在一篇博文中分享了他们如何使用教科书式的 RAG 并增强更复杂的检索逻辑，爬取导入和目录结构并将用户意图（例如您过去打开的文件）作为上下文。能够在检索中使用此粒度细节可以成为初创公司的重要护城河。开放性问题二，我们如何使 AI 代理更好地用于端到端编码任务？

虽然我们距离功能齐全的 AI 工程师还有很长的路要走，但 Cognition、Factory、CodeGence、WeAgent、OpenDevon、AutoCodeRover 和 Trunk 等少数公司和项目正在取得有意义的进展。

SWE 基准评估显示，大多数基础模型只能修复高达 4% 的问题。SWE 代理可以达到 12%，Cognition 据报道为 14%，OpenDevon 高达 21%。Andrei Karpathy 重复的一个有趣的想法是关于流程工程的概念，它超越了单一提示或思维链提示，并专注于代码的迭代生成和测试。

诚然，提示可能是提高性能而不必训练模型的好方法，尽管我不清楚从长远来看这对于公司来说能有多少护城河。请注意，套件代理形式的测量有一些局限性。

作为背景，SweeBench 包含 GitHub 中问题和拉取请求的配对。因此，当模型在其上进行测试时，会提供代码库的一个小子集，这是一种暗示，也会引入偏差，而不是提供整个库并告诉它弄清楚。尽管如此，我相信 SweeBench 是一个很好的基准，可以开始理解此时此刻的这些代理。

代码规划将在 AI 代理中发挥核心作用，我很高兴看到更多公司专注于生成代码规范，这些规范可以帮助代理构建目标、规划功能并定义其实现和架构。多步骤代理推理仍然普遍未解决，据传是 OpenAI 下一代模型的重点关注领域。事实上，

有人认为，AI 编码代理的实际护城河根本不是来自包装器，而是来自 LLM 本身及其解决现实世界软件工程问题的能力，包括使用人类级别的工具访问，例如搜索 Stack Overflow、阅读文档、自我反思、自我纠正和执行长期一致的计划。

这让我们来到了最后一个也是可能最大的开放性问题。拥有模型和模型基础设施是否会导致长期差异化的产品？十亿美元的问题是，初创公司是否应该依赖现有模型（无论是直接调用 GPT/CLOD 模型还是微调基础模型），还是经历构建他们自己的特定于代码的模型的资本密集型过程。

这意味着使用高质量的编码数据专门为代码预训练模型。我们凭经验不知道特定于代码的模型是否会比下一套大型语言模型产生更好的结果。这个问题归结为一些基本的不确定性。较小的代码模型能否胜过更大的基础模型？模型需要在多大程度上预训练代码数据才能看到有意义的改进？

是否有足够的可用高质量代码数据可供训练？大型语言模型的规模化推理是否胜过一切？Poolside、Magic 和 Augment 的假设是，拥有底层模型并对其进行代码训练可以显著决定代码生成的质量。考虑到竞争，这种潜在优势是有道理的。

据我了解，GitHub Copilot 没有完全从头开始训练的模型，而是运行一个较小、经过大量代码微调的 GPT 模型。我的猜测是这些公司不会试图构建一个基础规模的模型，而是一个更小、更专业的模型。根据我与在这个新兴领域工作的人们的谈话，我的结论是，在我们发布结果之前，我们仍然不知道这种方法会有多大程度的改进。

针对代码模型方法的反驳来自这样一个事实：现有的成功的编码副驾驶（如 Cursor 和 Devin）已知是建立在 GPT 模型之上，而不是特定于代码的模型。据报道，DBRX Instruct 的性能优于特定于代码的训练 CodeLlama。

如果使用编码数据进行训练有助于推理，那么前沿模型肯定会在未来的模型中包含代码执行反馈，从而使它们更适合 CodeGen。同时，主要针对语言进行训练的大型模型可能拥有足够的上下文信息，其推理能力可以超越对代码数据的需求。毕竟，人类就是这样工作的。

这里的关键问题是基础模型的改进速度是否大于特定于代码的模型的性能提升。

我认为大多数副驾驶公司可能会开始采用前沿模型并在他们自己的数据上进行微调。例如，采用 LAMA 3 80 亿参数并在其之上进行来自代码执行反馈的强化学习。这允许公司从基础模型的发展中受益，同时使模型偏向于代码性能。

总而言之，构建用于代码生成和工程工作流程的 AI 工具是我们今天看到的令人兴奋和最有价值的项目之一。增强并最终完全自动化工程工作的能力解锁了一个比我们历史上在开发人员工具中看到的市场规模大得多的市场。虽然需要克服一些技术障碍，但这个市场的潜力是无限的。

在 Greylock，我们正在积极寻求与尝试本文中讨论的所有三种方法的创始人合作。我们认为这个领域足够大，可以允许许多公司开发针对代理、副驾驶和模型的专业方法。如果您是一位正在从事这些概念或只是在考虑这些概念的创始人，请通过 [email protected] 与我联系。