返回资讯中心
外部精选
软件工程
#开发者实时流

Framer如何用AI改变软件工程流程

来源标题:How software engineering is changing at Framer

Framer早期采用Cursor和GPT-4,并逐步推行自动化PR审查与智能体结对编程。一位2024年2月入职的工程师撰文详述了团队从人工审查到自动批准PR的转变,全文5500字由人类撰写。

Hacker News 最新speckx2026/11/4 · 今天14 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

Framer 的 AI 实践

Agent PR 评审 Agent 自动批准 PR

以自动批准为前提来处理 PR

Slack Agent 以聊天作为低门槛入口

Agent 居中

保持健康的怀疑

理解 Agent 的优势 AI 作为杠杆

走向高效之路 PR 模板

Agent 结对工程

如何(不)评审 Agent 代码

结语

索引

本文作为 The Pragmatic Engineer 的“软件工程正在如何改变:征文挑战”的一部分发表。5500 词,全部由人类撰写。

我将带你回顾我们走向自动化 PR 评审的历程,以及我所称的 agent 结对工程,还有 AI 如何帮助我推动了晋升。希望你喜欢!

2024 年 2 月我加入 Framer 时,我在 Slack 上最先问的问题之一,就是这里的人推荐哪个“AI 扩展”。Framer 的 CEO Koen Bok 当时回复说,他推荐在聊天里用 Cursor + GPT 4。考虑到 Cursor 的增长曲线(2024 年 8 月其 A 轮估值为 4 亿美元),在 2024 年 2 月推荐 Cursor 算是很早的。基于这一点,我会把 Framer 定义为 agent 浪潮的早期采用者和早期骑手——也许不算最前沿,但很接近。Framer 的管理层鼓励尝试新技术,我的许多同事也喜欢玩最前沿的技术。对我来说,这就像玩新玩具。只是以成年人的身份。

2025 年,Framer 的管理层决定停止招聘,专注于用 AI 真正提升生产力(把 PR 数量翻倍,同时绝不以任何方式降低质量)。

我们看到的结果是 PR 变得更复杂,但代价是周转时间更长,于是三个月后我们重新放开了招聘。我们从中得到的重要经验是:

PR 评审被如何对待,似乎也是“浪潮最顶端”(Anthropic、OpenAI、SpaceXSI 这类公司)与“接近顶端”的公司(我把 Framer 归为这一类)之间一个有趣的差异。在浪潮最顶端的公司,他们似乎用 agent 编写接近百分之百的代码。从与那些实验室的工程师交谈来看,他们似乎也大量使用 agent 来评审代码,这感觉是这两类公司之间最大的差距。

接下来,我会逐一介绍我们使用的 AI 相关工具,谈谈个人亮点以及我们如何推广各种形式的 agent。最后,我会讲述我们在内部围绕 agent 编写的代码所经历的挣扎和讨论——这正是“接近顶端”的公司与前沿公司差别最大的地方,无论好坏。

Framer 的管理层从未强制要求使用 AI,有过一些引导,但所幸我们从未有过影响晋升或绩效评级的 token 排行榜。我们采用的策略是向工程师展示能让个人更高效的 workflow。一开始,我们每周开一次会,每个人都可以展示自己用 AI 做的酷东西、演示技能,或者只是发起讨论。我认为这有助于提升大家对 agent 能做什么、不能做什么的认知。

Framer 的工程师可以自由选择自己用的 agent:Claude Code、Codex、Cursor、Devin(Desktop)是最常见的几个。有些人也会在 Zed 或 WebStorm 里使用它们。对后端同学来说,这些工具的 CLI 版本似乎比桌面版更普及。我接触的大部分代码用 TypeScript 编写,框架是 React。

总的来说,感觉我们仍处在没有单一 workflow 适合所有人的阶段。这未必是坏事。毕竟过去开发者也是各自选择自己喜欢的 IDE,所以也许标准化工程师的工作方式并不是你该追求的目标?

对我们来说,完全依赖 agent 来编写和评审代码并不是默认做法,我们正处于一个阶段:还不太清楚该如何对待“100% 由 agent 生成的代码”的 PR,如何理解 agent 生成的产物(markdown/HTML/对话记录),以及如何提高评审效率。与此同时,进入主分支的 agent 生成代码量每天都在增长。

更为成熟的,是各种“支持”日常工程工作的 agent(甚至在工程之外也能发挥作用):

2025 年 1 月,Framer 的 CTO Eelco Lempsink 引入了 Factory.ai 作为代码评审 bot。我第一次可以请求由 LLM 驱动的 PR 评审。最初这些评审并不好,因为 LLM 的回复经常臆想场景,甚至错误地解释事情。2025 年的大部分时间感觉都是这样。你常常得读一堆“垃圾”(但一开始你并不知道),还得花时间追查幽灵问题。翻查这些东西几乎像地狱,GitHub 的 Copilot 也有同样的问题。

如今,我们依赖 Devin Review 和 Codex。几个月下来,我们得出结论:这两者在噪声与实际错误的比例上都恰到好处,而且我们经常发现一个能发现另一个发现不了的问题。

2026 年 3 月,我的时间线上出现了下面这条——一个 agent 在批准 PR:

我们已经把整个代码评审生命周期迁移到了 Automations 上。

Cursor 会批准并放行低风险的改动,并根据提交历史为中/高风险改动自动分配评审人。

把历史上静态的……(展开更多)

我们推出 Cursor Automations,用于构建常驻运行的 agent。

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →