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

ttxx

编辑：吴炳见

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能撑起一个多大的叙事？

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

<Code Smarter, Not Harder>

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

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

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

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

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

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

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已经占据了相当的市场份额（祝贺Devin，他刚刚与MicroSoft达成合作关系）。初创企业试图通过差异化来解决这个问题，找到立足点。比如，Codeium优先做企业客户，而Codium从代码测试和审查开始，从这一切入点拓展。

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

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

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

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本身及“解决现实世界App工程问题的能力，具有人类级别的工具访问能力，比如搜索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工具，是当下最令人兴奋和值得投入的事业之一。持续提升编码能力，甚至最终完全自动化编码，将开启一个巨大的市场，远大于历史上出现过的开发者工具。虽然需要克服众多技术障碍，但这个市场的上升空间是无限的。

PS：这是ChatGPT翻译的，我做了一些更符合中文习惯的修改。

还是建议大家去读原文，这是链接。

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


来源：36kr