AI model makers are becoming implementation companies.
Microsoft committed $2.5 billion and 6,000 people to embedded AI engineering. Amazon committed $1 billion two days before that. Anthropic, OpenAI, Accenture, EY, all racing to build the same thing.
The job title they're all hiring for is "Forward Deployed Engineer." The pitch is that FDEs are scarce, specialized, and worth a premium.
I've been running an embedded engineering company for over a decade. I have some thoughts on what they're selling and what it takes to deliver it.
The FDE concept isn't new. Palantir built the playbook in government contracting years ago. What's new is the scale.
Microsoft's Frontier Company tagline is "No Pilots. Scale from Day One." That sounds great in a press release. In practice, it means 6,000 people rotating through enterprise clients who are each at a completely different stage of AI readiness.
The rotation cycle prevents context from accumulating. Your FDE learns your system for three months, gets reassigned, and the next one starts from scratch. That's consulting with better branding.
Here are five things I've learned running this model for a decade that $9 billion in new FDE ventures will eventually learn the hard way.
Lesson 1: The FDE is not a rare species
The industry is pricing FDEs as if they're a rare natural resource.
They're not. An FDE is a full-stack developer who was curious enough to think in product terms, not code. Someone who understands why a feature matters to the business, not how to implement it.
Someone who asks "what problem are we solving" before asking "what framework should I use."
Those people exist in most engineering orgs. The gap is that most companies don't have a system for developing them.
That system is culture, and culture is the unsexy part nobody wants to talk about.
Lesson 2: Culture looks like a factory floor, not a tech campus
At Limestone Digital, teams meet at 8 AM. It's expected, not optional. They review what happened yesterday with actual numbers. They plan what they'll do today with specific deliverables. They surface blockers before those blockers become surprises for the client.
This doesn't happen once a week in a retro. It happens daily. The conversation is constant, iterative, and sometimes uncomfortable.
It means pushing people to a standard they didn't set for themselves. Having the same conversation about quality and ownership three days in a row if that's what it takes.
The purpose is client outcomes, not engineer happiness.
Avocado-and-matcha team perks don't produce FDEs. The daily operational grind does, and that grind is the part of embedded engineering that no press release from Microsoft or Amazon will ever mention.
Lesson 3: "Hire only the best" does not scale
I spent years trying the Silicon Valley approach. Hire only the best. Find the self-starters. Look for people who will perform on their own without management. You can hire people like that, and when you find them, hold onto them.
But if your model depends on only finding A-players who need zero direction, you will not scale. You will sit around waiting for unicorn candidates while your clients wait for deliverables. We tried it. It didn't work. The clients don't leave because you lack A-players. They leave because the work isn't getting done.
What works is building a culture that takes a competent, curious full-stack developer and turns them into someone who thinks like a product owner, communicates like a consultant, and ships like an engineer who knows their client's business.
That takes daily operational pressure applied consistently over months. Stand-ups with metrics. Code reviews with context. Conversations about business impact, not ticket closure. The boring, repetitive, unglamorous work of directing people toward the right standard, again and again.
Not many people have the skill or the desire to do this systematically. That's the real scarcity in the FDE market. Not the engineers. The operational culture that produces them reliably.
Lesson 4: Context doesn't survive rotation
This is what makes the $9 billion FDE wave interesting to watch. Microsoft, Amazon, Anthropic, and OpenAI are all betting they can build this at scale. But embedded engineering isn't a product you deploy. It's a culture you maintain. And culture doesn't survive rotation.
When your FDE cycles through a client every quarter, the context walks out the door with them. No amount of capital fixes that.
An embedded Frontier Company engineer co-designing your AI systems isn't engineering help. That's Microsoft's architecture being installed as your infrastructure. Customers should understand that before their next renewal, not after.
Lesson 5: The economics break if you only hire on-site
If you're only hiring FDEs on-site and in-office, you've narrowed your hiring pool to a fraction of the available talent. You're going to pay unsustainable rates.
Your clients are going to absorb those rates. And eventually the economics break because the premium you're charging for the FDE title doesn't match the cost of finding, retaining, and rotating people through enterprise engagements in expensive markets.
We do this differently. We take competent developers, embed them in client teams long-term, and build the operational culture around them that turns them into the product-thinking, context-accumulating engineers that everyone else is trying to hire pre-made.
Our clients' teams get the same treatment. We don't only embed our engineers. We transfer the operating system so clients can develop their own FDEs from their existing people.
The FDE market is real. The problem it solves, making AI work inside existing businesses, is the biggest engineering challenge of the next decade.
But the companies that win this market won't be the ones that spend the most on hiring. They'll be the ones that build the culture to develop embedded engineers faster than anyone can recruit them.
And that culture looks less like Silicon Valley and more like a factory floor where the same operational standards get enforced before anyone's had their coffee.
If you want to ship AI-native and need engineers who accumulate context instead of rotating through, book a discovery call by clicking here.
Top comments (1)
This is a really interesting perspective. I agree that the real challenge with FDEs isn’t simply finding talented engineer, it’s creating an environment where engineers develop strong product thinking, business context, and ownership over time. The point about context being lost through constant rotation is especially important. Long-term embedded relationships seem much more valuable when the goal is to deeply understand the client’s systems and business rather than just deliver short-term solutions.