The Engineer Who Ships to Production on Day 9
Here’s a number that should bother you: 95%.
That’s the share of enterprise AI projects that MIT found generate zero measurable return. Not “underperformed.” Not “produced mixed results.” Zero. Nothing on the P&L. After billions invested, hundreds of pilots run, and enough PowerPoint decks to circle the earth twice.
And here’s the part that stings: it’s not the models. The models work. GPT-4, Claude, Gemini, all of them perform well in controlled tests. The failure happens after the demo. In the messy, stitched-together, legacy-encrusted reality of how large organizations actually function.
That gap, between “impressive in a sandbox” and “working in production,” is where most enterprise AI goes to quietly die.
The Forward Deployed Engineer exists to close that gap. And right now, it’s the fastest-growing role in tech.
What Is an FDE, Actually?
The term comes from the military. Forward deployed units were stationed close to the front line, not sitting back at headquarters making strategic decisions. The point was speed and proximity: intelligence plus execution, co-located.
Palantir operationalized this for software in 2006. Instead of selling a platform and wishing clients luck, they embedded engineers directly inside the client’s environment. Engineers who could write code and understand the business simultaneously. Not consultants handing down recommendations. Not contractors following a spec. Builders with context.
Fast forward to 2025-2026, and every serious AI company is hiring them. OpenAI. Anthropic. Google. Databricks. Accenture launched a dedicated FDE practice with Microsoft in March 2026. Job postings grew 800% between January and September 2025. Salaries are pushing $200K, some reports say $265K.
That kind of growth doesn’t happen for a job title. It happens when the market discovers a structural problem and races toward the only solution that actually works.
Why the Old Playbook Broke
For twenty years, enterprise software worked roughly like this: vendor builds product, enterprise buys product, systems integrator bends enterprise to fit product. Sometimes an internal team does the bending. Either way, the product is the fixed point and the business is what adapts.
SaaS made this faster and cheaper but didn’t change the fundamental dynamic. You still ended up configuring your workflows to match what the software could do, not the other way around.
AI breaks this model completely.
The reason is that AI doesn’t have a fixed behavior. It has to learn your business logic, your data structures, your edge cases, your exceptions, your institutional quirks. A language model that hasn’t been grounded in how your procurement team actually categorizes commodities, or how your customer support tier-2 escalation actually works, is just a very expensive autocomplete.
And you can’t spec this upfront. The requirements only become visible through contact with the real system.
This is exactly the insight the FDE model is built on.
Here’s how the Forks, compared to what came before:
The “95% Failure” Problem, Decoded
MIT’s finding that 95% of AI projects get zero return sounds dramatic. It is. But it’s also entirely predictable once you understand where the failure actually occurs.
The research identified three root causes: brittle workflows, lack of contextual learning, and misalignment with day-to-day operations.
None of these are model problems. Every single one is an integration problem.
Brittle workflows break because AI was bolted onto a process that nobody fully mapped, including the people doing it. The exceptions, the workarounds, the “we always handle that case differently,” the unwritten rules that exist in the heads of three people who’ve been there for twelve years: none of that is in the training data or the system prompt.
Contextual learning fails because most deployments treat AI as a static system. You configure it, you deploy it, and it stays configured. Real enterprise workflows change. Data distributions shift. Regulatory requirements update. The AI needs someone close enough to catch these drifts and adjust, not a support ticket queue.
Misalignment with operations happens because whoever specified the AI system and whoever does the actual work are rarely the same people. The spec was written based on how the work is supposed to happen. The AI runs against how it actually happens.
An FDE fixes all three by being in the room. Not in the room after the project starts struggling. In the room from day one, watching real work happen, building against reality rather than documentation.
What an FDE Actually Is (and Is Not)
The honest confusion around the role is understandable. It sounds like a consultant who codes. Or a solutions engineer with more autonomy. Or an embedded contractor with a better job title.
It’s none of these, and the distinction matters.
A consultant produces analysis and recommendations. They leave behind a document. An FDE produces a working system. They leave behind deployed software.
A solutions engineer configures what exists. An FDE builds what doesn’t exist yet.
A contractor follows a spec. An FDE helps write the spec by discovering, in real time, what the actual problem is.
The Invisible Technologies paper captures it well: in the traditional SaaS model, vendors bent businesses to fit the software. FDEs bend software to fit the business. That inversion is the whole thing.
The Charlotte Hornets case is a good illustration. When the NBA draft was approaching, the Hornets needed better player analytics from game film. A traditional engagement would have started with months of requirements gathering, followed by a procurement process, followed by a build, followed by a testing phase. By which point the draft would be over.
Instead, FDEs embedded, used reusable computer vision components, understood what “athletically valuable” meant in the context of how the team actually evaluated players, and delivered a working system in nine days. Nine days. The Hornets called it a level of draft analytics nobody had seen before.
That’s not a consulting outcome. That’s a shipping outcome.
My Read: This Is the Last Mile, Finally Getting Solved
I’ve been building data and AI systems for over two decades now. I’ve sat on both sides of this problem, as the person architecting the system and as the person explaining to stakeholders why the demo worked and production didn’t.
The gap between those two states is real, it’s structural, and it’s been underserved for years.
The FDE model is essentially an acknowledgment of something practitioners have known for a long time: enterprise AI is not a software problem. It’s a systems integration problem with a software component. The people who succeed at it are the ones who can hold the business logic and the technical implementation in their heads simultaneously, and iterate between them quickly.
What’s changed is that AI has made this gap visible at scale. When every enterprise is trying to deploy AI at the same time, and the failure rate is 95%, the question of “why isn’t this working” becomes hard to avoid.
The answer isn’t better models. The answer is better last-mile deployment. And FDEs are, right now, the most direct solution to that.
Here’s what the FDE engagement model looks like as a workflow:
When Not to Use FDEs (The Honest Version)
Every model has a fit problem, and FDE is no exception. The Invisible Technologies paper lists five scenarios where forward deployment is the wrong call, and they’re worth being honest about.
If your systems are standard, API-ready, and well-documented, you don’t need embedded engineers. A well-configured off-the-shelf tool will do it cheaper.
If your organization can’t maintain what gets built after the FDEs leave, you’re creating dependency, not capability. The FDE leaves behind a working system. If your team can’t operate and extend it, that system becomes shelfware.
If the problem isn’t mission-critical or the contract value doesn’t justify the engagement model, the economics break. FDEs are a high-touch, high-cost intervention. They make sense for high-value problems.
And this is the one I’d add from experience: if your organization hasn’t actually decided what it wants AI to do, no amount of technical proximity will save you. FDEs need a problem to solve. “We want to do AI” is not a problem.
The Bigger Pattern
Here’s what I think this role actually signals.
For the last decade, the software industry sold enterprise AI as a product. Buy the platform. Get the models. Transform your business.
What the 95% failure rate is telling us is that AI is not a product in the traditional sense. It’s infrastructure that requires deep integration with the specific, idiosyncratic reality of how each organization actually works. And that integration requires humans who understand both the technology and the business, who can operate in the gap between them, who can build and iterate quickly without a bureaucratic handoff chain in the middle.
That’s an architectural observation, not a role description.
The FDE role is popular because it solves a real structural problem. But the underlying problem, the gap between AI capability and AI deployment, isn’t solved just by hiring more FDEs. It’s solved when organizations build the internal competency to do what FDEs do: understand their own workflows deeply enough to integrate AI into them intelligently.
FDEs accelerate that. They can’t replace it.
The enterprises that figure this out early, that use the FDE engagement to genuinely transfer knowledge rather than just get a system built, are the ones that will compound. The ones that treat FDEs as a magic outsourcing solution will find themselves dependent on them indefinitely.
The bottleneck in enterprise AI was never the model. It was always the last mile.
And the last mile has always been the hardest part of any infrastructure problem.
buymeacoffee.com/HardikGoel