When AI writes code at scale, FDEs are paid to own the outcome

The FDE listing for Agentforce and Data Cloud that Salesforce posted in mid-June 2026 contains an unusual detail. The FDE must be accountable for the quality of deliverables, whether the code was generated by a colleague using an AI tool or written by the FDE themselves.

For this employer, what matters is no longer who typed the code but who answers for it.

This is not confined to one company. The CEO of Infosys has said his teams have generated more than 28 million lines of code with AI. When code is produced in those quantities, the ability to type it is no longer scarce, and anyone who wants to be an FDE has to answer a very practical question: what reason is left to hire you?

Read the job listings from Salesforce and Anthropic, then listen to OpenAI’s head of FDE, and the answers look much alike. An FDE’s value now lies in owning outcomes, in the parts of a project that do not belong to the model, and in helping customers run their systems themselves.

If you have two to eight years of experience, those are the things your CV needs to prove. Commit counts say nothing about them.

Cheaper code makes the accountable engineer more expensive

Salesforce describes the senior FDE as the most senior technical authority in the room with the customer, responsible for holding deliverables to the highest technical standard.

Immediately afterwards, the listing adds two short sentences: technical depth is required, and architectural judgment is expected. Read alongside the requirement to own even AI-generated code, they suggest that technical depth is now needed to vet code written by other people or by machines, not just to write your own.

10Clouds separates FDEs from platform engineers by exactly this criterion. FDEs write code on the customer’s systems, often on site, and they are accountable for the outcome of the deployment. AI does not blur that accountability. If anything, when AI generates code faster than humans can read it, the accountability grows heavier.

Consider a scenario. An AI tool finishes a connector from an agent to the customer’s CRM in 20 minutes, and every test passes.

But the connector pulls every data field into the agent’s context, including end customers’ phone numbers and personal notes. The model will not catch this on its own.

The person who catches it has to be the FDE in the room.

The model is only a small part of the problem

Colin Jarvis, head of forward deployed engineering at OpenAI, estimates that model capability accounts for only “about 20% or less” of the gap between a demo and a system running in production. In his view, the rest is a matter of organisation, data, access and evaluation. This comes from the person running the FDE team at a lab that builds models.

Try applying the figure to a hypothetical project stuck for 10 weeks. This is only a rough illustration: Jarvis was talking about shares of the deployment gap, not offering any way to divide up time.

Translated loosely into time, the model’s share is at most about two weeks, while the other eight go on requesting data access, waiting for security sign-off, cleaning dirty tables and building an eval suite the customer trusts.

AI coding tools shorten the coding step. Most of the time sits in those other eight weeks.

Anthropic’s listing for an Applied AI FDE makes this plain. FDEs work inside the customer’s systems to bring applications to production on Claude. What they deliver are MCP servers, sub-agents and agent skills.

Each of those carries decisions about organisation and permissions. An MCP server decides which tools and data an agent is allowed to touch. So the access question Jarvis raises does not stay in meeting minutes: it becomes concrete lines of configuration in the server you hand over.

You can ask AI to write the body of an MCP server. What AI cannot do for you is decide what the server opens, what it closes, and what evidence shows the agent is behaving correctly. That is the work you have to defend in front of the customer.

Is the FDE just a temporary patch?

The most serious counter-argument comes from Larry Dignan of Constellation Research: FDEs exist because products are still immature. The argument has merit. If platforms could handle data, permissions and evals themselves, the person in the middle would be less necessary.

OpenAI itself does not want FDEs to become a permanent crutch. Jarvis is explicit: “We don’t want to create a dependency on FDEs.” Anthropic stresses a different point: FDEs must carry what they learn in the field back to the Product and Engineering teams, so that experience from each customer flows back into a better product.

Dignan’s critique may therefore hold for only one kind of FDE: the one who is valuable because the customer cannot do without them. That kind of FDE will lose their place as products mature. The other kind leaves capability behind with the customer, and each deployment makes the product better.

That kind still has work at the next customer, on a harder problem. Gergely Orosz of The Pragmatic Engineer notes that demand for the role is very strong at Google, OpenAI and Anthropic.

What developers need to prove

The first step is to fix your CV. A line such as “developed 15 APIs” now carries little weight, because AI can do that too. Write in terms of accountability: what you owned in a production deployment, what risks you blocked in AI-generated code, and what the customer could run on their own after you left.

When reading a job description, look for phrases such as “owns the outcome”, “architectural judgment”, “customer systems” and “MCP servers”. They tell you whether the company is hiring someone to be accountable or simply needs another pair of hands to write code.

Before an interview, prepare a true story about a time you rejected AI-written code: where it was wrong, how you found the problem, and what would have happened had you let it through.

For practice, a worthwhile personal project is building an MCP server for a messy internal system. Pair it with a page setting out the access scope, a small eval suite, and a runbook good enough for a colleague to run it without you. The project exercises all three things Jarvis mentions: data, access and evaluation.

Finally, there is the non-technical side 10Clouds sets out: product intuition and composure in front of customers. If you work in outsourcing and regularly meet overseas clients, you already have a place to build both. Practise saying “no” to a request, with a technical reason, in a way that keeps the customer’s trust.

When a single company has had machines write more than 28 million lines of code, employers will ask less about what you can write. They want to know which code you are willing to answer for.