Open a tech job board in late 2026 and the title is suddenly everywhere: Forward Deployed Engineer. Venture capital firm a16z called it “the hottest job in startups”, OpenAI and Anthropic are staffing FDE teams, and Google is hiring hundreds of them to embed AI into Fortune 500 workflows. Labor-market analysts tracked FDE postings growing by more than 1,000% year-over-year heading into this year.

I read all of this with curiosity. The job description matches work I have been doing for years, long before the term existed and without a single label on any contract. My project experience started in 2000. So when the market invents a name for my day job and pays a premium for it, is this really a new beginning after 26 years?

What a forward deployed engineer actually is

The role was invented at Palantir in the early 2010s, where forward deployed engineers were called “Deltas.” Until around 2016, Palantir employed more FDEs than regular software engineers. Their own formulation of the split is still the cleanest definition I know: a Dev works on one capability, many customers, a Delta on one customer, many capabilities (Palantir: Dev versus Delta). And Palantir’s job ads add the line that made me smile: FDE responsibilities “look similar to those of a startup CTO: you’ll work in small teams and own end-to-end execution of high-stakes projects.”

The Pragmatic Engineer’s deep dive describes the modern role as a mix of software, sales and platform engineering: FDEs embed with customer teams, write production code in the customer’s environment, help close and expand accounts, and feed what they learn back into the core product. Marty Cagan frames it from the product side: Palantir applied the product model to custom solutions. Instead of a consultancy building whatever a spec says, empowered engineers embed deeply enough to discover and deliver the outcome.

The distinction that matters most, and that I have lived my whole career: a consultant makes recommendations; a forward deployed engineer owns outcomes. It is the difference between leaving one-off slides behind and staying until the thing runs in production on Monday morning.

Alexandria: being an FDE before there was a name

My own case study predates the term’s crossover into the mainstream entirely. For Aktiv Software I built a product called Alexandria, a customizable data pipeline that synchronizes heterogeneous systems without needing a dedicated master-data system in the middle. No “big bang” central platform, no years-long migration program. Alexandria meets each system where it is and keeps the whole picture coherent while the details stay messy. If you have ever worked around real enterprise IT, you know that is the only kind of realism that ever ships.

Then came the part the term describes: taking Alexandria out of the demo world and into Securitas, first as a test integration, then inside the production system. It was a small team, XP-style, and the constraints were real: legacy interfaces nobody fully documents, data models that need reverse-engineering just to be understood, plus security requirements that rule out half of what you could attempt in a greenfield sandbox. That work leans on almost every line of my profile: development in SOA and EAI environments (that is exactly what system-to-system sync without a master-data hub is), reverse engineering, and full stack development from Apache Camel and Spring Boot services up to React front ends, with Kafka and the streaming stack for the data plumbing and Docker Swarm underneath all of it. At that scale a swarm is the sane answer.

Run Palantir’s own checklist back over that engagement and every box gets ticked. One customer, many capabilities: integration engineering, reverse engineering, data modelling, deployment, operations support. Whatever Securitas’s reality demanded that week was mine, because in a team of three nobody was going to hand it to someone else. Production code went into the customer’s environment, meaning their Debian and Windows Server estate, their operations team and an uptime bar they set, rather than a sandbox I control. The ownership was startup-CTO style: end-to-end responsibility, high trust, no escalation ladder above me.

Then there is the loop Marty Cagan says separates this role from contract work. What I learned inside Securitas did not stay inside Securitas. Every undocumented interface and awkward data model became another customization knob in Alexandria, because a pipeline designed to meet systems where they are learns from every system it actually meets. Each deployment taught the product something, and those lessons made the following deployments cheaper. That is forward deployed engineering as Palantir defined it, performed inside a security company long before the term was searchable on a job board.

Looking back through my project list, the pattern is obvious now even though we never named it then. Take the small-team, high-trust engagements that ran end to end: B. Braun with teams of one and two, GLS as front-end technical lead, Gascade maintaining a power-industry supplier’s application, the Beiersdorf migrations, and the Alexandria work at Securitas. The label arrived late; the modus operandi didn’t.

Why this role is made for a senior full stack engineer

I will put this plainly because the hiring data backs it up: forward deployed engineering is the natural destination for a highly capable, very experienced senior full stack engineer. It rewards what enterprise roles tend to grind out of you.

• Ambiguity is the job. OpenAI describes FDE work as happening in “often undefined or evolving problem spaces.” Twenty-six years of being handed a broken situation and no spec turns out to be the core qualification, which feels like poetic justice from here.
• Breadth beats framework-of-the-month. An FDE picks the tool per context: C# where the shop lives on Microsoft, Java/Spring when the existing systems demand it, something like Go or TypeScript for the glue. Jake Van Clief puts it nicely in a recent video: the same “calculator” gets a different engineering opinion depending on whether NASA or just another company is asking. That opinion was earned by seeing many stacks in production rather than in tutorials. It is not something AI can conjure up, and job postings are increasingly paying for it.
• Discovery is now a listed skill. The same 2026 analysis of FDE job posts found the fastest-growing requirement category is customer discovery: stakeholder management and translating ambiguous business problems. Seniors for whom “talking to the warehouse team” was simply Tuesday have a twenty-year head start on people who learned discovery from a bootcamp slide.
• You own end-to-end. You carry the work from architecture sketch to running production code, with the review gate where judgment matters and autonomy everywhere else. That is the setup under which experience compounds fastest. This very website’s pipeline works the same way: I write a task file and my AI agent runs the factory while I keep the review gate.

The factory: my own CI/CD on refurbished ThinkCentres

An FDE is only as fast as their delivery loop, so I stopped renting mine and built my own. My home setup is a small private cloud of refurbished Lenovo ThinkCentre office PCs with the RAM maxed out, running a Docker Swarm that delivers everything I build. The source and review layer is Gogs, a lightweight self-hosted Git forge (think GitHub in a shoebox), while GoCD, ThoughtWorks’ open-source CI/CD server, drives pipelines from commit to container image to deployed service. Twenty-plus years of testing and test development is what makes those pipelines worth trusting: the suite standing between “it compiles” and “it ships” is the same discipline I bring to a customer’s production gate.

The choice of small, boring hardware is deliberate. It teaches the same lessons the field does: no autoscaling safety net, real resource contention, real network partitions when a node reboots. And the machines carry their weight. Every node is maxed out with RAM (four of them 16 GB, one with 32 GB, one with 64 GB), 160 GB of memory in total across the swarm, each box on its own terabyte-class SSD. That fleet runs 24/7, idling most of the day and spiking when GoCD does. At my local utility’s rate here in Arnstadt, around-the-clock operation works out to roughly €20 of electricity a month, about a quarter of my office power bill, which also carries my workstation and my music studio. Rent the same amount of RAM from Hetzner at their post-2026 cloud prices and you are paying several hundred euros every month; I pay double-digit cents.

Maxing out RAM in cheap office machines turns them into surprisingly serious swarm nodes. The scheduler places workloads across the cluster, services heal themselves, and my pipelines run against the same Docker primitives that customers run in production. The whole factory is reproducible and mine. There are no vendor seats to wait for and no license between an idea at 22:00 and a tested deployment before breakfast.

My AI Ingo wrote up the deeper version of this from the Interpretable Context Methodology paper: configure the factory, not the product. An FDE’s value was never typing speed anyway. It is having a pipeline (CI/CD for code, folders and contracts for agents) that turns each new customer problem into a configuration change instead of a cold start.

What AI changed on the demand side

The hiring surge behind all this has a concrete cause: AI models work; AI deployments stall. MIT’s NANDA initiative found in its State of AI in Business report that 95% of enterprise generative-AI pilots showed no measurable business impact. The model is no longer the problem. What stalls is integration into messy, real-world customer systems, which is by definition forward deployed work.

OpenAI is building an FDE organization around phases I recognize from my own engagements: scoping onsite, validation with evals, then delivery. Anthropic, Google and a long tail of vertical AI startups are hiring the same shape of engineer. Kevin Bai, technical staff on Anthropic’s applied AI team and founding member of Rippling’s FDE function, gave a talk literally titled Forward Deployed Engineering 101 that frames the whole function as “development partnership”, scaled from how early startups work to how big enterprises buy.

The 2026 hiring-trend analyses even show the title fragmenting into variants like “Forward Deployed AI Engineer”, “Applied AI Engineer” and “Deployment Solutions Engineer”. Mostly that means employers are rediscovering, under new names, that deployment talent is scarce. It has spread past the labs entirely: a speaker on the AI Engineer channel describes the first forward-deployed engineers in the history of 10 Downing Street, embedding with policy advisers and lawyers. This role can now be found everywhere.

For a freelance senior, the interesting consequence is economic rather than technical. In his October 2026 breakdown of why consultancies live and which ones die, Jake Van Clief argues that AI collapses the billable-hours economics of both advice shops and build shops. What survives is assurance: judgment and owned outcomes, because you cannot blame a model in front of a board. That is the market pricing exactly what independents like me have always sold, one accountable engineer who shows up with the whole loop.

What AI changed on the craft side

AI is everywhere now, and almost everyone I talk to has wired it into their day. What matters to me is what it has quietly done to the craft itself. If AI writes most of the code, what is actually left in the hands of a forward deployed engineer?

To answer it you have to remember how recently the work looked completely different. Back in the mid-2010s, when Palantir’s Delta model was at its peak, a forward deployed engineer opened a customer’s undocumented interface and took it apart by hand. Packet captures and hex dumps, a WSDL nobody had touched since it shipped. Then you wrote the glue yourself in whatever language that shop ran, stood up a harness, and iterated with the people who would use it. Two things capped how far you got: how much of a foreign system one head could hold at once, and how fast you could type correct code into it.

The tools took the typing away. In Software Engineering Is Becoming Plan and Review, Louis Knight-Webb describes his own day rearranging around that fact: hours once spent writing moved almost entirely into planning the change and reading back what the agent produced. His rule of thumb, five minutes up front to save half an hour unpicking generated code later.

The task that used to define this job shows the shift best. Boris Starkov from Eleven Labs needed to drive an old Viking phone whose only software ran on Windows XP. Three senior engineers with ChatGPT had failed, and the handset sat on a shelf for a year. He pointed Agentic AI at the line behind a logging proxy, let it capture the traffic and work out the checksum, and rebuilt a protocol that has no public documentation in a couple of days (his AI Engineer talk walks through it). Reverse engineering is one of the lines on my profile, and I did it manually for years. Watching that compress to a weekend reframes what an engagement can absorb.

I should be straight about the cost, because the hype gets this wrong. None of it is free speed. A METR randomized trial set experienced developers loose on their own mature repositories, code they had tended for years, and found them 19% slower when AI was allowed. They were certain they had been faster. The drag appeared exactly where forward deployed work lives: dense systems full of unstated rules. The speedup lands on work you were never holding in your head to begin with.

So the center of the craft moved, and it did not move away from us. Simon Willison has a line I keep returning to: quitting programming over LLMs is like quitting carpentry because somebody invented the table saw. A saw does not decide what to build or vouch for the finished piece. Neither does a model. And the work slid from authoring the integration to directing it, then deciding whether it earns its place in production, which is the ground a forward deployed engineer has always stood on.

So: a new beginning?

No. And that is the good news. A new beginning would mean starting from zero, and after twenty-six years nothing on my bench is at zero; it all compounds. What actually happened is better than a restart. The market finally named what I do and priced it correctly, then handed me tooling that multiplies exactly the judgment my career was built on.

The Alexandria story (build a real product and get it running inside somebody else’s production reality) was hard to sell when you needed seven words and a shrug to explain it. Now it has a job title, and customers hiring for that title are looking for one thing: someone who has already done it before.

I have been doing it since 2000, across telecommunications, logistics, medical technology, fintech, insurance, mobility and the power industry. Most recently that has meant Unsloth, Qwen and OpenCode in the tool bag, with a Docker Swarm full of refurbished ThinkCentres behind me. If your organization has an AI pilot that works in the demo and stalls everywhere else, or two systems that “cannot” be synchronized without a three-year platform program, drop me a line. Forward deployed is what I do — now officially.