The same job title is appearing right now at the most visible players in AI. They deploy engineers as close as possible to the client, in contact with their field rather than away from their context.
The term, from English, is "forward deployed engineer". Behind the label, a deeper movement is at play. This role doesn't reappear by chance: it signals a shift in where software value lies.
A role reappearing at the AI giants
Several major AI players are highlighting the same profile. Palantir made it a signature. OpenAI, AWS and Microsoft followed, each in its own way.
The idea fits in one sentence. An experienced software engineer works directly with the client's teams, in their real environment, to turn a business problem into a tool that works.
They don't advise from a distance. They don't code in a bubble. They build in contact with the field: the business lines, the users, the data, the systems already in place and the security constraints.
When software development drifted away from the business
To understand this return, we have to look at where we come from. For two decades, software production was organized like a factory, away from real-world use.
The logic was industrial, and it had its reasons. Everything was specified in a requirements document, then the build was handed to a team that saw neither the business nor the users.
Code was expensive to produce. The rational reflex was to build it at the best cost, at scale. The distance that mattered wasn't geographic, it was the remove from reality.
What AI really shifts
Generative AI has changed a simple but decisive fact. Writing code is no longer the hardest part. A good deal of it is generated, assembled and fixed quickly.
Scarcity has switched sides. What remains hard is understanding a real business problem, then integrating it into an environment that's far from ideal.
That's where the real work lies: scattered data, a living information system, security rules, users with their habits. A demo isn't a production system.
This shifts the engineer. If value plays out in the client's reality, that's where they must stand. The movement reverses, not out of nostalgia, but out of necessity.
As close as possible to the client: what it demands
Working as close as possible to the client isn't a matter of miles. You can be remote and still stay in direct touch with their reality, provided you ask the right questions and talk to the right people.
It's first a way of running the project, in short cycles, as close as possible to the decision.
You start from an intuition, frame it, quickly get a concrete result, evaluate it, adjust. The tool gets sharper as you watch it work, without a long theoretical detour.
This closeness calls for a step-by-step climb. First you clarify the real need. Then you test a first version on a controlled scope. Finally you harden what deserves to hold up in production.
Each step settles a question: should you continue, correct or stop? The field makes this decision possible, because it's made on something concrete, not on a promise.
An out-of-touch engineer isn't a field engineer
The role is best understood by what it isn't. It isn't an order-taker executing a frozen requirements document, never questioning the context.
Nor is it a consultant who stops at recommendations, nor an isolated developer who accepts generated code without mastering it.
The common thread of these postures isn't physical distance, it's detachment from reality. You can stay out of touch in the same offices as the client, or very close at the other end of a line.
The field engineer, on the other hand, stays responsible for the overall coherence: the need, the architecture, the code, the security, the adoption and the move to production. They work with real complexity instead of ignoring it.
What an executive can take from it
For an executive, this movement offers a useful selection criterion. The right question is no longer only "can this team produce", but "can it work within my reality".
A partner close to the field is judged by concrete signs. It understands your business, works with your systems, surfaces risks early and has you decide on tangible results.
One last point matters, often overlooked. Good field work strengthens your control instead of creating dependency. Code delivered, choices explained, know-how passed on: you must be able to take back the reins.
So the return of the engineer to the client's side is neither a fad nor a mere anglicism. It's a sign that value has changed place.
It no longer lies in the ability to produce code, which has become abundant. It lies in the ability to turn a problem into a system that holds up, at your company, over time.
So before choosing who supports you, look less at the advertised speed than at true closeness: closeness to the business and its uses, not closeness on a map. That's often where what comes next is decided.