Tech Giants Are Putting Billions Behind a Decades-Old Engineering Model. Here’s Why It Matters More Now.

Opinions expressed by Entrepreneur contributors are their own. Key Takeaways The FDE model isn’t new. Vibe coding lets business users build a working first version in days, so the hard part now is turning that into something secure, scalable and connected to real enterprise data. FDEs write production code, spend roughly 60-70% of their time with customers and need functional knowledge of how a business area works. The shift is from “Did we deploy it successfully?” to “Did it create measurable value?” Successful FDE teams build within existing security, compliance and data controls from the start, while ensuring solutions are documented, auditable and maintainable by the customer. If you’ve followed tech news this summer, you’ve almost certainly come across the term Forward Deployed Engineer or, in short, FDE. On June 30, AWS announced a massive $1 billion investment in a new unit built around this one role. OpenAI had already put more than $4 billion behind its own Deployment Company in May. There’s no end to the news on FDE. All of this for just one role. So, who are they? A forward deployed engineer is an engineer embedded directly in a customer’s environment to design, build and ship AI or custom software solutions. Palantir, which made the title popular, describes the difference well. A regular engineer builds “one capability, many customers.” An FDE delivers “one customer, many capabilities.” But the model itself isn’t new. Companies have put engineers close to customers for decades. In the 1950s and 60s, IBM sent systems engineers to sit with customers alongside its mainframes, writing code and configuring the machine — all of it included in the price of the hardware until IBM started charging for it separately at the end of the 60s. Later, consultants embedded themselves inside client organizations, and implementation teams worked side by side with business users. So, why does it matter so much more now? Because the way enterprise software gets built has changed, and the FDE is the role that fits the new way of building. How projects used to work and how they work now Across years, the best way to describe the business and IT relationship was like a client and vendor. Business teams gave the requirement. IT took that requirement and took six months, sometimes a year, with large teams across development, integration, testing and training for a project. A lot got lost along the way. What the business wrote and what IT understood were rarely the same thing, and that gap only showed up in testing, the most expensive place to find it. And because IT built it and IT ran it, the business never really owned it. Every small change went back into the queue. This is the gap between a solution being “deployed” and being “valuable.” But now, with AI-assisted coding, or vibe coding, a business user can put together a first working version of an app in days. It won’t be production-ready, but it’s real enough to show what they mean instead of describing it in a document. That changes the order of things. The process doesn’t have to be frozen before you automate it. You can reimagine the process while you build, because trying an idea now costs a few days, not a quarter. But this first-version app lacks the practical connect to the data or the information that another team has. It doesn’t pass a security review. It doesn’t scale. Someone has to take what the business already knows it wants and turn it into something the enterprise can actually run. So, the hard part is no longer just building the technology. It is getting technology, data, workflows and people to work together in a way that changes an outcome. That too, quickly. That requires a different form of accountability. This is where the FDE comes in. What a true FDE team looks like A true FDE is an engineer first. They write production code, they work inside the customer’s data and systems, and they ship. Someone who writes a strategy deck under a new title is a consultant. Here’s what the role actually asks for: Engineering depth or technical depth: SQL, cloud, Python and real experience putting LLMs and agents into production. They need to understand the ins and outs of governance, security and compliance. Functional knowledge: Doesn’t mean you need doctors to work in pharma and life sciences projects. For example, OpenAI’s healthcare FDE role asks for experience with payer workflows, provider operations, EHR systems or standards like HL7 and FHIR, and the ability to “translate payer, provider or health-system workflows into technical requirements and measurable outcomes.” The same posting says clinical credentials are not required. So functional knowledge here means three things. Knowing how work actually moves through the function: who approves what, where the handoffs are, where it breaks. Knowing the systems and data that function runs on. And knowing the rules it operates under. An FDE in healthcare billing needs different context from one in supply chain. What they don’t need is to be the subject matter expert. They need to sit with one and ask the right questions. Discovery and judgment: As per my experience with FDEs, they’re spending roughly 60%-70% of their time with the customer. They need to scope problems that come with no spec and explain technical trade-offs in business terms. Outcome ownership: The roles that pay a premium are tied to customer outcomes, not tickets closed. Let’s go back to the IBM systems engineer era. The outcome there was “Did we deploy the system successfully?” and that’s it. Now it has changed to “Did the system create measurable value?” — essentially owning the business outcome. And the team is lean. Inside an enterprise, the way we’d staff it is two or three engineers, someone from the business who knows the function inside out, someone accountable for data and the platform, and a business owner who holds the metric. Staying inside the guardrails This is the question I get most from CIOs. If a small team is building fast with the business, what stops it from becoming shadow IT with better branding? A true FDE team works inside enterprise standards, not around them: Build in the customer’s environment, on governed data, under the existing access controls. Bring security and compliance in during discovery, not at go-live. Settle data classification, residency and the audit evidence your industry expects before anyone writes code. Design audit trails in from day one: what went in, what came out and why. Decide upfront which actions an agent can take on its own and which need a human to approve. Treat evaluations as evidence. Test cases with clear pass and fail criteria show an auditor the system stays within agreed boundaries. Have a human review AI-generated code before it ships. Leave behind documentation and a team that can run it, so the system doesn’t depend on the FDE staying. This is the governance you already have, applied while you build instead of after. For us at Polestar Analytics, this is not just what we preach but what we follow. We have forward deployed marketers in industry teams, for example, who get visibility into what the need of the hour is, right where the need is. And many more. Simply put, the FDE title might be new, but the theory is as old as computers themselves. What’s changed is that the engineer now sits with the business, builds with the business and owns the outcome with the business.