AI Coding是一个我很感兴趣的方向。

还是得说到Cursor，这是一个给我带来惊喜的产品，作为曾经学计算机的二把刀选手，已经很久没碰代码了，用Cursor生成代码，还是能让我构建一个demo，一下就能运行起来，这种简单和顺畅的体感非常真切。我也发现身边的开发者，用Cursor的越来越多。

我和做AI Coding的从业者讨论过，如果用自动化程度来看AI Coding的进展的话，一个美好又科幻的展望是这样的：

L1：给程序员用的工具，Copilot。（当下大家在使用的产品，GitGub Copilot、Cursor）

L2：从idea到demo，通过自然语言，建立产品demo，做到业务能力和代码能力分离。这一阶段只能交付demo，不能交付实用产品。

L3：AI程序员，Auto Pilot，能端到端的完成编程任务，不需要程序员介入。（融了很多钱的Poolside、Magic做这个，产品还是期货状态，效果如何是个开放问题。）

L4：从一个idea到一个实用产品，多个AI角色协作完成任务，包括AI产品经理+AI程序员+AI测试员+AI运维等。（这个还比较科幻，当下模型能力相差甚远，听听就好。）

L5：AI接管App工厂中的多个职能，除了编程，还包括AI投放、AI收集用户反馈、自动迭代、AI尝试商业化。（更科幻了，先当故事听听。）

从L1到L5，能走到哪一步不好说，这取决于模型能力的提升。

一种思考方式：手写代码是螺丝刀，AI coding是电动螺丝刀，AI Coding这个工具有多大的市场规模？这是比较现实的角度。

一种思考方式：随着摄影机的提升和普及，乃至手机拍摄，视频内容出现了什么新形式？出现了什么新平台？同样，随着AI Coding的提升，应用产品会有哪些变化？有什么增量机会？这是叙事的角度。

所以，AI Coding能撑起一个多大的叙事？

美国老牌VC Greylock写过一篇文章《Code Smarter， Not Harder》，系统梳理了三类AI Coding创业公司，现状如何，遇到的难题是什么。可能是目前对AI Coding分析最系统的一篇文章了，我翻译分享给大家。

Code Smarter， Not Harder

AI Coding是一个巨大的机遇：解锁高保证、可靠的AI，进行代码生成和重塑工作流程。

编程这项工作非常适合 AI 增强或替代，原因如下：

1. 编码本质上要求工程师将问题分解成更小、更易管理的任务；

2. 有大量现有的训练数据；

3. 任务需要判断力和基于规则的工作相结合；

4. 解决方案利用可组合的模块（比如开源软件库等）；

5. 在某些情况下，工作成果可以通过经验测试其正确性。这意味着可靠的 AI 编码工具可以提供可量化的价值。

过去一年里，AI Coding工具爆发式增长。最终，是希望这些编码工具做到和人类工程师一样好，甚至超越，但仍有很多悬而未决的问题。

我们看到了做AI Coding的三种方法，这三种方法对应三个挑战：

1. 如何创造更强的上下文感知能力？

2. 如何让AI Agent在端到端编码任务中做得更好？

3. 有人押注于编码模型，这能否带来长期的差异化？

市场现状

在过去的一年里，我们看到初创公司采取了三种方法：

1. AI Copilots和Chat界面，做副驾驶，辅助工程师，提升他的编程能力。

2. AI Agent，做主驾，替代掉工程师，能端到端的完成任务。

3. 构建编程模型，用特定的代码数据训练一个专有模型，并与应用垂直整合。

这三条道路上各有一批公司，我们来看看行业地图。

1. 增强现有工作流程

如今，大多数AI Coding创业公司的切入点是Copilot，在IDE中嵌入Chat界面，来增强工作流程。

虽然像Tabnine这样的公司研发代码助手多年，但AI Coding的重要时刻是2021年GitHub Copilot发布：工程师开始使用GitHub Copilot写代码，市场上出现大量AI Coding项目。

这类产品能有很好的验证，是因为：

• 产出代码是工程师的核心工作；

• 这类产品只要相对较少的上下文即可奏效；

• 多数情况下，它们可以在单一平台内捆绑；

• 因为，将输出直接放在用户面前（即在IDE中）允许他们负责所需的任何更正。

显而易见，这类产品最大的挑战是GitHub Copilot，GitHub Copilot已经占据了相当的市场份额。初创公司试图通过差异化来解决这个问题，找到立足点。比如，Codeium优先做企业客户，而Codium从代码测试和审查开始，从这一切入点拓展。

我们也相信，针对代码重构、代码审查和软件架构等任务的工具有很大机会。这些可能更复杂，因为它们不仅需要对代码有更广泛的理解，还需要理解不同文件之间的知识图谱、外部库、业务背景、软件的使用模式、以及复杂工具的选择。

无论切入点如何，这类产品统一的挑战是——如何更好地获取上下文，来完成代码库中更广更深的任务。

这是一个开放性问题，我们放在最后讨论。

2. AI Coding Agent

如果增强工作流程有价值，那么更大的机会是取代某些工作流程。

能端到端执行任务的AI Coding产品——工程师在做事情时，Agent同时在后台工作——将创造全新的生产力和创新模式。AI Copilot是卖生产工具，AI Agent更进一步，在卖AI工程师。在一个AI coding Agent很好用的世界里，一个人类可以同时监督多个“AI工程师”。

AI Agent的基本能力不仅仅是预测代码行中的下一个词。它需要将这种能力与执行复杂任务的能力结合起来，这种任务可能多达数十个步骤，并且像工程师一样从用户的角度考虑产品。

比如修复一个bug，它需要知道bug的位置、问题性质、它对产品的影响、修复bug可能会导致的任何上下游变化，等诸多问题，然后才能采取第一个行动。上下文必须来自像摄取Jira票据、更大块的代码库块、和其他信息源。能够编写详细的代码规范和准确的代码规划将成为AI工程师的核心。

我们在这一领域看到的产品包括：Devin、Factory、CodeGen、SWE-Agent、OpenDevin、AutoCodeRover、Trunk等。

那么，问题来了：为了让Agent能端到端的完成更多任务，我们需要做什么？这个问题我们留在后面回答。

3. 代码模型公司

一些创始人认为，为了在AI Coding应用层建立长期的差异化，需要拥有一个专门的代码模型。

听着似乎有道理，这是一条资本密集的道路，似乎有些问题阻碍创业公司走这条路：专门的代码模型更好？还是基础模型层持续进步，并超越代码模型？这个问题还不清楚。我将在开放问题部分进一步讨论这个话题。

首先，让我们回顾一下，大多数基础LLM并不是专门在代码上训练的，许多用于代码的模型，如CodeLlama和AlphaCode，是基于LLM基础模型做的，给它数百万个公开可用的代码点，然后针对编程需求微调来创建的。

注：时间线仅显示了部分代码模型和用于编码的LLM

如今，像Magic、Poolside和Augment这样的创业公司试图更进一步，正在训练自己的代码模型，通过生成自己的代码数据和人类对编程示例的反馈来训练模型（Poolside称之为“基于代码执行反馈的强化学习”）。他们的观点是，这样能带来更好的输出，减少对GPT-4或其他LLM的依赖，并最终创建最持久的护城河。

核心技术问题是，一个新团队能否超越前沿模型的改进速度。基础模型发展如此之快，如果你试图深入研究代码专用模型，你会面临一个风险——在你的新模型训练完之前，一个更好的基础模型出现，并超越你的模型。模型训练是个资本密集的活儿，如果你在这个问题上判断失误，将会浪费大量的时间和金钱。

我知道一些团队正在采取（非常吸引人的）方法，即在基础模型上对特定任务进行特定微调，这样既可以受益于基础模型的进步，又能提高编程能力。我将在开放问题部分讨论这个问题。

开放问题

无论采取哪种方法，都需要解决一些技术挑战，来解锁更可靠的AI coding工具，更低延迟，更好的用户体验：

• 如何创造更强大的上下文感知能力？（context awareness）

• 如何让AI Agent在端到端任务中变现更好？

• 拥有代码模型这一基础设施，是否能带来具有长期差异化的产品？

开放问题1：如何创造更强大的上下文感知能力？

上下文问题的关键在于，某些编码任务需要正在工作的文件之外的信息和上下文，这些信息不能简单通过增加上下文窗口来访问。

从代码库的不同部分（甚至外部）检索这些信息是有挑战的，还可能增加延迟，这在即时完成的世界中是致命的。

这个问题也带来了创业机会，谁能准确和安全的找到所需的上下文？

目前，有两种方法可以做到：

• 持续微调：我听到客户说过“我希望一家公司能在我的代码库上安全地微调他们的模型”。虽然理论上对自己的代码库进行模型微调有用，但实际上有一个问题：一旦你调整了模型，它就变得静态的，除非你进行持续的预训练（这很昂贵，并且可能还是有幻觉）。如果做不到持续预训练，它可能在一段时间内变现很好，但没有随着代码库的演变而学习。

确实，微调变得越来越容易，所以定期对你的代码库进行模型微调是可行的。例如，Codeium提供“客户特定的微调”，但他们明确表示谨慎使用，因为最好的方法是上下文感知RAG。

• 上下文感知RAG：RAG也许是目前提高上下文的最佳方法，通过检索代码库中的相关片段。这里的挑战是，在很大的代码库中，检索排名问题非常复杂。

像Agentic RAG和RAG微调这样的概念正在普及，这是更好地利用上下文的有效方法。例如，Codeium在博客文章中分享了他们如何使用教科书式的RAG，并辅以更复杂的检索逻辑，爬取导入和目录结构，并把用户意图（比如你过去打开的文件）作为上下文。初创公司如果能把这些细节做好，将成为护城河。

开放问题2：如何让AI Agent在端到端的任务中变现更好？

尽管我们离完美的AI工程师还有一段路要走，但像Cognition、Factory、Codegen、SWE-Agent、OpenDevin和AutoCodeRover这样的公司正在取得进展。

SWEBench评估显示，大多数基础模型只能修复4%的问题，SWE-Agent达到12%，Cognition达到14%，OpenDevin高达21%。

一个有趣的想法（由Andrej Karpathy提出）是 flow-engineering，它超越了single-prompt或Chain-of-Thought Prompt，专注于代码的迭代生成和测试。确实，Prompt Engineering无需训练模型，就可以提高性能，但对一家公司来说，这在长期能有多大的护城河尚不清楚。

注意，这种测量方法有一定的局限性：就上下文而言，SWE-bench由Github的问题和拉取请求配对组成，因此当模型在它上面进行测试时，它只会得到代码库的一小部分（这是一种提示，同时也引入了偏差），而不是给予整个代码库并让它们自行解决。尽管如此，我认为SWE-Bench是一个很好的衡量标准，可以开始理解这些Agent。

代码规划将在AI Agent中扮演核心角色，我很期待看到更多公司专注于生成代码规范，这些规范可以帮助Agent建立目标、规划功能、定义实现方式、和定义架构。多步骤Agent推理仍是一个悬而未决的问题，据传闻这是OpenAI下一个代模型的重点课题。

事实上，一些人（如Jim Fan）会认为，AI Coding Agent的护城河并不来自“套壳”，而是LLM本身及“解决现实世界软件工程问题的能力，具有人类级别的工具访问能力，比如搜索StackOverflow、阅读文档、自我反思、自我纠正，并执行长期一致的计划”。

这就引出了最后一个开放问题，也是最大的问题。

开放问题3：构建代码模型能否带来长期差异化的产品？

这是一个价值十亿美元的问题，初创公司是应该依赖现有LLM模型（无论是直接调用LLM的API，还是微调模型）？还是构建自己的代码模型？——即使用高质量的代码数据，从头做预训练，经历资本密集型的过程。

实际上，我们不知道代码模型是否会比下一代LLM有更好的结果。

这个问题可以归结为以下未知要素：

• 一个较小的代码模型能否胜过一个大得多的基础模型？

• 基于代码预训练模型，需要炼到什么程度才能看到显著改进？

• 是否有足够的高质量代码数据可供训练？

• 基础模型的大规模推理能力是否压倒一切？

Poolside、Magic和Augment的假设是，拥有底层模型，并在代码上训练它，可以显著提升代码生成质量。这种潜在优势在竞争中是有意义的：据我所知，GitHub Copilot并没有从头训练模型，而是运行在一个较小、经过大量代码微调的GPT模型上。

我猜这些公司不会构建一个基础级尺寸的模型，而是构建更小、更专业的模型。根据我与AI Coding领域的人的交流，我的结论是，在结果发布之前，我们仍不知道这种方法能带来多大的改进。（Poolside、Magic等都未发布产品，虽然融了很多钱。）

也有人反驳代码模型：现有成功的AI Coding Copilot，如Cursor和Devin，都是建立在GPT模型上，而不是基于代码模型。

据报道，DBRX Instruct的表现优于专门训练的CodeLLaMA-70B。如果用代码数据训练有助于推理，那么前沿模型肯定会在未来的模型中包括代码执行反馈，从而使它们更适合代码生成。与此同时，主要在语言上训练的大型模型可能具有足够的上下文信息，使其推理能力胜过对代码数据的需求——毕竟，这就是人类的工作方式。

关键问题是，是基础模型的改进速度更快？还是代码模型的性能提升更快？我认为，大多数Copilot公司会使用前沿的基础模型，并在自己的数据上微调——例如，使用Llama3-8b，通过代码执行反馈进行强化学习——这允许公司从基础模型的发展中受益，同时使模型偏向于代码性能。

结论

构建用于代码生成和工程工作流的AI工具，是当下最令人兴奋和值得投入的事业之一。持续提升编码能力，甚至最终完全自动化编码，将开启一个巨大的市场，远大于历史上出现过的开发者工具。虽然需要克服众多技术障碍，但这个市场的上升空间是无限的。

我们正继续寻找这三个领域的创始人合作，这个领域足够大，可以容纳很多公司开发Copilot、Agent和模型。

原文链接：

https://greylock.com.greymatter.code-smarter-not-harder

文章来自于“AI大航海”，作者“吴炳见”。