How Forward Deployed Engineering is done at Cognition

A coding agent can resolve benchmark tasks and still leave engineers wondering when they would actually use it. That was the gap around Devin at its 2024 launch: excitement about autonomous software engineering quickly met disappointment about practical usefulness. Jia Wu, a deployed engineering lead at Cognition, recalls a roughly 13% SWE-bench result at launch. That is a historical benchmark result, not a measure of current performance or enterprise productivity. Within a week, he remembers the reaction shifting from anxiety about engineers becoming obsolete to treating the agent as something to try when other ideas had run out.

Cognition eventually incorporated that skepticism into its advertising, presenting the product as useful now with a deliberately self-deprecating campaign. But the deployment question remains more demanding than whether the agent can write code: how does its capability become something a customer can rely on? The product offers familiar entry points—a CLI comparable to Claude Code and an IDE interface comparable to Cursor or Windsurf. Those surfaces establish how an engineer interacts with the system; they do not, by themselves, explain how an organization gets value from it.

Wu came from the Windsurf side following Cognition’s acquisition of Windsurf. Alongside the CLI and IDE, he identifies Devin Cloud as Cognition’s best-known agent offering. The broader ambition is to make the agent part of an enterprise software engineering function, rather than simply another place to request code.

Wu reports that Cognition shipped almost an order of magnitude more PRs internally over the preceding six months while hiring lagged. He characterizes those PRs as robust and good quality, and describes rapidly growing enterprise adoption across different use cases. These are his reported observations; the talk does not establish a separate quality measurement or provide the underlying adoption data. They set up the operational question: what work makes that expansion possible?

Imagine two circles: one contains what a product can do; the other contains the problems customers need solved. Their intersection represents product-market fit. Forward deployed engineering at Cognition aims to enlarge that overlap. Doing so requires understanding the customer’s problem domain, not merely knowing the product’s features.

For software engineering, the problem domain includes the entire life of an existing codebase. Features must be built, reviewed, deployed and maintained. Legacy software prevents most enterprises from treating development as a clean sequence of prompts that starts from nothing. Even a well-written user story only identifies something worth building; the organization still has to turn it into working software that creates business value.

Given sufficient context engineering, Wu regards generating the desired code blocks as largely solved. Wu estimates that writing code is usually only 20% of the problem. That is his framing of the work, not a universal measured allocation. Faster code generation leaves testing, review, deployment and maintenance to solve. An FDE therefore needs to locate the actual constraint in that chain before deciding where an agent belongs.

Deploying agents into a complex development lifecycle without a specific objective can produce consumption without useful delivery. Wu calls this token maximization: the system runs, tokens are spent, but no tangible outcome necessarily follows. The first deployment task is to map Devin’s capabilities to a customer problem important enough to justify the work.

Customer discovery and implementation are tightly connected. Wu describes a workday with four to five hours of customer calls followed by four to five hours at the keyboard. The calls identify strategic initiatives with the greatest business value. Implementation then turns the selected work into automations that can respond to alerts or events, without an FDE manually starting every agent run. The intended progression is:

1. Identify a consequential business initiative with the customer.
2. Find the software work that blocks it.
3. Configure the agent to perform the relevant work.
4. Connect recurring work to the events that should trigger it.

The goal is to make the workflow repeatable without requiring the deployed engineer to remain its operator.

That still leaves the harder question of return on investment, which Wu describes as ambiguous and unsolved. Embedding in the customer’s environment makes the candidate work concrete: a backlog of features, remediation tasks, code that never ships, tests nobody writes, or alerts that need triage. Mapping product capabilities to those needs is the first half of the job. Even a satisfied customer does not complete the whole responsibility.

The other half runs in the opposite direction: map customer problems back to the product. Solving an individual deployment moves one side of the product–problem overlap. Improving the product from that experience makes the next deployment easier and more valuable. Customer delivery and product feedback form one loop.

Wu describes field experience as a high-fidelity evaluation set. FDEs encounter the actual repositories, organizational constraints and failure cases that customers face every day. Their responsibility is to translate that context into product decisions, rather than forwarding every request unchanged. Three questions organize the translation:

• Scope: Is this a recurring enterprise challenge or a need specific to one user?
• Product potential: Should a workaround, hack or bug encountered during deployment lead to a supported feature?
• Roadmap value: Would addressing it reduce uncertainty about what to build and why a customer would pay for it?

The purpose is to reduce roadmap risk by connecting engineering priorities to observed customer needs and revenue opportunities.

This feedback is not an administrative step after delivery. It is what allows a successful deployment to improve the product for subsequent customers. An FDE bridges both directions: applying what exists today, then helping determine what should exist next.

That two-way responsibility explains why the FDE role is difficult to classify as sales engineering, solutions architecture or conventional software engineering. Cognition looks for a T-shaped skill profile: breadth across people, business, process, customers and technology, with a deep specialty that makes the person particularly useful in the field.

The deep specialty need not be identical for every hire:

• Product judgment: Someone from product management may understand how features fit together and what makes a coherent product. In Wu’s view, falling implementation costs make deciding what to build more important.
• Technical expertise: Founders and software engineers may bring substantial depth in a technology domain. Wu is willing to hire people whose business skills are still developing because becoming the technical expert in the room while already deployed is harder to teach on the job.

The shared requirement is enough breadth to operate with a customer, plus depth that contributes something difficult to replace.

Good deployed engineers can solve a customer problem and connect it to the roadmap. Wu distinguishes great ones by their curiosity about why the work matters. They ask whether the problem is important to the business and whether its lessons can improve the product for other customers. That curiosity sits alongside a second commitment: staying closely connected to the customer. Making customers successful is both the immediate deployment objective and the basis for a durable enterprise partnership.

Wu describes an earlier period of agent deployment in which token usage itself could serve as a KPI. Subsidized budgets made experimentation cheap, and running more work could look like progress. The next phase, which he calls intelligent orchestration, is accountable for measurable delivery. Large, regulated enterprises want to know whether the system produces value, not simply whether it is busy.

The distinction also changes the unit of improvement. Making one engineer faster is valuable, but it does not automatically accelerate an organization that includes both technical and nontechnical staff. Wu uses a tenfold improvement at each level as a challenge, not as an established organization-wide result. His criticism of isolated CLI and IDE tools is that they do not, on their own, coordinate the wider work needed to achieve that organizational change. The proof therefore has to move beyond individual tool activity.

Cognition calls an agent run, with its associated trace or trajectory, a session. Session metrics are used to estimate generated engineering hours and the portion considered productive. Wu reports that one three-month customer engagement generated capacity equivalent to more than 150 additional engineers. This is an inferred capacity equivalent, not a claim that the customer hired that many people.

An engineering-hours estimate can still resemble token maximization if it only repackages activity. Wu explicitly raises that objection before moving to delivery time. Wu reports approximately 82% shorter delivery timelines in an anonymized before-and-after deployment example. He describes looking at the customer’s existing project, ticket and sprint measures before Devin and after it is deployed and fully activated. The numerical claim is an 82% reduction; the accompanying order-of-magnitude language should not be treated as an equivalent calculation.

The third dimension is shipped output. Wu reports almost twice as many PRs in an anonymized comparison with engineers using point tools before Devin. This asks whether the additional activity becomes engineering artifacts, rather than merely more sessions.

These three proof points answer different questions:

Wu presents them as three anonymized case-study results, not one universal effect. The talk does not supply the calculation methods, sample sizes or causal controls needed to turn them into a general productivity estimate.

Migration work makes the enterprise problem concrete. Wu introduces Nubank as a public customer example involving an ETL migration. Wu recalls a Nubank migration staffed by 50 engineers finishing in roughly one-third of the timeline with Devin. He describes Devin’s contribution as autonomous, though he does not break down human prompting, supervision or review. The staffing and timeline figures remain his approximate recollection.

The next example concerns a separate large Latin American bank migrating a tax identification system. Wu reports completing the bank’s tax identification migration with roughly half the engineering effort. He connects the work to legacy environments such as COBOL and JCL, where expertise can be difficult to find. The displayed case-study slide includes an Itaú sign and describes COBOL migration outcomes; it is separate from the preceding Nubank example.

The relevance of these cases is not simply that an agent can generate an unfamiliar language. Enterprise deployment has to work inside complicated existing codebases and produce a migration that matters to the business. These are precisely the environments that the earlier greenfield prompting ideal leaves out.

Bilt supplies a different kind of example: ongoing engineering output rather than a bounded bank migration. Wu invokes an order-of-magnitude improvement while discussing merges and PR acceptance at Bilt, but does not define its baseline or denominator. That wording does not establish a precise acceptance-rate increase.

Wu reports weekly output at Bilt equivalent to the work of more than ten engineers. This is a separate capacity claim, not another way to express PR acceptance. He emphasizes the strength of Bilt’s existing engineers when making the comparison: the intended value is to extend a capable team’s output.

The operating model depends on commitments that extend beyond embedding engineers and collecting feedback. Cognition applies its internal values to customer engagements as well. A successful deployment gives the people introducing Devin inside their organization visible results they can stand behind, turning them into internal champions.

Sometimes that commitment means physical proximity. Wu describes placing someone in Brazil for about two months to live near a customer and help the deployment succeed. Proximity is paired with a concern for correctness: engineering practices that need attention should be raised and brought back to product, without ego preventing the team from addressing them.

That makes the boundary between sales, post-sales and engineering less important than the shared responsibility for the customer’s outcome. Everyone contributes to bringing the product successfully into the market. Wu closes on urgency: the work sits at the intersection of difficult customer problems and software change at scale, and every second counts. The role is to keep that work moving—from a concrete customer need, through delivery, and back into a better product.