Talk by Jia Wu (Cognition) on forward deployed engineering: how Cognition's deployment team measures Devin's impact by customer-visible outcomes rather than token usage, including a reported ~82% reduction on targeted work measured before and after activation. Covers why value scales from step function (single team) to parabolic (whole enterprise), how deployed engineers blend engineering with business and people skills to target high-leverage work, and the emphasis on correctness and customer success. # Channel Presentation Observations — "How Forward Deployed Engineering is done at Cognition — Jia Wu" ## Explicit Self-Description Evidence - **Speaker role stated directly**: "My name is Gia. I'm a deployed engineering lead at Cognition." - **Scope claimed for the talk**: "how we deploy Devin in the field is very much a function of how we view deployed engineering at Cognition." - **Positioning claim**: "we are one of the premier software engineering functions across the enterprise, and we're actually able to deliver impact on a global scale." - **Company affiliation context**: Speaker notes, "I come over from the Windsurf side after the Windsurf acquisition." ## Intended Audience - **Technical/developer audience, likely in-person at an event**: Speaker polls the room — "how many people like have heard of Devin," "how many people know of Windsurf or have used Windsurf in the past?" - **Audience assumed familiar with AI coding tools**: references to Cursor, Windsurf, CLIs, IDEs, SWE-Bench scores without basic explanation. - **Implicit recruiting angle**: closes with "if you're interested in, you know, forward deployed engineering at Cognition... we should talk." ## Claimed Scope of Content - Explains the forward-deployed engineer (FDE) role at Cognition: customer embedding, capability mapping, feedback loops to product. - Frames FDE skills/hiring personas: "sales engineer? ... solutions architect?" — wide skills plus "very deep spikes" in technology or product. - Presents case studies (anonymized plus named: Nubank, a large Latin American bank, "Built") with metrics: "~150% plus headcount," "82% reduction across delivery," "almost double the amount of PRs." ## Observable Presentation Patterns - **Promotional/self-advocating tone**: "What I am here to sell you on is we are one of the premier software engineering functions." - **Self-deprecating humor about past product criticism**: references 2024 Devin reception ("'We're so cooked'") and the "We're actually good now" ad campaign — "we took this and we ran with it." - **Metric-heavy persuasion**: repeated quantitative proof points (engineering hours, PR counts, timeline compression) framed as differentiators vs. "single point tools." - **Named-value framing**: "Making them successful is the only way that you can survive as a business and become the obvious choice for an enterprise partnership." ## Claims vs. Demonstrated Distinction - All impact figures (150% headcount, 82% reduction, 10x output, Nubank ETL migration) are **creator claims** presented without shown methodology; no underlying data is demonstrated in the transcript. - One apparent slip: "that is forward deployed engineering at Cockroach Labs" — refers to a different company than Cognition elsewhere in the talk. - Values statements ("no ego involved," "we leave nothing on the table," "everybody is go-to-market") are stated principles, not observable behaviors. # Delivery Observations — "How Forward Deployed Engineering is done at Cognition — Jia Wu" ## Tone & Register - **Conversational, casual presentation style** with frequent filler words like "like," "you know," "right?" and "uh." > "So, if you've used something like, you know, Cursor, Windsurf, we also expose an interface such as an IDE." - **Humor and self-deprecation**, including internet slang: > "it was like, 'Oh, SweepBench 13%. We're so We're so back.' And as engineers, we were like, 'We're so cooked.'" > "They were trying to migrate like the tax identification system. I know, like rocket science, right?" - **Confident, sales-adjacent framing** despite the casual register: > "What I am here to sell you on is we are one of the premier software engineering functions across the enterprise." ## Recurring Phrases & Verbal Habits - **"right?" as a constant check-in / connective phrase** — appears throughout ("So, what does that mean, right?", "at the end of the day, right?", "It's very ambiguous. And it's an unsolved problem… right?"). - **"like" as an all-purpose filler** — near-constant, even mid-clause: > "you need to like build features, you need to maintain that software, uh you need to like review, deploy, maintain that software." - **"at the end of the day"** used repeatedly as a rhetorical closer: > "they are our lifeblood at the end of the day" > "At the end of the day, we are all in the same boat." - **"So," as a sentence starter** — dozens of utterances begin with "So," marking transitions between points. - **"de-risk," "leverage," "token maxing," "10x," "order of magnitude"** — repeated business/tech jargon; "token maxing" appears at least three times as a recurring motif. ## Teaching / Structuring Habits - **Rhetorical question → answer pattern** to structure sections: > "What do I mean by that?" / "So, what does that mean, right?" / "Now, how do we do that, right?" - **Audience interaction via show of hands**, at least twice: > "how many people like have heard of Devin or like know of Devin?" > "how many people know of Windsurf or have used Windsurf in the past?" - **Numbered/enumerated proof points**, explicitly counted: > "So, there's three proof points of anonymized case studies…" > "The third part of that is…" - **Concrete numbers to anchor claims**: "82% reduction," "150% like plus headcount," "10x per sub," "1/3 of the timeline." - **Anticipating audience skepticism and pre-empting it**: > "You might just say, 'Hey, this actually just kind of looks like token maxing, right?'" ## Persona & Framing - **Dual framing of "good vs. great"**, a classic contrast device: > "Good customer engineers or deployed engineers do everything… Great customer engineers are able to actually have that relentless curiosity for why." - **Explicitly stated "mantras"** as a summarizing teaching device: > "these are the two mantras that we specifically subscribe to as deployed engineers at Cognition." - **Internet-culture vocabulary** ("so cracked," "we're so back," "we're so cooked," "sweet") suggesting an engineer-to-engineer register rather than formal corporate delivery. ## Verbal Slips / Anomalies (observable, not interpretive) - Possible misstatements of the company name and a competitor's name: > "forward deployed engineering at Cockroach Labs" (context indicates Cognition is intended) > "if you've used Flood Code" (likely Claude Code) - These appear to be isolated slips; the speaker otherwise says "Cognition" consistently, so no pattern is claimed beyond the individual moments. ## Uncertainty Notes - Filler frequency ("like," "right?") is clearly repetitive and stable across the talk; this is a strong pattern. - Whether pauses, pacing, or visual delivery habits exist cannot be confirmed from the transcript alone — only verbal features are observable here. - The "at the end of the day" repetitions number roughly four-plus instances, which supports but does not guarantee a deliberate rhetorical habit rather than incidental phrasing. # Position Extraction: How Forward Deployed Engineering is done at Cognition — Jia Wu ## Speaker - **Jia Wu** ("Gia"), introduced as a deployed engineering lead at Cognition; states she came over from Windsurf after its acquisition. ## Framing Claim - How Devin is deployed in the field is "very much a function" of how Cognition views deployed engineering; the forward-deployed motion is what makes AI engineering "actually real." ## Positions & Claims ### On Devin's History and Reputation - Recalls 2024 Devin reception: SWE-Bench ~13%, engineers felt "we're so cooked"; after a week, sentiment was "this is actually not that useful — I would only use this if I was desperate and out of ideas." - Cognition embraced that criticism with humor (SF "We're actually good now" ads); Wu claims "the reason why we're good" now follows from the deployment practices described. ### Product Surface (claimed, descriptive) - Devin is exposed as a CLI, an IDE-style interface, and the Devin Cloud agent. - Wu explicitly says she is not there to sell features but to argue Cognition is "one of the premier software engineering functions across the enterprise." ### Internal Impact Claims - Over the last 6 months, despite lagging hiring, Cognition shipped "almost an order of magnitude more good quality robust PRs" using its own agent — a "step function increase" in engineering leverage. - Enterprise adoption shows "parabolic growth" (claimed, no figures given). ### Core Model: Product–Problem Overlap - Visualized as a Venn diagram: product domain vs. customer problems; overlap = product-market fit. - Forward-deployed engineering (FDE) aims to **maximize this overlap** in both directions: 1. Solve the customer's problem (only "half of the equation"). 2. Feed field insight back to product to de-risk the roadmap and improve the next deployment. ### On the Nature of Software Engineering - Building from zero with prompts would be ideal, "but that's not the reality." - **Coding is "a mostly solved problem"** from Cognition's perspective — with enough context engineering, models produce the needed code. - Writing code faster is "only 20% of the problem"; the real problems are testing, reviewing, deploying, and maintaining code across the enterprise. - Deploying agents "with no specific direction" is "straight up just token maxing" — wasting spend with no tangible outcomes. ### FDE Practice (as described by Wu) - Day-to-day: ~4–5 hours of customer calls plus 4–5 hours hands-on keyboard work; calls surface the "highest leverage" strategic initiatives. - Goal: "automate ourselves out of the job" — agents respond to alerts/events without manual triggering. - FDEs examine customer backlogs, remediations, unshipped code, unwritten tests, alert triage, and map Devin capabilities onto them. - **Measuring ROI of AI agents is "very ambiguous" and unsolved** — Wu speculates the solving company would be a "$5 trillion market cap" (explicitly speculative). - FDEs decide whether field workarounds/hacks/bugs should become product features; customer problems form the "highest fidelity evaluation set." ### Hiring Philosophy (T-shaped personas) - Wide skills expected: people, business, process, customer, technology. - Deep "spikes" valued; hires from PM backgrounds (because "if the cost of software engineering is going to zero, you actually need to know how to design a product") and founder/engineer backgrounds strong in technical domains. - Stated trade-off: business sense "can be learned"; technicality is "very hard to teach on the job." - Two mantras: **relentless curiosity for why** (does this problem matter to the business) and **relentless ties to the customer** ("they are our lifeblood"). ### Evolution of Deployment Metrics - Prior era (~1–2 years ago): KPI was **maximizing token usage**; budgets were subsidized. - Now: largest, most-regulated enterprises care about true value vs. "burning tokens for no reason." - Differentiator claim: making an engineer 10x faster is fine, but making the **whole organization** 10x faster — technical and non-technical staff — is the real unlock; single-point tools (CLIs, IDEs alone) "fail to do that." ### Case Study Claims (presented as anonymized unless named) - **Anonymized 3-month embedding:** ~150% "plus headcount" in delivered engineering hours. - Anticipating the skepticism that this is "just token maxing," offers: **82% reduction in delivery timelines** measured pre/post-Devin. - **~2x the PRs** vs. engineers using single-point tools. - **Nubank (public):** ETL migration staffed by 50 engineers delivered in ~1/3 of the timeline with Devin autonomously. - **Large Latin American bank (unnamed):** tax identification system migration delivered with half the required effort; claims capability on COBOL/JCL legacy codebases. - **"Built" (Bilt?):** an order of magnitude higher PR acceptance/merge rate; "10x worth of engineering talent every single week," weekly output of 10+ engineers; Wu qualifies that Bilt's engineers "are so cracked," making the multiplier more impressive. ### Closing Claims - Cognition applies its values externally, not just internally; "whoever deploys Devin... can show results essentially unmatched." - Anecdote: someone deployed to Brazil for 10 months to live next to a customer. - **"Everybody is go-to-market"** — FDE's fuzzy sales/post-sales boundary resolved by the target of customer success "at all costs"; "every second counts." ## Qualifications & Tensions Preserved - Wu concedes the "150% headcount" metric could look like token maxing and responds with additional metrics rather than resolving the measurement question. - ROI measurement is explicitly called unsolved and ambiguous. - Internal impact ("order of magnitude more PRs") is self-reported with "for better or worse" hedging on hiring. - The speaker self-describes as selling a position ("What I am here to sell you on"), so promotional framing is explicit in the source. # Speaker Attribution & Provenance Record ## Video **Title:** How Forward Deployed Engineering is done at Cognition — Jia Wu **Video ID:** `01a15ca8-357c-7f64-805a-ffef1adbe031` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Gia / Jia Wu** (transcript says "Gia"; title says "Jia Wu") | **Creator / sole presenter** — introduced as "deployed engineering lead at Cognition" | Self-introduction at talk opening | | **Live audience** | Unnamed, non-speaking participants | Responds to show-of-hands questions and laughter; no speaking lines | - Single-speaker conference/talk format; no narrator, guest, or host speech present. ## Promotional Segments (Flagged) The talk is a **promotional presentation on behalf of Cognition and Devin**, with explicit promotional framing throughout: - **Early on:** "What I am here to sell you on is we are one of the premier software engineering functions across the enterprise." - References to advertising campaigns: "I'm sure you've seen all these ads around SF. We're actually good now." - **Closing recruitment pitch:** "if you're interested in forward deployed engineering at Cognition... we should talk." ## Referenced Sources & Third-Party Claims All claims below are **speaker-asserted, from the presenter**, not independently verified in the transcript: ### Cited sources - **SWE-Bench** (transcribed as "SweepBench") — 13% figure for Devin's 2024 release. - **Public case studies** with named companies: - **Nubank** — ETL migration, 50 engineers, delivered in ~1/3 of the timeline with Devin. - Unnamed "one of the largest banks in Latin America" — tax identification system migration at half the effort. - **Built** (transcribed as "the built card" / "Built") — ~10x PR acceptance/merge rate, weekly output of 10+ engineers. ### Internal / anonymized claims - Internal Cognition: ~order of magnitude more PRs shipped over 6 months using their agent. - Anonymized customer case study: 3-month embedding, ~150% "plus headcount"; ~82% delivery timeline reduction; ~2x PRs vs. single-point tools. - Speaker states these are "three proof points of anonymized case studies" and that public case studies also exist. ### Named third-party entities - **Windsurf** — speaker states they came over "after the Windsurf acquisition"; audience familiarity polled. - **Flood Code** (likely transcription of **Claude Code**), **Cursor** — referenced as competitor/comparable product surfaces. ## Uncertainty & Data Limits - Speaker name discrepancy: transcript self-introduction says **"Gia"**; video title says **"Jia Wu"**. Identity not resolvable from source alone. - Possible transcription artifacts: "SweepBench" (likely SWE-Bench), "Flood Code" (likely Claude Code), "built card"/"Built" (company name uncertain), "Cockroach Labs" (apparent misspoken reference to Cognition mid-talk). - **No curated metadata supplied** — no timestamps, verified metrics, links to cited case studies, or channel information available. - **Comment availability:** not indicated in source material. \>\> 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. 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? 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. 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. 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. 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? 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. 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? 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. 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. 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?" 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. 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. 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 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. 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. 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." And we go for it all, right? We leave nothing on the table. We've deployed somebody in Brazil for like 10 months. \>\> \[laughter\] \>\> 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. Thank you.