How Forward Deployed Engineering is done at Cognition — Jia Wu

频道: AI Engineer
视频: https://www.youtube.com/watch?v=RVxym6mmIns
原文语言: en
统计: 共 22 轮 · Jia Wu 20

[0:01]

[music]

[音乐]

[0:12] Jia Wu

It's nice to be here. I appreciate you all. My name is Gia. I'm a deployed engineering lead at Cognition. And today, hopefully, what you'll take away from this is that how we deploy Devin in the field is very much a function of how we view deployed engineering at Cognition. So, how the four deployed motion makes AI engineering actually real. Before I start, how many people like have heard of Devin or like know of Devin? Oh, cool. And I'm not talking about like the Devin of today. Like, I'm talking about the Devin back in 2024 when we first released and it was like, "Oh, SweepBench 13%. We're so We're so back." And as engineers, we were like, "We're so cooked." But, I mean, after a week, everyone's like, "Oh, this is actually like not that useful." Um "I would only use this if I was desperate and out of ideas." That's 2024. Uh and let it be said that we have a sense of humor because we took this and we ran with it.

很高兴能来这儿，谢谢各位。我叫 Jia，是 Cognition 的 forward deployed engineering lead。今天我希望大家能带走的一点是：我们在客户现场怎么落地 Devin，很大程度上取决于我们在 Cognition 内部怎么理解 forward deployed engineering 这件事——也就是 FDE 这套打法，是怎么让 AI engineering 真正变成现实的。开始之前先问一下，在座有多少人听说过 Devin，或者知道 Devin？哦，不错。而且我说的还不是今天的 Devin，我说的是 2024 年我们刚发布时的那个 Devin。当时大家的反应是：哇，SWE-bench 13%，我们又行了。而作为工程师，我们的反应是：完蛋，我们要被取代了。不过嘛，一周之后大家就变成了：哦，这玩意儿其实也没那么有用。那种「我只有在实在没辙、走投无路的时候才会用它」的感觉。那是 2024 年。另外说明一下，我们还是有幽默感的，因为我们干脆把这句吐槽拿过来，顺着做成了广告。

[1:00] Jia Wu

I'm sure you've seen all these ads around SF. We're actually good now. So, the reason why we're good is I'll talk a little bit about the product surface area a little bit just to give you folks a little bit of context for who might not have used Devin before, uh who might not have exposure to something like Cognition. So, if you've used Flood Code, we also expose a CLI. If you've used something like, you know, Cursor, Windsurf, we also expose an interface such as an IDE. Uh actually, how many people know of Windsurf or have used Windsurf in the past? Sweet. So, I come over from the Windsurf side after the Windsurf acquisition. Um great times. And then, what we're actually known for, specifically, is for Devin Cloud or the Devin Cloud agent. And I'm not going to bore you to death talking about like all the components and features and everything that comprise of the actual product. I'm not here to sell you on that. What I am here to sell you on is we are one of the premier software engineering functions across the enterprise, and we're actually able to deliver impact on a global scale. What do I mean by that?

你们在旧金山街头应该都见过这些广告了。我们现在是真的好用了。至于为什么好用，我先简单讲讲产品的覆盖面，给那些没用过 Devin、没接触过 Cognition 的朋友一点背景。如果你用过 Claude Code，我们也有 CLI；如果你用过 Cursor、Windsurf 这类东西，我们也提供 IDE 形态的界面。对了，在座有多少人知道 Windsurf，或者以前用过 Windsurf？很好。我是 Windsurf 被收购之后从那边过来的，那段时间很棒。而我们真正为人所知的，其实是 Devin Cloud，或者说 Devin 的 cloud agent。我不打算在这儿一条条念产品由哪些组件、哪些功能构成，把大家听睡着。我不是来卖产品的。我要向各位推销的是：我们是整个企业市场里最顶尖的软件工程职能之一，而且我们真的能在全球范围内交付出实际影响。这话什么意思？

[2:01] Jia Wu

We can take a pause and take a look at this figure. So, internally at Cognition, over the last 6 months, for better or worse, we might have been behind on hiring, but using our agent, we were able to ship almost an order of magnitude more good quality robust PRs across the organization. So, it's a step function increase in the amount of engineering leverage that we can have by deploying our own agent. You don't have to take our word for it. If we take a look If we can take a look at the specifics of how we're actually being consumed, how we're being utilized across the enterprise, it's a parabolic growth of how companies are adopting our agent, deploying our agent, and using it in multiple different use cases and multiple different scenarios. So, what does it mean, right? Like, how does this actually happen? Well, it can only happen with the forward-deployed engineers at Cognition. And I'm going to frame up the problem from like a couple of like buckets, right? So, there's two circles in front of you on the screen.

我们停一下，看看这张图。在 Cognition 内部，过去 6 个月里——不管这算好事还是坏事——我们招人可能是滞后的，但靠着自家的 agent，我们在全公司范围内合入的高质量、健壮的 PR 数量，差不多多出了一个数量级。也就是说，部署自家 agent 带来的工程杠杆，是一次阶跃式的抬升。你不用只听我们自己说。如果去看具体的消费数据、看我们在企业客户那边被使用的情况，会发现企业采用我们的 agent、部署我们的 agent、在各种不同用例和场景里使用它，是一条抛物线式的增长。那这意味着什么？这事到底是怎么发生的？答案是：只有靠 Cognition 的 forward deployed engineer 才可能发生。我想把这个问题拆成几块来讲。屏幕上现在有两个圆。

[2:53] Jia Wu

One of them can represent the domain of a product, right? As a business, as a software engineering organization, obviously, you have a product. You obviously also, on the other side, on the left-hand side or right-hand side for you guys, you specifically have like a bucket of problems that you're looking to solve, right? You have a product, you have problems that you're trying to solve, and the intersection of these two, or whatever you would call it, is the product-market fit. Right? Hopefully, you have a pretty good overlap in the sense that whatever it is that your company does, you can actually bring value to customers. And hopefully, whatever problems the customer has, you can solve with your company's stuff. So, the forward-deployed motion at Cognition essentially aims to maximize the overlap between the products that we typically build and the problems that we're experiencing across the enterprise.

其中一个圆可以代表产品的领域。作为一家企业、一个软件工程组织，你显然有自己的产品。同时在另一边——对我来说是左边、对你们来说可能是右边——你有一堆想解决的问题。你有产品，你有想解决的问题，这两者的交集，随你怎么叫它，就是 product-market fit。理想情况下你希望这两个圆有相当大的重叠：你公司做的东西，确实能给客户带来价值；客户遇到的问题，也确实能被你公司的东西解决。所以 Cognition 的 forward deployed 打法，本质上就是尽可能把我们通常在做的产品，和我们在企业现场遇到的问题之间的重叠面积最大化。

[3:42] Jia Wu

So, what does that mean, right? The first fundamental concept that I would like to convey is that forward-deployed engineers at Cog deeply understand the problem space at hand. And specifically, right? Like if we think of the problem of software engineering, and I'm just going to like mask the features at the bottom, we don't really care about those, but if we think about when you go ahead to take some sort of codebase, some sort of implementation, and you need to like build features, you need to maintain that software, uh you need to like review, deploy, maintain that software. All of these steps, all of these functions have a lot of business value behind them, right? You can only do like it would be great if we could build from zero to one and just like prompt stuff and not worry about like legacy code, but that's not the reality of the situation. It would be great if our product engineers or our product managers could just take user stories and say like these are the things that we need to build in order to get value and revenue.

那这具体是什么意思？我想传达的第一个基本概念是：Cognition 的 forward deployed engineer 对手头的问题空间理解得非常深。具体来说，如果我们来看软件工程这个问题——我把底下那些功能点先盖住，那些我们先不管——当你拿到一份代码库、一套已有的实现，你需要做新功能，需要维护这套软件，需要 review、部署、维护它。所有这些环节、所有这些职能背后，都有大量的业务价值。要是我们能永远只做从 0 到 1、只管 prompt 一下就出东西、完全不用操心遗留代码，那当然很爽，但现实不是这样。要是我们的产品工程师或者产品经理能直接拿着 user story 说「这些就是我们要做的东西，做完就有价值、有收入」，那也很爽。

[4:32] Jia Wu

And then we come to coding. Coding itself, at least from our perspective, is a mostly solved problem, right? These models are so good now that like with any type of context, with enough context engineering, you can get the code blocks that you really care about. But the problem isn't like writing code faster, that's usually only 20% of the problem. The problem really just becomes like how do you test this code? How do you review and deploy this code? And how do you maintain this code across the enterprise? So, that's the premise of the problem. Now, I will predicate that by saying that like we also have the solution, I'm not going to bore you to death about talking to you about the solution, but for deployed engineers at Cognition, we map Devin's capabilities specifically to the customer problem. So, if the software development life cycle is extremely complex, deploying the agents for with like no specific direction, you're straight up just token maxing. Right?

然后就轮到写代码本身了。写代码这件事，至少在我们看来，基本上已经是个被解决的问题了。现在的模型好到什么程度？只要给到合适的上下文，只要 context engineering 做到位，你真正在意的那些代码块它都能给你。但真正的问题从来不是「把代码写得更快」，那通常只占问题的 20%。真正的问题变成了：这些代码怎么测？怎么 review、怎么部署？以及在整个企业范围内怎么长期维护？这就是问题的前提。当然我得补一句，我们也是有解法的——我不打算把解法一条条念给你们听——但对 Cognition 的 forward deployed engineer 来说，我们做的事就是把 Devin 的能力精准地映射到客户的问题上。因为软件开发生命周期极其复杂，如果你没有明确方向就把 agent 扔进去跑，那你纯粹就是在 token maxing（拼命烧 token）。对吧？

[5:20] Jia Wu

Like you were wasting tokens, you were burning you were burning spend, you're not getting any tangible outcomes. So, we try to identify, when we partner with customers, when we take meetings, and for example, right? Like my day might look like four or five hours of customer calls, and then four or five hours of like actual hands-on keyboard work. Those four or five hours of calls actually allow us to understand very deeply what strategic initiatives are the highest leverage for the business. Right? Once Once identified that, right? How can we automate ourselves out of the job in the sense that we set up the agent in a way that it runs all of the automations for us, right? We don't have to be there manually triggering the agents. It can respond to like specific alerts, specific events. But most importantly, as forward deployed engineer, how do you measure the return on investment? And it's very ambiguous.

你只是在浪费 token，在烧预算，却拿不到任何实打实的结果。所以我们在和客户合作、开会的时候，会努力把真正的问题识别出来。举个例子，我一天的日程可能是四五个小时的客户电话，再加四五个小时真正动手敲键盘的工作。而那四五个小时的会，恰恰能让我们非常深入地搞清楚：对这家企业来说，哪些战略性举措的杠杆最高。一旦识别出来，接下来就是：我们怎么把自己从这份工作里自动化掉？也就是把 agent 配置成能替我们跑完所有自动化，我们不需要人守在那儿手动触发它，它可以响应特定的告警、特定的事件。但最重要的一点是，作为 forward deployed engineer，你怎么衡量 ROI（投资回报）？这件事非常模糊。

[6:06] Jia Wu

And it's an unsolved problem because the company that will solve this will be um you know, $5 trillion market cap. So, specifically, our forward deployed engineers will embed in the customers ecosystems, right? We take a look at, you know, the backlog of stuff that needs to be built. We take a look at the remediations that need to be done. We take a look at all of like the delayed code that never ships or the test that nobody writes uh or the automatic triage of specific alerts. And we map our product capabilities into those problems. That being said, if we all do our job and we solve the customers problems 100% and the customer is very happy, that is only half of the equation, right? Not only do we have to solve the customer's problem, we also need to solve for our product. What do I mean by that, right? If we are taking it union of like the problems that the customers have and the products that we are building, right? Solving the problem only shifts like part of the Venn diagram. But in order to get that true feedback loop where we unify like the maximal overlap between what we're doing and what the customers need, that is forward deployed engineering at Cockroach Labs. So, the second part of this that I want to emphasize is that at our company, we map the customer problems back to the capabilities at hand. Now, how do we do that, right?

而且这是个尚未被解决的问题——谁把它解决了，谁就会是市值 5 万亿美元的公司。具体来说，我们的 forward deployed engineer 会嵌进客户的生态里。我们去看那些待建东西的 backlog，去看那些需要做的修复整改，去看那些永远发不出去的积压代码、没人写的测试，还有那些需要自动分诊的告警，然后把我们的产品能力映射到这些问题上。话虽如此，就算我们把活干得完美，100% 解决了客户的问题、客户非常满意，那也只完成了方程的一半。我们不光要解决客户的问题，还要为我们自己的产品解决问题。这话什么意思？如果我们把客户遇到的问题和我们正在建的产品这两个集合放在一起看，光解决客户的问题，只是挪动了维恩图的一部分。而要形成那个真正的反馈闭环、让我们在做的事和客户需要的事重叠到最大，这才是 Cognition 的 forward deployed engineering。所以我想强调的第二点是：在我们公司，我们会把客户的问题反向映射回手上的产品能力。那这怎么做到？

[7:18] Jia Wu

A lot of engineering challenges come in similar shapes um from the field, right? We have the highest fidelity evaluation set that comes back from our customers, right? We are in the field every single day. We are hearing about the problems. We are hearing about whatever the customers are doing. And we have to take that context and bring it back to product in a sensible way. So, what are the ways in which these enterprise challenges, you know, manifest? are they common across the entire enterprise or are they unique to a specific user? Should like workarounds or like hacks or bugs in in in what we're building become features, right? Because ultimately what we want to do as a company is we want to de-risk our road map. At the end of the day, it would be great if like I as an engineer knew exactly what to build to get Y percentage of revenue from particular customer. And that's exactly what the problem is that we're trying to solve for because we are ultimately at the end of the day the heralds of the change, right? We are the bridge between products. We are the bridge between problems and the feedback is actually like half of the loop that makes the next deployment better than the previous deployment.

现场遇到的很多工程难题，形状其实是相似的。我们手上有保真度最高的一套评测集，它是从客户那儿反馈回来的。我们每天都在一线，我们在听客户遇到的问题，在听他们到底在做什么。然后我们必须把这些上下文以一种合理的方式带回产品团队。所以要问的是：这些企业级难题是以什么形式冒出来的？它们在整个企业里是普遍存在的，还是某个特定用户独有的？我们产品里那些绕行方案、那些 hack、那些 bug，是不是该被做成正式功能？因为作为一家公司，我们最终想做的是给自己的路线图去风险。说到底，如果我作为工程师能确切知道该做什么，才能从某个客户身上拿到 Y% 的收入，那该多好。而这正是我们要解决的问题，因为归根结底，我们是变化的传令官。我们是产品之间的桥梁，我们是问题之间的桥梁，而这些反馈其实构成了闭环的另一半——正是它让下一次交付比上一次更好。

[8:24] Jia Wu

So, if we think about the T-shape or personas of the folks that we hire, and for a deployed engineer, it's just so it's so flexible in terms of how you actually define it. Like, are you a sales engineer? Are you a solutions architect? What are you, right? So, if you think about all of the skills that FDEs typically are expected to have, right? You probably want to go wide. You probably want to have, you know, good people skill, like business skill, good process, customer skill, or even technology, right? In order to be deployed in the space, you need to know like what whatever the tech is. So, we also look for very deep spikes across people, right? Folks at Cognition deployed engineers at Cognition, we will hire them from like product management backgrounds if they have a really good sense of like how products are supposed to fit into each other, right? Because if the cost of software engineering is going to zero, you actually need to know how to like design a product that makes sense.

再说说我们招人时看重的 T 型能力结构，或者说人才画像。forward deployed engineer 这个岗位，定义上极其灵活：你算销售工程师吗？算解决方案架构师吗？你到底算什么？所以如果你去列 FDE 通常被期待具备的技能，你会希望横向铺得足够宽：要有不错的沟通能力、商业能力、流程能力、面向客户的能力，甚至技术能力——你要去现场部署，就得懂对方那套技术是什么。同时我们也很看重每个人身上那根扎得特别深的尖刺。Cognition 的 forward deployed engineer，我们也会从产品经理背景里招人——只要他对产品之间该怎么咬合有很好的判断力。因为如果软件工程的成本正在趋近于零，你就真的得知道怎么设计一个说得通的产品。

[9:16] Jia Wu

Cuz you can just prompt it. But we also hire folks that are like founders, software engineers, but specifically like very spiky in the technology domains, right? It's fine if you don't have like the strongest business sense, that can be learned, but it's also very hard to teach like technicality and being the expert in the room while you're on the job. So, there's a couple of personas that we specifically hire for. Good customer engineers or deployed engineers do everything, right? Like they can map the product back to road map, like they can solve the customer's problems. Great customer engineers are able to actually have that relentless curiosity for why. So, at Cognition, we always ask ourselves, "Why are we solving this problem? Does this problem matter to the to the business as a whole? And can I communicate this back to the road map in a way that like improves the problem for everybody else?"

因为这些东西提示词写一写就有了。但我们同时也招那种创业者、软件工程师背景的人，特别是技术上非常尖的那种。你商业嗅觉不是最强没关系，那是可以学的；但技术功底、以及在客户会议室里当那个最懂行的人，这些在岗位上很难教会。所以我们招人时会特别盯着几类画像。合格的 customer engineer 或者 deployed engineer 什么都能干：能把产品需求映射回路线图，能解决客户的问题。而顶尖的 customer engineer，是真的对「为什么」有那种不依不饶的好奇心。所以在 Cognition，我们总是问自己：我们为什么要解决这个问题？这个问题对整个业务到底重不重要？我能不能把它反馈回路线图，让所有其他人的这个问题也一起被解决掉？

[10:05] Jia Wu

But we also are The second mantra that we subscribe to is that you have to be relentlessly tied in to the customer, right? They are our lifeblood at the end of the day. Making them successful is the only way that you can survive as a business and become the obvious choice for an enterprise partnership. So, these are the two mantras that we specifically subscribe to as uh deployed engineers at Cognition. So, previously, um the first approach to deployed engineering was just, you know, token maxing, right? Uh the next era that I'll talk about is intelligent orchestration, but with like outcomes that you can actually measure, and I'll give you guys some examples. So, previously, like a year, maybe a year and a half, two years ago, uh the target or KPI for whatever deployed engineers were trying to do is maximize token usage, right? It was It was like the perfect time. Didn't have to worry about budgets. Everything was subsidized. You could just like run anything you wanted.

我们信奉的第二条信条是：你必须和客户死死绑在一起。说到底他们才是我们的命脉。让客户成功，是你作为一门生意活下来、并且成为企业合作里那个「显而易见的选择」的唯一路径。这就是我们在 Cognition 做 deployed engineer 所奉行的两条信条。回过头看，deployed engineering 的第一代做法就是 token maxing——把 token 用量拉满。接下来我要讲的下一个时代，是「智能编排」，而且是带着可被真正衡量的结果的那种，我会给大家举一些例子。大概一年前、一年半、两年前，deployed engineer 干活的目标或者说 KPI，就是把 token 用量最大化。那真是个完美的时代，不用操心预算，一切都有人补贴，你想跑什么就跑什么。

[10:59] Jia Wu

But now, the problem has really shifted into the delivery space, right? A lot of organizations that we work with, some of the largest and most regulated enterprises in the world, they really care about, "Are we getting true value out of this solution, or are we just burning tokens for no reason, right?" And that is one core differentiator that I need to call out between us and some of the other platforms. You can make engineers like 10x faster. That's fine. That's still valuable. But can you make an organization 10x faster, including every single person that might be technical or non-technical uh across the company? That's when you unlock the true value of being the partnership. And that's why like single point tools that are just like CLIs or just IDEs, they fail to do that. So, let me just give you some proof points of how we've operated across the enterprise. So, at Cognition, um when we run the agent and the agent has like a specific trace or trajectory or like the agent does something, we call that a session.

但现在，问题真正转移到了交付这一侧。跟我们合作的很多组织，包括全世界规模最大、监管最严的一批企业，他们真正在意的是：我们到底有没有从这套方案里拿到真实价值，还是只是在毫无意义地烧 token？这也是我必须点出来的、我们和其他一些平台的一个核心区别。你可以让工程师快 10 倍，这没问题，这依然有价值。但你能不能让一个组织快 10 倍——包括公司里每一个人，不管技术岗还是非技术岗？做到这一点，你才真正解锁了「成为合作伙伴」的价值。这也是为什么那些单点工具，只是一个 CLI 或者只是一个 IDE，它们做不到这件事。下面我给大家一些实证，讲讲我们是怎么在企业里跑起来的。在 Cognition，当我们把 agent 跑起来、agent 产生一条特定的 trace 或者轨迹、agent 做完一件事，我们把这称为一次 session。

[12:00] Jia Wu

A session itself, right? We have metrics that allow you to derive how many engineering hours you can actually generate and how much how many engineering hours are actually productive that users are running. Right? So, one of these examples is a case study where we embedded ourselves within a customer for 3 months. We brought them on board. And functionally, over the course of those 3 months, we delivered about 150% like plus headcount. So, if you thought about like a project that you're trying to ship or something that you're trying to develop or a migration that you're trying to go through, imagine having 150 extra coworkers doing that with you by your side. You might just say, "Hey, this actually just kind of looks like token maxing, right? Like you're just giving me a metric that says it's just, you know, engineering hours. You're like running a bunch of different sessions. Like, how do we know that these sessions are true, meaningful, and valuable?" So, the second part of that is, okay, we can think about how we've reduced timelines for delivery projects on an order of magnitude. So, about like 82% reduction across like delivery. So, if you subscribe to the agile deliver agile development methodology, obviously like you have tickets, you have sprints, like you have things that need to be built. If you look at every single metric that you measure before you bring in Devin and after you bring in Devin, you can take a look at that. We can compress this timeline by a factor of like 82%. So, across the board, whenever we get developed, whenever we get deployed, and fully activated within the customer

就 session 本身而言，我们有一套指标，能推算出你实际产出了多少工程小时，以及用户跑出来的这些工程小时里有多少是真正有产出的。举个例子，有个案例是我们驻场在一家客户内部三个月。我们把他们带上手，实打实地说，这三个月里我们交付了大约相当于增加 150% 人头的产能。你想想，如果你手上有个要发的项目、要开发的东西，或者要做的一次迁移，想象一下有 150 个额外的同事在旁边陪你一起干。你可能会说：「等等，这看着不就是 token maxing 吗？你只是给了我一个叫『工程小时』的指标，你不过是跑了一大堆 session 而已。我们怎么知道这些 session 是真实的、有意义的、有价值的？」所以第二部分是：我们可以看看，交付类项目的周期被我们压缩了多少个数量级。大概是整个交付环节下降约 82%。如果你信奉敏捷开发方法论，那你显然有 ticket、有 sprint、有要做的东西。你把引入 Devin 之前和引入 Devin 之后测的每一个指标都拿出来对比，就能看得很清楚：我们能把这条时间线压缩掉大约 82%。所以放眼全局，只要我们被部署进去、并且在客户环境里被完全激活，

[13:22] Jia Wu

environment, not only do we deliver a massive scale in terms of like engineering capacity, but we also reduce the time to value in terms of bringing things to market. Now, the third part of that is, hey, but I actually really care about the numbers, right? I actually really want to see how many PRs are you actually shipping? Like, is this meaningful? Does this actually make sense? So, if you think about dissecting the numbers a little like one dimension further, and you want to just look at like the raw PRs that people are ripping across the enterprise, we deliver almost double the amount of PRs that engineers were able to do with single-point tools and before you brought in an agent harness like Devin. So, there's three proof points of anonymized case studies in which we are able to deliver value at scale and across like various different problem domains. What I'll say is these aren't like, you know, private case studies. We have a bunch of different public case studies as well.

我们不仅交付了巨大规模的工程产能，同时也缩短了产品推向市场的 time to value。第三部分是：「好，但我真正在乎的是数字。我就想看你到底发了多少个 PR，这事有意义吗？这真的说得通吗？」那我们把数字再往下拆一层，只看整个企业里大家实际发出的原始 PR 数量：相比只用单点工具、在引入 Devin 这样的 agent harness 之前，工程师的 PR 数量翻了将近一倍。这就是三个匿名案例的实证，说明我们能在规模上、在各种不同的问题领域里交付价值。我要说明的是，这些并不是只有私下的案例，我们还有一堆公开的案例研究。

[14:16] Jia Wu

So, we partner with companies like Nubank, right? If you folks have ever gone to Latin America, you can understand that, you know, the there's a lot of developers there. There's a lot of projects that are tangentially related. So, specifically, like we can say that there was an ETL migration. They had 50 engineers staffing this migration. We were able to deliver this within, um, I think like 1/3 of the timeline. Just with Devin autonomously. We have another bank, right? We have another use case where we work with one of the largest banks in Latin America. They were trying to migrate like the tax identification system. I know, like rocket science, right? Um, but the idea is that we were able to deliver this with half of the amount of effort actually required. So, if you think about like legacy languages like COBOL, if you think about things like JCLs, you think about things that like people don't learn anymore just because it's like not fun and not interesting, we're able to operate across some of the most complicated codebases in the world and deliver results that actually matter.

比如我们和 Nubank 这样的公司合作。如果你去过拉美，你就知道那边开发者非常多，也有一大堆彼此沾边的项目。具体来说，他们有一个 ETL 迁移项目，原本配了 50 个工程师。我们把它做完只用了大概原计划三分之一的周期，而且是 Devin 自主完成的。还有另一家银行——我们跟拉美最大的银行之一合作，他们要迁移税号识别系统。我知道，这听着跟造火箭似的。但重点是，我们把它做完，只花了实际需要的一半工作量。所以如果你想想 COBOL 这类遗留语言，想想 JCL 这种东西，想想那些已经没人愿意学、因为既不好玩也不有趣的技术栈——我们有能力在全世界最复杂的一批代码库上作业，并交付真正有意义的结果。

[15:13] Jia Wu

And last but not least, obviously like if we think about the built card, um, specifically, we're able to actually merge like an order of magnitude more, um, in terms of like PR acceptance rate. We deliver like 10x per sub like worth of engineering talent like every single week. And then we're actually able to, you know, generate the weekly output of like over 10 engineers at the organization. Built has great engineers, by the way, right? These guys are so cracked. So, if you take one of these engineers and multiply them by 10, you just imagine the amount of returns. So, what I'll say is I'll I'll probably like round off this talk by just saying that at Cognition, we don't just, you know, embed ourselves in the customers. We don't just, you know, propagate feedback back to everybody else. But, the core values of the company are things and principles that we subscribe to not internally to the company, but external to the company as well, right? It's really fun being on the winning team. It's really fun when you come into an organization and say, "We can actually deliver so much cool stuff and like make people our champions, right? Whoever deploys Devin within the organization, they can show results that are essentially unmatched across the board."

最后但同样重要的，说到 Built 这家公司，我们在 PR 接受率上实现了数量级的提升，合并的量大幅增加。我们每周交付的相当于 10 倍的工程人力价值，实际上能产出这个组织里 10 名以上工程师的周产出。顺便说一句，Built 的工程师非常强，这帮人是真的猛。所以你拿他们中的一个乘以 10，你就能想象那个回报有多大。我大概要收尾了，最后说一句：在 Cognition，我们做的不只是驻场到客户那里，也不只是把反馈传回给团队；公司的核心价值观，是我们不只对内、也对外践行的一套原则。待在赢的那一队真的很爽。你走进一个组织，说「我们真的能交付一堆很酷的东西」，然后把这些人变成我们的拥护者——谁在组织内部把 Devin 部署起来，谁就能拿出全场无可匹敌的结果，这种感觉真的很爽。

[16:16] Jia Wu

And we go for it all, right? We leave nothing on the table. We've deployed somebody in Brazil for like 10 months.

而且我们是全力以赴的，一点余地都不留。我们曾经把一个人派到巴西驻了差不多 10 个月。

[16:22]

[laughter] [snorts]

[笑声]

[16:23] Jia Wu

To to live next to one of the customers to just make them successful. So, we're down for the mission. And it's it's more about like correctness, right? Like if if there are engineering practices that we want to fix, if there are things that we want to flag and raise, like these are all things that we take back to product and there's no ego involved. At the end of the day, we are all in the same boat. We're on the same mission and we're just shipping. And everybody essentially is go-to-market. I know forward deployed engineering is kind of like this fuzzy thing where it's like, "Am I part of sales? Am I part of post-sales? Like what do I actually do as an FDE?" But, everybody is go-to-market because the target is to make the customer successful at all costs. And at the end of the day, we just do things because every second counts. So, if you're interested in, you know, forward deployed engineering at Cognition, being the intersection between some of the hardest problems in this world, being part of like all of the software disruption at scale, and then being on the other side of these problems, we should talk.

就为了住在客户旁边，只为让他们成功。所以我们是真的认这个使命的。而且这件事更多是关于「做对」——如果有工程实践需要我们去纠正，如果有问题需要我们指出来、提上去，这些我们都会带回产品团队，中间没有任何自尊心作祟。说到底我们都在同一条船上，扛的是同一个使命，就是一路往前发。而且本质上每个人都是 go-to-market。我知道 forward deployed engineering 听起来是个挺模糊的东西：我算销售吗？我算售后吗？我这个 FDE 到底是干什么的？但每个人都是 go-to-market，因为目标就是不惜一切代价让客户成功。归根到底我们做这些事，是因为每一秒都算数。所以如果你对 Cognition 的 forward deployed engineering 感兴趣——站在这个世界上最难的一批问题的交叉口，参与规模化的软件颠覆，并且站在这些问题被解决的那一侧——我们该聊聊。

[17:18] Jia Wu

Thank you.

谢谢大家。