Forward Deployed Engineering spent most of its life as a slightly strange corner of the technology industry. Palantir had FDEs. A few companies borrowed the model. Most engineers could go through an entire career without ever needing to know what the acronym meant.

That changed quickly in 2026. Anthropic has committed $100 million to training 10,000 Frontier Deployed Engineers by the end of 2027. AWS has put $1 billion behind a dedicated FDE organisation designed to embed thousands of engineers directly with customers. OpenAI has created an entire Deployment Company, backed by more than $4 billion of initial investment, and agreed to acquire Tomoro to bring roughly 150 experienced FDEs and deployment specialists into it from day one. Google is building FDE capability through its enormous partner network, putting its own engineers alongside systems integrators and supporting the wider ecosystem with a $750 million agentic AI fund.

The hiring market is moving with them. Research shared with TechCrunch this summer found that the proportion of companies planning to hire FDEs had risen from roughly 5–10% at the beginning of 2026 to 70% by the end of the second quarter. Pave, one of the larger compensation-data platforms, has now gone from tracking FDE as an emerging role to giving it its own compensation benchmark. Whatever happens to the terminology over the next few years, forward deployment has moved well beyond being an interesting Palantir artefact.

If you’re already an FDE, that creates an unusually good market around you. If you’re a software engineer, applied AI engineer, solutions engineer or technical founder thinking about moving into the work, it creates an unusually good moment to do it. The useful question going into 2027 isn’t how quickly you can get FDE onto your CV. It’s how you position yourself to take advantage of what the role is becoming.

Don’t optimise for the title

The easiest mistake to make in a fast-growing profession is to chase the label. That is particularly risky with FDE because the title still covers a huge range of work. One company may expect you to spend most of your week writing production software beside a customer. Another might want technical discovery, prototyping and product feedback. Another could have something much closer to solutions engineering or implementation under the same title.

None of those jobs is automatically better than the others. They will simply develop different skills. If you’re trying to build an FDE career, look for the underlying work rather than the wording on the job description.

You want opportunities where the problem isn’t completely specified before it reaches you, where you are close enough to users to understand what is actually happening, and where you have enough technical ownership to do something about what you discover. You want to see what happens after the demo, when the system meets real data, real processes and people who don’t behave the way the requirements document said they would.

For someone moving into FDE, that work may already be available inside your current company. Volunteer for the difficult customer implementation. Take the project nobody has managed to define properly. Spend time with users rather than waiting for requirements to arrive. Follow a feature through deployment instead of stopping when the pull request merges.

You don’t have to wait for somebody to change your title before you start becoming good at the job.

Get closer to the problem

One of the most interesting things about the current FDE boom is that it is happening while AI is making software dramatically easier to produce. If an engineer can use Claude Code, Codex and increasingly capable agents to build far more quickly, you might expect companies to need fewer engineers sitting close to customers. Instead, some of the companies building those tools are investing heavily in putting more engineers into the field.

The explanation is probably that faster execution changes the bottleneck. When implementation takes three months, engineering capacity determines how many ideas you can try. When the same work takes three weeks, you can try far more of them. Suddenly the expensive decision is not whether you can build something, but whether the thing you are about to build is worth building in the first place.

That is good territory for an FDE. A capable model can help you write the integration. It cannot walk into an organisation for the first time and immediately understand why one apparently simple workflow exists across six systems, why three teams disagree about what the data means, or why the person buying the software and the person expected to use it want completely different things.

The more AI compresses implementation, the more valuable it becomes to understand those things early. Going into 2027, use AI aggressively. Become excellent with the tools, let them take as much of the mechanical work as they reliably can, then use the time you get back to move closer to the customer, the data and the actual problem.

That’s a much better use of the leverage than simply producing twice as much code.

Build technical depth that survives the tools

There is a version of the FDE story where technical ability becomes less important because AI writes more of the software. I wouldn’t bet on it.

The nature of the technical bar is changing, but the bar itself still matters enormously. Anthropic’s FDE residency is aimed at hands-on software engineers with strong fundamentals. AWS talks about a production engineering bar rather than simply a training badge. Across the market, the work still involves integrations, data, architecture, security, evaluations, production systems and everything that happens when an elegant prototype meets an enterprise environment.

AI makes it easier to produce an answer. Technical depth helps you know whether the answer is any good.

That distinction becomes more important when code is being generated quickly. You need to understand enough about architecture, data, APIs, security and system behaviour to know when the tool has produced something plausible but wrong, or something technically correct that will become painful six months later.

The strongest position is not to compete with the model at typing code. It is to become the person who can give the model much more room to run because you know how to judge what comes back.

That is real leverage.

Find a domain worth learning properly

There is another shift that should become more obvious as the FDE market grows. When there are relatively few people capable of deploying frontier AI, being a strong generalist is enough to make you unusual. Once thousands more engineers have experience working with models, agents and enterprise deployments, domain knowledge becomes a much stronger differentiator.

Healthcare is not financial services. Defence is not retail. Manufacturing is not insurance. The technical stack may overlap, but the processes, incentives, regulatory constraints, procurement cycles, data and definitions of failure can be completely different.

An FDE who has spent two years working inside a sector starts seeing things another engineer does not. They know which integrations are normally painful before opening the architecture diagram. They know which stakeholder needs to be involved before the project reaches security review. They recognise when a seemingly strange customer requirement is actually a consequence of regulation rather than bad product design.

That knowledge compounds with technical ability rather than replacing it. You don’t need to decide that you are going to spend the next twenty years as the world’s leading insurance FDE, but there is a lot to be said for choosing work that teaches you something difficult about a real industry.

By 2027, being good at AI deployment will be increasingly valuable. Being good at AI deployment somewhere other people find difficult will be even more so.

Get repetitions in production

There is only so much of forward deployment you can learn from courses, frameworks and reading about other people’s projects. Eventually something needs to break.

A project you expected to take two weeks takes six. The customer changes the requirement halfway through. A model behaves differently against real data. An evaluation you thought was sensible turns out to measure the wrong thing. Security kills your first architecture. The workflow technically works and the users still don’t want it.

That is where a lot of FDE judgement comes from. The useful part is not failure for its own sake; it is seeing enough deployments that apparently unique problems start revealing familiar shapes. The second time you see adoption falling away after a pilot, you ask different questions. The third time a data problem presents itself as an application problem, you look upstream earlier.

Anthropic’s approach to training FDEs is interesting for exactly this reason. Its programme starts with instruction and simulation, but engineers then spend twelve weeks leading an actual Claude deployment inside their own organisation. The credential comes after the work rather than instead of it.

If you’re choosing your next role, optimise for repetitions. Find somewhere you can take real systems through the whole cycle, from an uncertain problem to something people actually use.

Five difficult deployments will teach you things fifty prototypes won’t.

Choose an environment where the learning compounds

The company you join matters almost as much as the role.

The best FDE environments don’t treat every customer engagement as an isolated project. Something should come back from the field. A recurring integration gets easier. A missing capability becomes part of the product. An evaluation framework becomes reusable. A deployment pattern becomes tooling. The fifty-first customer should benefit from what happened with the first fifty.

AWS is unusually explicit about this in its partner-led FDE model. Each engagement is intended to contribute to a reusable delivery harness containing domain knowledge, evaluation frameworks, MCP servers, agent operations tooling and architectural context that the partner can use on subsequent deployments. The FDE does the immediate work for the customer, but the organisation retains what was learnt.

That compounding loop is worth looking for when you’re evaluating an opportunity. Ask what happens when an FDE discovers something important. Does anybody in product hear about it? Can the engineer change the underlying product themselves? Does a clever workaround become permanent technical debt, or does somebody turn it into a reusable capability?

Two jobs can have almost identical descriptions and produce very different careers. One gives you a sequence of projects. The other gives you a body of knowledge that keeps becoming more valuable.

Decide what you want to become unusually good at

As FDE grows, the profession should become broader rather than narrower. More companies will adopt the model, more engineers will move into the work and more formal training paths will appear. That is good news if you’re entering the field now because there are going to be many more ways in.

It also means the interesting differences will move underneath the title.

An FDE who understands regulated healthcare systems deeply is different from an FDE who can take agentic workflows into production at enormous scale. Someone exceptional at evaluations has a different advantage from somebody who understands enterprise data integration or knows how to navigate defence environments. Another FDE might become unusually good at recognising when a customer’s supposedly bespoke requirement is actually the beginning of a product.

You don’t have to know your version on day one. But after a few years, “I’m an FDE” should probably be the beginning of the description rather than the end of it.

The current market gives you room to work that out. The profession is young enough that many of its specialisms haven’t been named yet, but large enough that the opportunities to develop them are already appearing.

That’s a pretty unusual place to build a career.

Ride the part of the wave that compounds

Nobody knows exactly where the FDE market settles. The title may broaden. Some of the work will become easier as models improve. Some things that currently require specialist deployment teams will become self-service, while entirely new problems appear further up the stack.

You don’t need a perfect prediction to take advantage of what is happening now.

Demand is rising. Compensation platforms are recognising the role as a distinct job family. Anthropic is building a pipeline for 10,000 new FDEs. AWS, Google and OpenAI are putting serious capital and organisational weight behind forward deployment. The market is creating more opportunities for people who can combine engineering ability with judgement, ownership and a willingness to work inside problems before they are neat.

If you’re already doing the work, this is a good moment to go deeper. If you’re an engineer looking towards FDE, this is a good moment to start collecting the experiences that will get you there. And if you’re early enough in your career that you’re still deciding what kind of engineer you want to become, there are not many roles offering this much exposure to both the technology and the problems it is supposed to solve.

The FDE wave is already moving into 2027. The opportunity isn’t simply to get onto it while the market is hot. It’s to use this period to build the technical depth, customer judgement, domain knowledge and production experience that become more valuable as the market gets bigger.

That is how you stay on it.

Sources

• Anthropic — Claude Frontier Academy: $100M to train 10,000 engineers, 2 October 2026.
  Anthropic source
• OpenAI — OpenAI launches the OpenAI Deployment Company, 11 May 2026.
  OpenAI source
• AWS — Introducing Forward Deployed Engineering for Partners: Winning the Future of Enterprise AI, 30 June 2026.
  AWS source
• Google Cloud — Building the Agentic Enterprise with Google Cloud partners and a $750M innovation fund, April 2026.
  Google Cloud source
• TechCrunch — Forward-deployed engineers are the AI industry’s latest talent obsession, 30 July 2026.
  TechCrunch source
• Pave — Forward Deployed Engineering: From Watchlist to Benchmark, 6 August 2026.
  Pave source