Why the Forward Deployed Engineer role needs to be understood now
Contents
The two-minute version of this article. Also on YouTube.
I'm responsible for delivery on software projects for industrial clients. Over the past few months, the same question has moved to the front of almost every conversation. It's no longer whether AI is arriving in software development, but what it means for cost, teams and how companies work with their partners.
I see this regardless of how a given industry is doing. Clients in the supplier industry are under heavy pressure, other sectors are doing well. The expectation is the same everywhere: software engineering should get cheaper. It isn't always said out loud, but it's there in every budget round and every tender.
The expectation meets an existing model #
Many companies have scaled their software development with external service providers for years. That's a deliberate choice: buy capacity flexibly, bring in specialist knowledge, keep internal teams lean.
Those same providers now find themselves in a new position. They are expected to explain how agentic software development works. What changes when coding agents take over a large part of the implementation? Where does the effect really show up, and where only in the demo? What happens to quality, traceability and accountability, especially in regulated environments?
No slide deck answers these questions. They can only be answered by someone who masters the technology and gets it running inside the client's own systems.
From Senior Software Engineer to Forward Deployed Engineer #
The term Forward Deployed Engineer originally comes from Palantir and is now used mostly by AI vendors. It describes an engineer who doesn't sit behind a ticket system but with the client. They understand the business problem, build the solution themselves and stay with it until it holds up in production.
For a technically focused Senior Software Engineer, this is an extension, not a break. Engineering craft stays at the core. What gets added is consulting: listening, working out the actual problem, explaining options, preparing decisions, and talking to business units and management as an equal.
The Senior Software Engineer role won't disappear. There will still be a need for people who are deep inside a system and keep it in good shape. But those who understand what's shifting right now, and grow towards the FDE role, can create value that used to be out of reach for a software engineer.
What an FDE changes in a transformation #
When a company moves its software development to agentic ways of working, the technology is rarely the hardest part. The harder questions are around it: How do roles in the team change? What processes and quality gates are needed so that faster doesn't mean worse? What does it mean for contracts with partners who have billed by effort until now?
This is where an FDE makes a difference. They show on the client's real code what an agent can do and where it fails. They build the first workflow that works day to day and turn it into a standard internal teams can adopt. That way they don't just shape a project, they shape the direction a company takes. That's entrepreneurial impact, and here it comes from someone who writes code.
An opportunity on three sides #
For software engineers it's a real career opportunity. The way up used to run mostly through architecture or management. Now there's a third path that stays technical and still sits close to the business.
For consultancies and IT service providers it opens up a portfolio that is less contested than pure delivery capacity. When agents make implementation cheaper, the value of hours drops. The value of people who can guide a client safely through this change goes up.
For smaller digital agencies and software firms it's a way to meet the demands of large industries without having to scale through near- or offshoring. A small team of experienced engineers working with agents can deliver results today that used to take a large crew.
Why now #
The expectation of cheaper software development is already here. Answering it only with discounts on day rates is a losing game. Answering it with people who can explain agentic development, demonstrate it and anchor it in the organization makes you part of the solution.
That's why the role is worth understanding now. For engineers thinking about their next step. For service providers rethinking what they offer. And for clients who don't just want cheaper code, but a change that lasts.
I've written about how I structure agentic delivery myself in One Person, a Whole Team.