How far can the FDE go?

My view: the function is durable, the title probably isn't, and the content of the work is going to churn faster than most people in the role expect.

The compression argument is real — it's just aimed at the wrong part of the job

If Forward Deployed Engineer means "writes the custom integration code that the product doesn't ship yet," then yes, that's the most compressible layer in the whole job, and agents are eating it right now. Palantir's FDEs spent a decade doing work that Foundry eventually productized. Every platform does this. The pipeline you hand-build this year becomes a config screen next year.

But that was never where the difficulty was. The hard part of what I did with the RFP pipeline wasn't the code. It was knowing which person actually routes prioritization, which one is the real dependency for the source data, and which one has to verify product matching before anybody trusts the output. None of that is written down anywhere. It's not in a wiki, a schema, or a Confluence page, and a model pointed at the company's data lake does not recover it — because it doesn't exist in the data. It exists in rooms. Somebody has to sit in those rooms.

The shape shifts: less "engineer," more "forward deployed"

What replaces the code-writing is roughly three things: deciding what's worth building, specifying it precisely enough that an agent can execute it, and designing the verification that tells you it's actually right.

That last one is the most undervalued thing in the job right now. Whoever can answer "how do we know the extraction was correct?" with something better than vibes holds more leverage than whoever wrote the extractor.

The counterintuitive part: headcount probably goes up

Better agents make each deployment cheaper, which makes marginal deployments economical that weren't before. Jevons applies to integration work. I'd expect more of these roles over the next five years, not fewer — the same way automation created SRE rather than eliminating ops.

What actually protects the role is capability churn

If model capabilities froze today, three years of standardization would compress this whole thing into a template and a certification course. They're not freezing. Every six months the question "what is now possible in your specific business" reopens, and that question gets answered locally or not at all.

Your job security is the derivative, not the level.

The uncomfortable part

Here's what I think is the real risk, and it isn't obsolescence. The durable half of FDE value is often the least portable half.

"Can configure Bedrock knowledge bases and resolve OpenSearch permission gaps" is portable and decaying. "Understands how this company's RFP process actually works, well enough to judge what's safely automatable" is compounding and non-portable. Optimize purely for the durable thing and you become very valuable at exactly one company.

The escape is generalizing the method. The reusable asset isn't the pipeline I built — it's my model of how to find the seam between business language and system data in any org. Writing that down as a transferable playbook is worth more to a career than the next integration.

What would change my mind

If within a few years you could point an agent at a company's Slack, Drive, and ERP and have it reconstruct the actual operating process — including the informal parts — then a large share of this compresses fast. I don't think that's absurd.

But even in that world, the last mile is accountability. When the agent misprices a bid, an org chart needs a name next to the failure, and models don't take responsibility. That's not a technical limitation that gets solved. It's what organizations are for.

Bet on the title dying, not the work.