AI Coding 新进展:从工具到自然语言生成 demo 的美好展望

admin

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

我们来谈谈游标。这是一个让我惊喜的产品。作为一个二手电脑玩家,我已经很久没有接触过代码了。使用Cursor生成代码仍然可以让我一次性构建一个demo。跑步的时候,这种简单流畅的感觉非常真实。我还发现我身边越来越多的开发者都在使用Cursor。

我和AI Coding从业者讨论过,如果从自动化程度来看待AI Coding的进展,一个美好而科幻的前景是这样的:

L1:程序员的工具,Copilot。 (现在大家都在用的产品,GitGub Copilot、Cursor)

L2:从idea到demo,通过自然语言构建产品demo,将业务能力和编码能力分离。现阶段只能交付demo,无法交付实用产品。

L3:AI程序员,Auto Pilot,无需程序员干预即可端到端完成编程任务。 (筹集了大量资金的Poolside和Magic正在这样做。产品仍处于期货状态。它们的效果如何是一个悬而未决的问题。)

L4:从一个想法到一个实际产品,多个AI角色协同完成任务,包括AI产品经理+AI程序员+AI测试员+AI运维等(这个还是比较科幻,目前模型的能力差别很大,所以请听一下。)

L5:人工智能接管应用工厂中的多项功能。除了编程之外,还包括AI交付、AI收集用户反馈、自动迭代、AI商业化尝试。 (这更像是科幻小说,所以先把它当作一个故事来听。)

从L1到L5,很难说能走多远,要看模型能力的提升。

一种思考方式:手写代码就像一把螺丝刀,而人工智能编码就像一把电动螺丝刀。人工智能编码作为工具的市场规模有多大?这是一个更现实的视角。

换一种思考方式:随着相机的改进和普及,甚至用手机拍摄,出现了哪些新形式的视频内容?出现了哪些新平台?同样,随着AI Coding的完善,应用产品会发生哪些变化?有哪些增量机会?这就是叙事视角。

那么,AI Coding 能支持多大的叙事呢?

美国资深VCGreylock写了一篇文章《Code Smarter, Not Harder》,系统梳理了三类AI Coding初创公司的现状以及遇到的问题。这可能是目前关于AI Coding分析最系统的文章了。我将其翻译并与您分享。

代码更智能,而不是更难

人工智能编码是一个巨大的机会:解锁高保证、可靠的人工智能来生成代码并重塑工作流程。

编程是一项非常适合被人工智能增强或取代的工作,原因如下:

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

2、已有大量的训练数据;

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

4. 解决方案利用可组合模块(例如开源软件库等);

5. 在某些情况下,可以根据经验测试工作产品的正确性。这意味着可靠的人工智能编码工具可以提供可量化的价值。

在过去的一年里,人工智能编码工具呈爆炸式增长。最终,希望这些编码工具能够与人类工程师一样好甚至更好,但仍然有许多未解答的问题。

我们看到了三种进行 AI Coding 的方法,它们对应着三个挑战:

1. 如何增强情境意识?

2、如何让AI Agent在端到端的编码任务中做得更好?

3.有人在编码模型上下注。这能带来长期的差异化吗?

市场现状

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

1.使用AI副驾驶和聊天界面担任副驾驶和助理工程师,提高他的编程能力。

2、AI Agent起主导作用,取代工程师,可以端到端完成任务。

3. 构建编程模型,使用特定代码数据训练专有模型,并与应用程序垂直集成。

这三条路上各有多家公司。我们来看看行业地图。

AI Coding能撑起一个多大的叙事?_AI Coding能撑起一个多大的叙事?_

1. 增强现有工作流程

如今,大多数 AI Coding 初创公司的切入点是 Copilot,它将 Chat 界面嵌入到 IDE 中以增强工作流程。

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

这类产品能够得到很好的验证是因为:

显然,此类产品面临的最大挑战是已经占据相当市场份额的 GitHub Copilot。初创公司试图通过差异化来解决这个问题并找到立足点。例如,Codeium优先考虑企业客户,而Codium则从代码测试和审查开始,并以此为起点进行扩展。

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

无论切入点如何,此类产品的统一挑战是如何更好地获取上下文以完成代码库中更广泛、更深入的任务。

这是一个悬而未决的问题,我们将在最后讨论。

2.AI编码代理

如果增强工作流程有价值,那么更好的机会就是替换其中的一些工作流程。

人工智能编码产品可以端到端地执行任务——工程师在做事情的同时,代理也在后台工作——将创造新的生产力和创新模式。 AI Copilot 销售生产工具,而 AI Agent 则更进一步,销售 AI 工程师。在人工智能编码代理易于使用的世界中,一个人可以同时监督多个“人工智能工程师”。

人工智能代理的基本能力不仅仅是预测一行代码中的下一个单词。它需要将这种能力与执行复杂任务(可能涉及数十个步骤)的能力结合起来,并像工程师一样从用户的角度思考产品。

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

我们在这方面看到的产品包括:Devin、Factory、CodeGen、SWE-Agent、OpenDevin、AutoCodeRover、Trunk等。

那么,问题来了:我们需要做什么才能让Agent端到端地完成更多的任务呢?我们稍后会回答这个问题。

3. 代码模型公司

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

听起来很有道理,这是一条资本密集型的​​道路,而且似乎存在一些问题阻碍初创公司走这条路:专门的编码模型更好吗?或者底层模型层会继续超越代码模型吗?问题尚不清楚。我将在开放问题部分进一步讨论这个话题。

首先,让我们回顾一下,大多数基础法学硕士都没有接受过专门的代码培训。许多代码模型,例如 CodeLlama 和 AlphaCode,都是基于 LLM 基本模型,为其提供了数百万个公开可用的代码。单击 ,然后根据编程需要进行微调来创建。

AI Coding能撑起一个多大的叙事?_AI Coding能撑起一个多大的叙事?_

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

如今,Magic、Poolside 和 Augment 等初创公司正试图更进一步,通过生成自己的代码数据和对编程示例的人工反馈来训练自己的代码模型(Poolside 称之为“基于代码执行反馈”)。强化学习”)。他们的论点是,这会带来更好的产出,减少对 GPT-4 或其他 LLM 的依赖,并最终创造最持久的护城河。

核心技术问题是新团队是否能够超越领先模型的改进速度。基础模型发展得如此之快,如果您尝试深入研究特定于代码的模型,那么在新模型训练之前,您将面临更好的基础模型出现并超越您的模型的风险。模型训练是一项资本密集型的​​工作,如果在这个问题上犯了错误,就会浪费大量的时间和金钱。

我知道一些团队正在采取(非常有吸引力的)方法,在基础模型上进行特定于特定任务的微调,从而从基础模型的进步中受益,同时提高编程能力。我将在开放问题部分讨论这个问题。

开放式问题

无论采用哪种方法,都需要解决一些技术挑战,以解锁更可靠的人工智能编码工具、更低的延迟和更好的用户体验:

_AI Coding能撑起一个多大的叙事?_AI Coding能撑起一个多大的叙事?

开放问题1:如何创建更强大的情境感知?

上下文问题的关键在于,某些编码任务需要您正在处理的文件之外的信息和上下文,而仅通过增加上下文窗口无法访问此信息。

从代码库的不同部分(甚至外部)检索此信息具有挑战性,并且还会增加延迟,这在即时完成的世界中是致命的。

这个问题也带来了创业机会,谁能准确、安全地找到所需的上下文呢?

目前,有两种方法可以做到这一点:

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

Agentic RAG 和 RAG 微调等概念越来越受欢迎,它们是更好地利用上下文的有效方法。例如,Codeium 在一篇博客文章中分享了他们如何使用教科书 RAG 辅以更复杂的检索逻辑、爬行导入和目录结构,以及将用户意图(例如您过去打开过的文件)作为上下文。如果初创公司能够正确处理这些细节,它们将成为一条护城河。

开放问题2:如何让AI Agent在端到端任务中更好地变现?

尽管我们距离完美的人工智能工程师还有一段距离,但 Cognition、Factory、Codegen、SWE-Agent、OpenDevin 和 AutoCodeRover 等公司正在取得进展。

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

一个有趣的想法(由 Andrej Karpathy 提出)是流程工程,它超越了单一提示或思想链提示,专注于代码的迭代生成和测试。确实,Prompt Engineering 可以在无需训练模型的情况下提高性能,但从长远来看,尚不清楚这对公司来说有多大的护城河。

请注意,这种测量方法有一定的局限性:对于上下文来说,SWE-bench 由成对的 Github 问题和拉取请求组成,因此当在其上测试模型时,它只能获得代码库部分的一小部分样本(这是一个提示)并且还引入了偏见),而不是提供整个代码库并让它们自行解决。尽管如此,我认为 SWE-Bench 是开始了解这些代理的一个很好的基准。

代码规划将在人工智能代理中发挥核心作用,我期待看到更多公司专注于生成代码规范。这些规范可以帮助Agent建立目标、规划功能、定义实现方法、定义架构。多步Agent推理仍然是一个未解决的问题,有传言这是下一代OpenAI模型的关键主题。

事实上,有些人(比如 Jim Fan)会认为 AI Coding Agent 的护城河并非来自“外壳”,而是来自 LLM 本身以及“解决现实世界软件工程问题的能力,具有人类水平”。使用搜索 StackOverflow 等工具、阅读文档、自我反思、自我纠正并执行长期、一致的计划。”

这就引出了最后一个悬而未决的问题,也是最大的一个问题。

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

这是一个十亿美元的问题,初创公司是否应该依赖现有的LLM模型(要么直接调用LLM的API,要么对模型进行微调)?或者构建自己的代码模型? ——即使用高质量的代码数据,从头开始预训练,经历一个资本密集的过程。

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

问题归结为以下未知因素:

Poolside、Magic 和 Augment 的假设是,拥有底层模型并在代码上对其进行训练可以显着提高代码生成的质量。这种潜在优势相对于竞争对手来说是有意义的:据我所知,GitHub Copilot 并不是从头开始训练模型,而是在经过微调的更小、代码较多的 GPT 模型上运行。

我的猜测是,这些公司不会构建一个基础级别的模型,而是一个更小、更专业的模型。根据我与人工智能编码领域人士的互动,我的结论是,在结果发布之前,我们仍然不知道这种方法能带来多大的改进。 (Poolside、Magic等虽然筹集了很多资金,但尚未发布产品。)

也有人反驳代码模型:现有成功的 AI Coding Copilot,比如 Cursor、Devin,都是建立在 GPT 模型之上的,而不是代码模型。

据报道,DBRX Instruct 的性能优于经过特殊训练的 CodeLLaMA-70B。如果使用代码数据进行训练有助于推理,那么尖端模型肯定会在未来的模型中包含代码执行反馈,使它们更适合代码生成。与此同时,主要接受语言训练的大型模型可能拥有足够的上下文信息,其推理能力超过了对代码数据的需求——毕竟,这就是人类的工作方式。

关键问题是,基础模型改进得更快吗?或者代码模型是否可以更快地提高性能?我认为大多数 Copilot 公司都会使用最先进的基础模型,并根据自己的数据对其进行微调 - 例如,使用 Llama3-8b,带有代码执行反馈的强化学习 - 这使公司能够从基础模型的开发中受益,也使模型偏向于代码性能。

综上所述

构建用于代码生成和工程工作流程的人工智能工具是当今最令人兴奋和最有价值的努力之一。不断提高编码能力,甚至最终完全自动化编码,将开辟一个巨大的市场,远远大于历史上任何开发者工具所见过的。尽管还有许多技术障碍需要克服,但这个市场的上涨空间是无限的。

我们正在继续寻找创始人在这三个领域进行合作。这个区域足够大,可以容纳许多开发副驾驶、代理和模型的公司。

原文链接:

作者简介:吴秉健,魂资本合伙人,原某大型厂商移动产品经理+战略分析师,曾就职于先锋、联想之星。参与投资多个大型模型及人工智能应用项目。关键词 LLM、AI Native、AI 基础设施、机器人。