From software engineer to FDE: production code only gets you through the door

Anthropic’s job posting for a Forward Deployed Engineer in Applied AI contains a line that can give even strong engineers pause. The requirement is not about how many years you have written Python. It asks for 4+ years of experience in a technical, customer-facing role, such as the FDE role itself.

That line captures the paradox of moving into FDE work. The hardest skill software engineers spend years developing, writing code that runs in production, is something recruiters take for granted. Paraform, a recruiting platform, says it plainly: technical skill is the floor, not the criterion on which candidates are ranked.

For a developer with 2-8 years of experience who is aiming for an FDE role, this is both good news and bad. The good news is that you already have half the skill set. The bad news is that the other half does not arrive by writing more code, because the way your work is currently organised is designed to keep you away from it.

The half you have is bigger than you think

Start with the advantage. The Palantir-style FDE model is often summed up like this: write production-quality code, but do it from inside the customer. The first part of that is already your trade.

Paraform lists five core skills: a backend language, cloud infrastructure, data engineering, applied AI and customer communication. The first three are a backend engineer’s daily work. Anthropic’s posting likewise describes the job as building production applications with Claude models inside customers’ systems.

An FDE playbook published on Data Conversationalist describes the FDE as someone who knows what to build, why it matters to the business, and how to deploy and scale it in production. The third part is where experienced engineers have a clear edge over people who are merely good at talking to customers. Understanding the customer is one thing. Making a system run reliably in their real environment is another.

So where is the gap?

Software engineers usually fall short on the first two parts: what to build, and why. Not because they are weak, but because they have never had to do it. The playbook’s author argues that the traditional engineering career does not demand these skills, because the back office shields engineers from business problems.

Futurense looks at the same phenomenon from a different angle: in most organisations, software engineers rarely work directly with customers, and feedback usually arrives through support or a PM. By the time a ticket reaches you, someone has already restated the user’s problem as a requirement, so you only receive the mediated version.

An FDE has to do that restating themselves, and listening to users directly is not easy. The playbook notes that employees rarely volunteer their undocumented workflows, or the exceptions they still handle by hand, unless asked. To find out, you have to know how to ask, and be trusted enough that they will tell you.

Imagine you are sent to a logistics company to build an agent that processes documents. The spec says “read invoices, enter them into the ERP”. It may take until your third session sitting with the accounting team to learn that one major customer always sends invoices as two separate files, and that the team lead stitches them together by hand every week, a detail the spec never mentions.

Breadth over depth, and a new layer of AI

The next gap lies in the nature of the work. Futurense describes the FDE’s technical scope as broad, whereas software engineers typically focus on perfecting a single component. A specialist engineer is used to asking “how do I make this module as good as possible”. An FDE has to ask “what does the customer need running next week, and which part of the system is blocking it”.

Newer still is applied AI. Anthropic asks for experience taking LLMs to production, including advanced prompt engineering and agent development. This is the most concrete gap but also the easiest to close, because it is still technical: you can teach yourself, build it yourself and measure it yourself.

What remains is working style. Anthropic’s posting emphasises high agency and the ability to navigate ambiguity in complex organisations. Paraform observes that engineers who have done hackathons, worked at early-stage startups or carried an on-call pager tend to adapt fastest.

These three environments share one trait: nobody hands you a complete spec, and mistakes have real consequences.

Aspect	What software engineers are used to	What is expected of an FDE	How to close the gap from your current role
Production code	Backend, cloud, data: an existing advantage	Write production code inside the customer’s systems	Keep it sharp; this is the floor for getting through interviews
Scope	Go deep, perfect one component	Range across many parts of the system	Take end-to-end work that spans several layers of the stack
Customers	Feedback arrives via support or a PM	Listen directly, build trust yourself	Ask to join requirements-clarification sessions
Business domain	Shielded by the back office	Uncover undocumented workflows and exceptions	Spend time sitting beside end users
Applied AI	Often has not taken LLMs to production	Advanced prompt engineering, agent development	A small project with real users and real measurement
Ambiguity	Specs are provided	Take initiative in complex organisations	Join the on-call rota, enter hackathons

Don’t wait to be assigned to customers

The notable detail in the table is that only one row, applied AI, can be closed mainly by learning more technology. Every other row is experience, and experience has to be built in a real working environment. That is why moving into FDE work cannot be packaged into a single course.

Anthropic’s 4-year requirement suggests career changers will struggle to walk straight into that role. But read the wording closely: they count experience in a technical, customer-facing role, and FDE is only one example.

The practical route, then, is to build this kind of experience in your current job, and then call it by its proper name when you apply.

If you work at a services or outsourcing company, ask to join the requirements-clarification calls rather than just receiving tickets afterwards. If you work on a product, ask to sit with support for a session or to be added to the on-call rota. Each time you uncover a hidden requirement the spec missed, write it down.

Those notes become material for your CV. A line such as “implemented feature X” only proves you meet the floor. A line describing which exception you uncovered, through which conversation, and what happened after deployment shows the skills that sit above it.

Return to the hypothetical logistics example. Before: “Built an agent that reads invoices and enters the data into the ERP.” After: “Over three sessions with the accounting team, discovered that one major customer always sends invoices as two separate files; added a file-merging step to the agent before ERP entry, eliminating the team lead’s weekly manual merge.”

Same project, but only the second line shows a recruiter that you have covered all three parts: what to build, why, and making it work.

When reading a job description, look for phrases such as “customer systems”, “ambiguity” and “production experience with LLMs”. They tell you which gaps the role needs you to have already filled with hands-on experience, not just which technologies you need to know.

Production code gets you over the floor. The rest of the job description, from direct customer experience and handling ambiguity to taking LLMs to production, is where you can set yourself apart from other candidates.