What the FDE Role Taught Me About Being an Engineer in the AI Era
Translated from the original Korean post. 한국어 원문 보기 →
I recently ran across a job title I hadn't seen before: FDE (Forward Deployed Engineer).
The name was new to me. The job description wasn't.
An FDE figures out what the customer's actual problem is, picks the technology to solve it, wires it into whatever systems already exist, and gets it running in production or in someone's daily workflow.
It sits somewhere between developer, architect, and consultant.
What I find interesting is why AI companies in particular seem to care so much about this role.
Adopting AI doesn't solve the problem
When a company brings in new technology, the technology itself is rarely the hard part.
AI is no exception.
Dropping in a good LLM does not improve anyone's job on its own.
A real enterprise already has systems, data, APIs, auth, security policies, networks, and business processes in place.
So the work is connecting:
AI → data → existing systems → business process → users
That's why something that demoed beautifully in a PoC falls apart once it hits a real environment.
Knowing one technology deeply and making it actually work across five other systems are different skills.
Implementing a requirement isn't the same as solving a problem
Early in your career, the question is how to build what you've been asked to build.
After enough years, the question shifts.
Less "how should I build this API?" and more "why does this API need to exist?"
Less "should we adopt Kubernetes?" and more "does this org actually need Kubernetes?"
Less "where should we apply AI?" and more "what judgment call is a human repeating over and over right now?"
Defining the problem starts to matter more than implementing it.
That's the core of the FDE role.
You're not building the feature the customer asked for. You're finding the problem underneath the ask, deciding how to solve it, and shipping the solution yourself.
Between business language and technical language
People on the business side don't hand you problems in technical form.
"This takes way too long."
"Someone has to check it manually every time."
"When it breaks, we have no idea where."
You have to translate.
Is it a process problem? A data model problem? An API problem? An observability problem? An infrastructure problem?
The translation chain looks like this:
Business Problem → System Problem → Technical Solution → Working System
Owning that whole chain is what makes FDE different from a typical dev role.
As AI gets better, there may be more of this work, not less
Generative AI is driving the cost of implementation down fast.
You can build a prototype with a fraction of the people it used to take, and pick up an unfamiliar stack quickly enough to ship with it.
So does the engineer's value disappear?
I think it moves.
The cheaper how to build gets, the more what to build and why to build it are worth.
Deciding what should exist. Combining the right technologies. Connecting them to what's already running. Getting all of it to a state you can actually operate.
The better AI gets at writing code, the more visible the gap in that kind of judgment becomes.
One level above the tech stack
Deep knowledge of Java, Python, Kubernetes, cloud, LLMs — still valuable.
But as the pace of change picks up, knowing a particular technology buys you less runway than it used to.
Some skills survive the churn better.
Structuring a problem and turning it into a system is one of them.
Understanding what's actually wrong.
Choosing the technologies.
Designing the boundaries between them.
Getting it into a real environment.
I think the attention FDE is getting right now is a symptom of that shift.
Not every developer needs to become one. Deep specialists are still necessary, and will be.
But if AI takes over much of the implementation, the engineer who can connect several technologies to a messy real-world problem probably gains more than the one who's great with a single tool.
The title was unfamiliar. The job wasn't.
This doesn't look like a new role appearing so much as an old one — the engineer who solves problems rather than fills tickets — finally getting a name in the AI era.
Was this post helpful?
One click helps me write the next one