Three and a half billion dollars, same week, same idea. Microsoft announced its Frontier Company on July 2 — $2.5 billion, roughly 6,000 engineers embedded inside enterprise customers to build and operate AI systems. Amazon beat them to it by two days: $1 billion committed to a forward-deployed AI engineering organization on June 30. OpenAI and Anthropic had launched similar ventures in May. The whole AI productivity industry converged on the same model at the same time, from different directions.
Forward-deployed engineering is a Palantir invention from the 2000s. The idea is simple and expensive: instead of selling software and hoping customers figure it out, you send your own engineers to live inside the customer's operations, build things in the customer's actual environment, and leave once the system is running and the customer's teams can operate it independently. It works. It's also what you reach for when you've accepted that "deploy our product and measure the results" isn't reliably working.
The convergence in late June and early July is the part worth sitting with.
What the Pilot Failure Rate Is Really Saying
The number Microsoft has been citing internally — and which got attention in coverage of the Frontier Company announcement — is 95%. A joint CIO Research and RAND study found that 95% of enterprise AI pilots deliver zero measurable results. 88% never reach production at all.
The popular explanation is change management: organizations buy tools, skip training, underinvest in process change, and blame AI when outcomes don't materialize. This is partly right. Software that doesn't get used doesn't deliver results. But change management is downstream of a more basic problem.
Before you can change how developers work, you need to know how they currently work. Before you can measure whether AI is helping, you need a baseline for what "helping" looks like in this specific codebase, with these specific developers, on these specific kinds of tasks. Most enterprises don't have that baseline. The tools went in before the instrumentation did.
Forward-deployed engineers spend a significant portion of their early engagement doing something unglamorous: mapping workflows. Which tools are developers actually using, and for how long? Where do coding tasks stop and coordination tasks start? What's the ratio of focus time to context-switching on a given team? What does a productive day look like here, as opposed to an unproductive one? These questions don't have answers that most engineering organizations can pull from a dashboard. They have answers in the form of anecdote, intuition, and post-hoc self-assessment — which is not the same thing.
The First Month Is a Measurement Problem
AWS describes their FDE pods entering customers for 45-day periods, structured to compress deployment timelines from months to days. The first phase of that isn't building. It's figuring out what the environment actually looks like: data architecture, existing workflows, where AI tools are being used versus quietly avoided, what the actual failure modes are in this organization's specific context.
This is not peripheral to the engagement. It's what makes the rest possible. You can't compress a timeline if you don't have an accurate picture of what the current one looks like and why. You can't identify where an AI tool will help without knowing where developer time is currently going.
The measurement layer that FDE engineers construct manually determines the ceiling of the whole engagement. Organizations that had any instrumentation in place before the engineers arrived — time tracking, tool usage data, deployment frequency metrics — get more from the engagement faster. The ones that arrive as black boxes take longer and see less. The FDE team is, in a real sense, being paid to build the observation layer that should have already existed.
The Information That Matters
There's a version of developer time tracking that's been around for decades and mostly used for billing. Hours logged against Jira tickets. Standup status reports. Timesheets. That's not what I'm describing.
The information FDE engineers are extracting is behavioral: where is attention going at the session level, not the project level? Which categories of work are expanding because of AI, which are staying flat, and which are unexpectedly shrinking? Is AI-assisted code spending more time in review than manually written code? Are the developers who use AI tools heavily having more or fewer production incidents than those who use them sparingly?
These are not hard questions to answer if you have the data. They're close to impossible to answer if you're relying on self-report.
The reason Microsoft is paying 6,000 engineers to go ask these questions in person, at customer sites, is that most enterprises don't have data to answer them any other way. The forward-deployed model is, at its core, a response to a data collection problem. Embedding humans is expensive and it works. It's also the method of last resort when other approaches aren't available.
What This Looks Like Without a Six-Figure Engagement
Microsoft Frontier Company and AWS FDE are enterprise products. The minimum viable engagement probably starts somewhere in the low six figures and requires organizational coordination most teams can't sustain. Solo developers and small teams are not the customer.
But the underlying problem exists at every scale. A solo developer building a product doesn't know, without measurement, whether their AI-heavy weeks are more productive than their AI-light ones, or just more active-looking. A small team of five can't tell from intuition whether the PR review bottleneck that appeared over the last six months correlates with AI-generated code, scope creep, or something else. The diagnosis requires data that isn't in anyone's head.
The difference is that a solo developer or a small team can instrument themselves in ways that don't require a 45-day engagement from six AWS engineers. App-level time tracking that captures what tools you're actually using and for how long. Session-level metrics that show where focus time is going on a given day. PR cycle time and post-merge stability tracked over weeks, not reconstructed from memory.
The same information that FDE engineers spend weeks extracting through observation and interview is, in principle, available from tracking data a good developer analytics tool generates continuously. The FDE model is what you reach for when you don't have that layer and need to reconstruct understanding from scratch. It works. It's also a very expensive substitute for having had the data all along.
What the $3.5 Billion Is Actually Funding
Microsoft and Amazon are not spending this money because they think AI tools are bad. They're spending it because the value locked inside their tools is conditional on deployment conditions that their customers rarely satisfy independently. The conditions aren't exotic: understand what your developers are actually doing, build measurement infrastructure that can detect whether things are improving, run change management with that data as the foundation.
These are solvable problems at small scale. At enterprise scale, without any instrumentation in place, they're expensive enough to require an embedded team of experts.
At xeve, we track time at the app, session, and category level because we wanted to close the gap between how developers feel about their productivity and what the data actually shows. We didn't anticipate Microsoft spending $2.5 billion on a labor-intensive version of the same insight. But the July announcement makes the argument clearly: AI tools perform in proportion to how well you understand your own workflow. The forward-deployed engineer is how you get that understanding when you've run out of other options.
There's a cheaper path. It just requires starting before things are already failing.