AWS and OpenAI Are Betting Over $5 Billion on a 1950s Job Title

By Olivia Hart

AWS announced a $1 billion investment on June 30 in a new unit built around a single role: the Forward Deployed Engineer. OpenAI had already committed more than $4 billion to its own Deployment Company in May. That is over $5 billion in roughly two months for a job title Palantir popularized — and one whose core idea dates back to IBM mainframes in the 1950s.

The scale of the spending deserves scrutiny. A forward deployed engineer is an engineer embedded directly in a customer's environment to design, build and ship AI or custom software. Palantir draws the line neatly: a regular engineer builds "one capability, many customers." An FDE delivers "one customer, many capabilities."

That model is not new, whatever the press releases imply. In the 1950s and 60s, IBM sent systems engineers to sit with customers alongside its mainframes, writing code and configuring machines — included in the hardware price until IBM began charging separately in the late 60s. Consultants and implementation teams later did the same inside client organizations. The theory, as the source puts it, is "as old as computers themselves."

Why is the money arriving now?

The answer lies in how enterprise software gets built. The old model ran like a client-vendor relationship: business teams handed requirements to IT, which took six months, sometimes a year, with large teams across development, integration, testing and training.

Much got lost in translation. What the business wrote and what IT understood rarely matched, and that gap surfaced in testing — the most expensive place to find it. Because IT built and ran the system, the business never owned it; every change went back into the queue.

AI-assisted coding, or "vibe coding," collapses that timeline. A business user can now assemble a first working version of an app in days. It will not be production-ready, but it is real enough to show what they mean instead of describing it in a document. Trying an idea costs a few days, not a quarter — so processes can be reimagined while being built.

The catch: that first-version app lacks connections to other teams' data, fails security review and does not scale. Someone must convert what the business wants into something the enterprise can actually run. Building is no longer the hard part; integration, speed and accountability are. That gap is what the FDE spending is really buying.

What does the role actually require?

A true FDE is an engineer first. They write production code, work inside the customer's data and systems, and ship. As the source bluntly notes: someone who writes a strategy deck under a new title is a consultant.

The demands are specific:

• Engineering depth: SQL, cloud, Python, and real experience putting LLMs and agents into production, plus governance, security and compliance knowledge.
• Functional knowledge: OpenAI's healthcare FDE posting 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." Clinical credentials are not required.
• Discovery and judgment: The author reports FDEs spend roughly 60-70% of their time with the customer — scoping problems with no spec and explaining trade-offs in business terms. That figure is one practitioner's experience, not audited data.
• Outcome ownership: The premium roles tie pay to customer outcomes, not tickets closed. The IBM-era question was "Did we deploy the system successfully?" The new one is "Did it create measurable value?"

The teams stay lean: two or three engineers, a business function expert, someone accountable for data and the platform, and a business owner who holds the metric.

Shadow IT with better branding?

This is the question the source says CIOs ask most: what stops a small, fast team from becoming shadow IT with a trendy name? The prescribed guardrails:

• Build in the customer's environment, on governed data, under existing access controls.
• Bring security and compliance in during discovery, not at go-live — settle data classification, residency and audit evidence before anyone writes code.
• Design audit trails from day one: what went in, what came out, why.
• Decide upfront which actions an agent takes autonomously and which need human approval.
• Treat evaluations as evidence, with clear pass/fail criteria.
• Have a human review AI-generated code before it ships.
• Leave documentation and a team that can run the system, so it does not depend on the FDE staying.

The author's own firm, Polestar Analytics, says it follows this model, embedding marketers inside industry teams — a self-interested claim readers should weigh accordingly.

The takeaway in plain words: billions are flowing into a decades-old engineering model because AI made prototyping cheap and integration expensive. Whether the FDE label produces value or just repackaged consulting will show up in one metric — measurable customer outcomes, not deployments.