Skip to content

Writing

  • in fde
  • 5 min read

How do you grow FDEs?

A small swimming pool built from toy bricks, with a red brick at the tip of a diving board over the deep end, and a ladder, a lifebuoy and a lane rope around it

My friend Vinoo Ganesh led Palantir's Frontline programme. It sent new software engineers into the field for their first six months, before they joined a product team. More than 250 engineers went through it. In his guide to forward deployed engineering, he asks how you hire FDEs, with the answer "You don't. You grow them."

I mostly agree. Most companies will need to hire a few experienced people first, but the rest have to be grown. And right now a lot of companies are trying to grow them. Anthropic has committed $100 million to train 10,000 FDEs, and Mistral is hiring a head of FDE learning. In the last two months I've worked on three versions of this myself.

How Palantir did it

So how do you grow one? At Palantir, you were thrown in at the deep end. I never had any onboarding. Funnily enough, I was not actually hired as an FDE, but as a quality engineer. I had studied physics, never done an internship, and didn't know any Java. In my first week as a QE, I was brought in to help make a deployment more stable. I happened to be sitting next to an FDE who was debugging a pipeline written in Python, but he didn't know Python, so I offered to help. Next thing I know, I was in Zurich next to a data scientist, doing FDE things.

Being thrown in early was normal. Palantir hired far more new grads than people from industry. After a three-month first deployment, your second could mean tech leading one, in rooms with the C-suite of a Fortune 500 company. You were given more responsibility than you were comfortable with. That was the training. Whoever staffed you went in like a good scientist, with a hypothesis, and course corrected if it failed.

Why the deep end worked

The deep end only worked because of what surrounded it. Vinoo writes that they learned quickly that throwing engineers into the field wasn't enough, so every Frontliner got a mentor. Every deployment paired an FDE with a strategist. There was a product team to take the weird bricks that FDEs brought back. And there was one hiring manager holding the bar. Learning the product was the easy part. How to operate as an FDE came from the people who mentored you, the culture, and how much autonomy and trust you had.

Most companies trying to grow FDEs today don't have that system. A startup hiring its first FDEs has no strategist to pair them with, and often no product team ready for the weird bricks. Nobody has calibrated a hiring bar. So they can't simply copy the deep end. They need a version that fits them.

Define the training, not just the role

This is the same point I made in "We need FDEs" is not a complete sentence. FDE is an ill-defined role. That's valuable because it makes for an adaptable org, but it means you have to define the role for yourself. The same goes for training. If the role is yours to define, so is the training. A generic course can teach the craft. It can't teach your role.

Here is what that looked like for the three companies I've worked with.

A large IT services firm wanted its people to work as FDEs, in pods of domain experts and engineers. The firm hand-picked the cohort, and the cases came from problems it had already solved. Each pod got a client rather than a specification. The operational users were hidden until someone asked the right question, and the client changed its mind every day. Coaches checked in at noon, and pods defended their work each evening. We scored people as a profile across four areas, not as a single total. There is a review 30 days into real work.

A marketplace of freelance developers wanted to place some of its people with AI platform companies. That called for something else. I sketched a remote programme in pairs, with one deployment simulation running throughout. Teaching would come in only when the scenario needed it. It would end with a call on each person: ready for a paired deployment, ready with conditions, or not ready yet. It was also designed so the marketplace could run later cohorts itself.

A startup I've worked with wanted to onboard engineers onto its own agent platform. My advice there was to keep it simple. Keep the product material. Add a project, run in the pods they'd use with a real client, from scoping through to a demo. They are also adding a murder board. That's a Palantir habit I really liked, where a new hire explains the architecture to someone very senior, who grills them. If the client's IT team asks a question on a call, you shouldn't have to say "I don't know".

What every programme needs

The three look different, but they share a few things. Each starts by choosing people carefully, because a few weeks won't give anyone grit. Each looks like a deployment, with a client who is vague and keeps changing their mind. Each leans on feedback more than lectures. At the services firm, I had told the pods to reuse the data models they already had. On the first morning, both built their own anyway. A short check-in at noon turned them round faster than my masterclass had. And each programme ends in real work, with someone there to nudge people in the right direction.

None of it sticks if the system around people stays the same. I told the services firm's leaders this before we started. A programme can't decide how you assess and promote FDEs, how you shape the teams, or where the bar for reusable work sits. It can't decide how you sell the work either. If you bill clients for FDE hours, you're working against the whole motion.

Helping companies work through this is now a growing part of what I do at Platypus. I help them define what an FDE means for them, and then design the training to match.

"We need FDEs" isn't a complete sentence. Neither is "we need to train them".

If you're designing an FDE programme, I'm happy to compare notes. The Platypus engagements page has more.

  • in physics
  • 11 min read

The Boundaries of Delegation: The Autonomy Gradient, One Year On

In November last year I started an experiment to see whether AI could turn one physicist into a research team. I have written about it as I went, from building GANDALF to the autonomy gradient to a first physics result. Looking back over the year, the biggest change is in how much of the research I hand over, and in what I keep for myself.

The work I delegate has grown in three steps: first a coding milestone, then a parameter scan, and now a whole physics problem. Each step moved the boundary of what I do myself.

A timeline of what I hand over: a coding milestone in November 2025, a parameter scan in spring 2026, a whole problem in October 2026, and perhaps a research agenda next

A year ago: one milestone at a time

When I started, coding agents had just become good enough to write serious code. I asked Claude to rebuild GANDALF, my PhD-era gyrokinetics code, in JAX. It drafted a plan with milestones, and we worked through them one at a time. I didn't read the code. I checked the physics it produced instead, an approach I later wrote up as physics-oracle validation.

At the end of that project I tried to summarise what the AI could and couldn't do as an autonomy gradient. Code implementation sat at about 100% and research direction at about 0%. My summary was that "AI can implement what is specified but cannot determine what to specify." I described the model as a capable undergraduate, and I argued that problem selection, validation and physics taste could not be delegated.

This spring: a parameter scan

By the spring the code was in place, and the brief changed. I would describe a physics goal in a sentence or two. Claude would propose a config, run it on cloud GPUs, analyse the output and show me plots. On most days my side of the conversation was a handful of short messages, often just "go for it". The result was a small paper on the dissipative anomaly. Across a 50× scan in collisionality, the phase-space dissipation rate stays flat to under 1%.

The interventions that mattered were the kind an advisor makes: a missing coupling constant, three weeks spent inside the wrong hypothesis, and a figure that should have been dropped. My conclusion at the time was that the real constraint had become the speed at which I could validate what the AI produced.

Vienna: analytic calculations

In August I went back to the Plasma Kinetics Working Meeting in Vienna for the first time in twelve years, which I wrote about in A week in Vienna. I arrived thinking of AI as a tool for the computational side of physics. I had not considered using it for analytic calculations, and some of the people there were doing exactly that.

One example has stuck with me. It happened in the first week, which I missed, so this is second-hand. A speaker presented a new invariant for one of the sets of equations that many of us work with. In various limits it reduces to invariants that were already known, but nobody had found the general form before. The derivation had been done without any AI.

Two attendees wanted to see whether a model could find it. One used Claude and the other used ChatGPT. The paper was already on arXiv, so they turned web search off. They started by giving the model the known limiting invariants and telling it that the general one was unknown. After a fair amount of back and forth, the model got there following a deliberately ungrammatical prompt:

do a breakthrough

I don't want to read too much into one example. The model was told what kind of answer to look for, which is a big hint. On the other hand, the result was only days old, and the model could not look it up. My guess is that a prompt like that pushes the model towards the tails of what it can produce. Whatever the explanation, it changed how I thought about what these models are for.

Now: a whole problem

The brief has changed again. For my current study I describe the physics problem and leave the method to the model. If it needs code, it writes code.

The study is Study 04 in my research repo. It builds on a recent paper by Chandran, Mallet and Meyrand on the gyrokinetic helicity. The study asks whether conserving that quantity changes how free energy cascades to fine scales in velocity space. It runs as a loop: a series of Claude Opus sessions, each starting fresh, with the repository as the only memory. The brief for the loop includes this paragraph:

Nobody reviews the loop in real time. Three failures matter most: money
spent without anyone noticing, a gate passed on a hopeful reading, and
work lost between sessions.

Most of the design follows from those three. Every gate needs a coded check and a review by an independent AI critic. A launcher caps the GPU budget at 200 A100-hours. The loop stops and waits for me only for a short list of reasons, such as reaching the budget or wanting to change a pre-registered hypothesis. My side of the conversation now happens in a file. The loop writes a question with its options and a recommendation, and I reply with a line starting ANSWER:.

I expected the hard part to be the physics. In fact, the loop used no GPU time at all in its first ten days. It spent them getting the critic to accept that its own gate checks were sound, while I decided how strict those checks needed to be.

Here is one of those exchanges, shortened. "Part (a)" is one piece of the gate-checking code, and F1 to F4 were the critic's latest findings.

Q10. Gate 1 report machinery: the fourth review was refuted inside
your threat model. How should part (a) go on?

[...] Part (a) has now been refuted seven times in total [...]. Each
refutation found fewer and narrower faults, but there is no sign yet
of a review that comes back clean.

Options:
- (a) The loop fixes F1 to F4 with tests and asks the critic again [...]
- (b) The loop fixes F1 to F4 with tests, and you accept part (a) [...]
- (c) Simplify. [...]
- (d) Something else you choose.

Recommendation: (a). [...]

ANSWER: (c), simplify. Strip the gate report code down to what it
must do [...]

By then the critic had rejected this part of the gate code seven times. The loop recommended another round of fixes, and I chose to simplify instead.

The most interesting output so far is a side result. On 12 October I asked Claude to compare an appendix of that paper with GANDALF's equations. It found that the compressive fluctuations in KRMHD are exactly a continuum of passive scalars, one for each parallel phase velocity, and suggested there was an analytic paper in it.

Snapshots from the side paper: a blob in turbulence and three of its phase-velocity slices

A figure from the side paper. A blob is released into decaying turbulence in GANDALF. Panels (a) and (b) show the lowest Hermite moment at the start and after 1.5 eddy times. Panels (c) to (e) show three of its phase-velocity slices at the later time. All three start identical, and each is carried by its own flow.

I decided to let a second loop write that paper, starting on the afternoon of 13 October. By the next morning the draft was 90 pages long, which was far more than the result needed. I asked for it to be restructured around a single message, and by that evening it was down to 39 pages. By then, scripts checked every number, and it had been through two rounds of AI referee reports.

Page thumbnails of the side paper: 90 pages in the first draft and 39 after the restructure

The side paper before and after I asked for the restructure.

I read it the following morning. It was a competent paper and probably publishable, but I didn't find it interesting. My reply (P1 is the paper) was:

I am not going to publish the current P1. So this is reworking it.

For the rework, the loop proposed a sharper hypothesis and simulations to test it. Its literature check found part of that hypothesis in my own 2015 thesis, which I had not expected to have cited back at me. The first production run took 15 hours on a spare MacBook. It then failed one of the validation gates by a small margin: 1.11% of the free energy sat above Hermite moment 24, against a limit of 1%. The loop stopped and asked me what to do, as the rules require. I chose how to proceed, and it carried on.

A practical note on the models. Opus 5.5 at maximum effort is the most capable model I have worked with, and it is noticeably more independent than what I used last year. It also catches more of its own mistakes. The cost is usage. I now run through my Max plan's limit within about an hour of it resetting. A few of the loop's "failed" sessions were me pressing Ctrl-C, because I needed the usage for something else.

Where the boundary sits now

This is the slide on autonomy that I showed in Vienna in August.

The autonomy slide from my Vienna talk

Parts of it already look out of date. This is how I would draw it now.

The same slide redrawn for October 2026

What is left for me is choosing the problem, designing the checks and deciding whether a result is interesting. The model now does a fair amount of what I would have called research direction a year ago. It found the structure in the appendix, suggested it was worth a paper, and proposed the hypothesis for the rework. Where it still falls short is judgement about what matters. It thought the analytic result made a strong paper, and I disagreed.

The hard part is deciding how much to hand over. If I hold on too tightly, I lose most of the benefit. If I let go completely, I stop thinking about the physics myself, and that is how you end up with slop. I don't think there is a stable answer, and I expect this slide to look dated in six months as well.

The wider context

It is hard to write about this without mentioning mathematics, where the same shift is happening at a much larger scale. On 8 September, OpenAI announced that an internal system had produced a proof of finite-time blow-up for the 3D Navier–Stokes equations with a smooth external force. The proof is formalised in Lean. The Clay Institute has not accepted it, and the credit is disputed. On 6 October, OpenAI published full or partial solutions to more than 370 open problems, and withdrew at least three of them within days. Reactions have been mixed. Terence Tao described the release as the end of "Math 1.0", while Dan Litt called it "great for mathematics".

Physics is not far behind. In a new benchmark called TheoPhysEval, the best agent solved 98% of 50 unpublished research-level problems in theoretical physics, at under $3 a problem. The authors also found that accuracy barely changed without web search, which they read as memorisation, and they discuss why agents have not yet produced breakthroughs. Closer to home, Matt Landreman has just posted exact solutions for 3D MHD equilibria with nested flux surfaces, which he presents as counterexamples to Grad's conjecture. His acknowledgements say the solutions were found with GPT-6 Astra Pro, and that he confirmed every equation by hand.

Checking the work

One difference between mathematics and physics matters a lot here. Mathematicians can check many AI-generated proofs in Lean, which is part of why the field can absorb results at this scale. Physics has nothing equivalent in everyday use. Our derivations rely on orderings and approximations, and a proof checker can't yet tell you whether those are physically sound. Lanyon, a new startup, is trying to change that. It is building formally verified software for physics, where code comes with machine-checkable proofs that it does what its specification says. I hope it works.

Until then, our checks are the ones physicists have always used: codes, conservation laws, known limits and derivations by hand. They run in both directions. Landreman offers his exact solutions as test cases for equilibrium codes. My side paper tests its analytic results against GANDALF. The Vienna experiment tested the models themselves, by asking them to rederive a result they could not have seen. Physics-oracle validation was how I learnt to trust code I hadn't read. The same idea now has to stretch to cover analytic work as well.

Beyond physics

I think the question of where to draw this boundary applies well beyond physics. A lot of companies are trying to become "AI native", or "AI-pilled", whatever that means. In practice, that comes down to the decision I have been making all year: which parts of the work to hand over, and which to keep.

Getting it right needs two things that pull in different directions. The first is ambition. I have underestimated these models at every step this year. Each time I handed over a bigger piece of work, the model coped with more of it than I expected. So people have to be ambitious and creative about what might now be possible, and then try it. The second is restraint: handing over the work without handing over the thinking. At least for now, someone still has to decide what matters and check what comes back.

It is also hard to know in advance where the boundary is, because this intelligence is jagged. The model that found an exact result in KRMHD in a day could not tell that the paper it wrote was uninteresting. Last year, the model that implemented a spectral code could not tune a simulation to give a textbook spectrum. Strengths and weaknesses sit side by side, and the pattern differs from one kind of work to another. So there is no general rule. Each company has to find the boundary for its own work, by trying things and checking the results. It then has to find it again each time the models improve.

What's next

The simulations for the reworked paper are running now, and Study 04 still has to get past its first gate. I don't know yet whether either will turn up something interesting. I should know in a few weeks.

Acknowledgements

Thanks to Alex Schekochihin and the other organisers of the Vienna meeting for inviting me back. The Anthropic team for the tools.

  • in fde
  • 4 min read

Every deployment is a startup with two founders

When people hear how Palantir staffed its deployments, they usually picture a project manager and an engineer. The deployment strategist manages the client, and the forward deployed engineer builds the thing. Yes and no.

Palantir did hire for two roles. Palantir had funny names for everything, so strategists were Echoes and FDEs were Deltas. The technical bar for strategists was lower at hiring. They didn't need to be engineers, but they did need to be analytical. They had to take an open-ended question and answer it with data. Many of them also had domain expertise or were good at managing accounts.

But the mental model I always come back to is different. Think of each deployment as a self-contained startup with two founders. The strategist is the CEO and the FDE is the CTO. If you're running a startup with your co-founder, it doesn't really matter what your title is. Your title may be CEO, but you'll be writing code sometimes. Your title may be CTO, but you'll be on sales calls and doing ops. The titles shift the rough set of responsibilities. They don't draw a line between them.

On one of my deployments there were four of us. I was the tech lead, and there were two strategists and another engineer. One of the strategists, a good friend of mine, had a PhD in mechanical engineering. She wrote a lot of the PySpark code that integrated the client's data. She was also the face of the deployment to the client. The other strategist was not technical at all and could barely write Python. One part of our pipeline had to be in Java for performance reasons. When he needed something changed there and I wasn't helping, he would just open a pull request himself. His attitude was: fine, I'll do it my way and break everything, and then you'll have to help me. It worked. I'd end up saying "okay, fine, I'll fix it."

Funnily enough, I didn't do much of the client-facing work myself. The strategists I worked with did far more of it, and I mostly talked to my technical counterparts on the client side. Other FDEs I know did a lot more. Both roles are really distributions, and the job description is roughly the median.

Two overlapping curves, one for FDEs and one for deployment strategists, running from more technical to more client-facing. The job descriptions sit at the middle of each curve, and the three people from this post sit at different points along them

The founder framing also came with a lot of autonomy, and that's how it actually ran. I did some crazy things. One customer was running out of disk space on an on-premise deployment, and their procurement was going to take nine months. So I bought hard disks on my corporate card, shipped them to the customer, and we figured out billing later. I didn't ask anyone for approval. It's what a CTO would have done.

The part people miss most often is that the pair is one unit. They own the business outcome together, so if one of them drops the ball, they both have. Their incentives are aligned with each other. That is what lets them deal with all the incentives that aren't aligned, like product wanting one thing and leadership wanting another. I wrote in If LEGO had forward deployed engineers about why some of that misalignment is deliberate.

I saw this go wrong recently. A company I advise pairs its deployment leads and engineers many-to-many, to keep staffing flexible. When I tried to draw it, I ended up with one lead connected to three engineers, and one of those engineers connected to a few other leads. I couldn't reason about it. One of their leaders told me he'd started seeing Slack messages like "I discussed with him and he said he will get this done." Work was being thrown over the fence. My suggestion was to group their customers by use case or user type, and give each group a dedicated pair. One person working across a few pairs is fine. Many-to-many isn't. People aren't fungible.

Not every deployment needs to work like this. If there isn't much product discovery, and what you really need is someone to fill a gap on execution, a different shape can make sense. So the first question is what you are trying to achieve by putting people in the field. The second is whether you have the right shape of people for it.

If it's discovery, hire two founders.

  • in fde
  • 3 min read

"We need FDEs" is not a complete sentence

We need FDEs, with because handwritten underneath followed by an empty line When a new client starts a conversation with “We need FDEs,” my next question is usually “What are you trying to achieve?”

Sometimes they need engineers who can get customers up and running on an existing platform. Sometimes they need people who can work out what the platform should be. Sometimes the difficult question is who takes responsibility for what they've built once the deployment team moves on. These lead to different conversations about whom to hire, how to organise the work, and what success looks like. Calling all of them FDEs doesn't resolve any of that.

FDE is an ill-defined role, and I think there is something valuable in that. At Palantir, I did backend development, data engineering, DevOps, sales engineering, and product management under the same title. The role emerged out of what the company was trying to achieve and what stood in the way. As the product evolved, the role changed too.

There was an interesting side effect of giving people such a broad title: you could do that thinking for yourself. Identify where you could uniquely add value, ideally somewhere you also found interesting, and go do it. This was one of the key things that made Palantir a great place to work at.

On one deployment, the deployment strategist I worked with did a lot of the data pipelining while I focused on things breaking in the core product. When some of her Python code wasn't fast enough, I got involved in building a more efficient implementation. That division of work made sense for the two of us and the problem in front of us. Another pair would have divided it differently.

I often describe that partnership as being like two startup co-founders. One might be the CEO and the other the CTO, but both do whatever the company needs. The titles give you a rough idea of their strengths. They don't settle every question about who does what.

A friend of mine has a great definition of an FDE: someone who fixes broken shit. But to do that, you first have to identify the broken shit, diagnose why it's broken, and figure out how to fix it. Ideally, you leave behind something reusable. That might become part of the product, or it might be tooling that makes the next deployment easier. Otherwise, you just keep getting asked to fix the same broken shit over and over again.

That freedom needs a purpose. You don't have to know exactly what your FDEs will build before you hire them. Discovering that may be why you need them. But you do need some understanding of what you're trying to achieve, and you have to give them room to act on what they find. If they discover that the obstacle is in your product, can they help change it? If nobody will listen, their ability to diagnose the problem won't get you very far.

I've had to learn this in my own advisory work too. At one company, we started by helping existing solutions engineers take on more of an FDE role. Some of my assumptions from Palantir didn't fit the people and culture there. We had to look at who was taking to the changes, what was actually working, and where we needed to adjust. We narrowed the effort to a few people and a more limited scope, with the idea of getting that working before expanding it.

The people you already have matter. So does the state of your product, the ambition of the company, and what you're willing to change. You can learn from how Palantir did it, but you still have to work out what makes sense for you. And then keep adapting as you learn.

“We need FDEs” is a perfectly reasonable place to start a conversation. Before it becomes a job description, though, we need to finish the sentence.

A week in Vienna

Twelve years after I last attended the Plasma Kinetics Working Meeting in Vienna, I returned expecting—perhaps a little too confidently—to be the AI expert in the room, only to be humbled within the span of a week.

The first handwritten page of A week in Vienna, written in blue ink in a lined notebook

The first draft of this article, written by hand.

Technological revolutions have often reshaped science. The use of computers to run large-scale numerical simulations is an example I am personally close to. I was fortunate enough to have Bill Dorland as my PhD advisor. He was always pushing cutting-edge technology to its limits in an effort to expand the boundaries of science. He introduced me to CUDA back in 2009 and encouraged me to write the main code for my thesis to run on GPUs. So, with the rise of AI, I have been thinking a lot about what might now be possible. What new physics problems can we tackle? How does AI change the way we do physics?

Those questions sent me down a path last year of rewriting GANDALF and attempting a return to physics after a hiatus of more than a decade. The timing was fortunate: AI models were going through an inflection point, with a sudden improvement in their abilities, particularly in coding. As I made progress, I reached out to members of my former research group to show them what I had done and crowdsource ideas for future work.

Science is paradoxically both lonely and collaborative. You have to put in a non-trivial amount of individual effort, but you also have to talk to other people and share ideas. One without the other doesn't work. Those conversations led to an invitation back to the Vienna meeting for the first time in 12 years.

The Vienna meeting has always been unusually well organised. It is a working meeting where the expectation is that you make real progress during the one or two weeks you attend. The number of talks is deliberately kept to a minimum, and speakers are warned that their time is capped at 30 minutes. Interruptions and discussions—even during the talks—are encouraged, leaving most of the week for collaboration. Each week also has dedicated themes to give the work some focus.

Several physicists gathered beneath a ceiling-mounted projector, trying to get it working

Before the physics could begin: several physicists versus one projector.

I attended week two, which had two themes I was interested in: phase-space frolics, my previous research area, and AI as a research assistant, my new obsession.

This group includes some of the smartest people I know. It is a place where curiosity and original thought are valued, and I was quickly forced to recognise how narrow my own conception of AI in physics had been. I had focused mainly on computational physicists: using AI to write better codes faster, orchestrate large numbers of simulations, perform comprehensive data analysis, and produce presentations. I saw it as an assistant that could do the boring work a physicist has to get through before reaching the interesting work.

Slide showing AI writing nearly all of the code, half of the prose, and none of the research direction

My view going into the meeting: AI could do the work around the physics, but not choose the direction.

There were sceptics in the room, some of whom I managed to turn around and for whom this was exactly the right pitch. What fascinated me, however, was seeing physicists use AI for analytical calculations and mathematical reasoning. I had not realised that current models were capable of being useful in that kind of work.

We had all sorts in the room. At one end were the completely AI-pilled, pushing Claude and ChatGPT to find new gyrokinetic invariants. At the other was a hardcore programmer who struggled to cede control to Claude Code, but who, after an afternoon of seeing what was possible, found himself frustrated by the rate limits. There were also cynics who had tried something six months ago, found that it did not work, and given up without appreciating how rapidly the technology was improving.

Some started using AI more in their work and personal lives over the course of the week; others remained unconvinced. But even among the sceptics, there was a sense that the technology is here to stay and has the potential to change how we work.

I arrived in Vienna thinking that AI's role in physics was largely to remove the computational drudgery surrounding the interesting work. I left wondering whether it might also become part of the reasoning itself. I don't yet know where that leads, but I am energised by the possibilities.

In the coming months, I hope to carve out more time for independent physics research and find out.

  • in fde
  • 4 min read

Is FDE a Bubble?

When I wrote If LEGO Had Forward Deployed Engineers, I opened by saying the role was having a moment. That was an understatement. Since then the title has spread everywhere — every AI startup seems to be hiring FDEs, investors ask founders about their "FDE motion" the way they used to ask about their PLG motion, and the job ads have long since outrun any shared understanding of what the job is.

When a title spreads faster than the understanding behind it, it's worth asking the uncomfortable question: is FDE a bubble?

I should declare my interest upfront. I spent seven years as an FDE at Palantir and I now make my living helping companies build FDE organisations. I have every incentive to tell you the answer is no. Bear that in mind as you read.

Palantir never chose FDE

The origin story matters here, because it's the part everyone skips.

In The FDE Fork I described how Foundry was an accident — nobody sat in a room and decided to build it. FDEs were solving customer problems, building tools to bootstrap themselves, and the product fell out of the residue. But push that one step further back: the FDE role itself was an accident too. Nobody at Palantir designed "forward deployed engineering" as an organisational innovation. In the beginning there was no platform to deploy. FDEs worked the way founding engineers work: embedded in a customer's mess, doing discovery, building custom things end to end. Out of the learnings from those bespoke builds came the beginnings of Foundry. And then the same motion kept repeating — pointed at a different part of the platform each time, always at the envelope of what didn't exist yet. Plenty of those deployments ran at a loss. The economics were never the point; the discovery was. The tooling fell out of the delivery, the product fell out of the tooling, and the role got a name only after it already existed.

FDE, in other words, is residue. It's what was left over after one company spent a decade solving one specific problem from first principles. The structure was downstream of the reasoning, never the other way around.

Copying the residue

What's spreading right now, mostly, isn't the reasoning. It's the residue.

A founder reads about the Palantir model, or watches an AI lab they admire hire FDEs, and concludes that the title is the strategy. They hire smart generalists, call them FDEs, send them to customers, and wait for the magic. At no point does anyone ask the first-principles question — what is our deployment problem, and what is the cheapest structure that solves it?

Sometimes the honest answer to that question is an FDE team. Often it's a solutions engineering function, or better documentation, or a smaller product surface, or the admission that the product isn't ready to sell yet. But those answers don't sound like Palantir, so they don't get considered.

The LEGO test applies directly. If your FDEs are building dragons but nobody is walking back to product with the bag of weird bricks — if the field signal never changes what you build — then you haven't built an FDE org. You've built a services team with a fashionable title. That can be a perfectly good business. It just isn't the thing you thought you were copying, and it won't produce the thing Palantir's version produced.

The part that isn't a bubble

A lot of AI companies genuinely do have Palantir's problem shape. Capable technology, bespoke deployments, a chasm between "demo works" and "production works", customers who can't self-serve their way to value, and a product whose shape nobody knows yet — the kind you only discover by embedding engineers in a customer's mess and watching what they're forced to build. A founder who reasons honestly from those constraints will land on something that looks like forward deployment — not because Palantir did it, but because the same conditions produce the same conclusion.

And as I argued in The FDE Fork, AI has made a second version of the model coherent — the outcomes path, where the internal tooling compounds and the FDE never stops being the product. The model has more legitimate configurations today than it did when Palantir ran it, not fewer.

So the model isn't hollow. The bubble, to the extent there is one, is the gap between the number of companies using the title and the number that did the reasoning.

What happens when it pops

That gap will close the way these gaps always close. The companies that hired FDEs as an identity will quietly discover they built expensive support engineering, wind it down, and conclude that "FDE didn't work for us" — when the truth is they never had the problem FDE solves. The title will absorb some reputational damage on the way down, and the discourse will move on to whatever gets named next.

The companies that derived their structure from their own problem will be fine. Some of them will be running FDE orgs. Some of them will be running something else that they arrived at the same way Palantir arrived at FDE. What they call it won't matter much.

The wrong question

Which is why "is FDE a bubble?" is ultimately the wrong question. Whether the title is over-adopted matters far less than whether you derived your structure from your problem.

Palantir's actual insight was never "put engineers in the field." It was the willingness to look hard at the problem in front of it, ignore what everyone else's org chart looked like, and build whatever the problem demanded. FDE is what that process produced — once, for one company, in one problem space. It happened to be immensely successful, so the output got a name and the name got copied. But the output was never the insight, the process was.

If you do that reasoning and land on FDE, great. If you do that reasoning and land somewhere else, also great. The only losing move is skipping the reasoning.

FDE is not the path to success. Solving problems from first principles is.

  • in physics
  • 12 min read

AI as the Undergrad Researcher: A Real Physics Result, Two Months, One Person

Writing code with AI is no longer surprising. I rebuilt my PhD-era gyrokinetics code in JAX with Claude in 30 days last year (Building a Gyrokinetics Code Without Reading a Single Line). What I actually wanted to test was the next step: can AI do the unglamorous, undergraduate-level research motions that turn a working tool into a publishable result — running simulations on a cluster, iterating on the configs when the physics looks off, generating diagnostic plots, catching numerical bugs, and drafting the paper?

Two months later, the answer is yes. The paper is merged (repo, currently with Alex Schekochihin for review). It's a small but clean physics result: across a 50× scan in collisionality, the phase-space dissipation rate stays flat to under 1%. The kinetic analogue of Onsager's classical 1949 dissipative anomaly, demonstrated directly in nonlinear KRMHD simulation.

In this article I write about what those two months actually looked like — what Claude did, where I stepped in, and the broader claim I want to make: computational physics researchers today have undergraduate-level research assistants on tap, and using them well is a systems problem more than a model problem.

The Setup

In plasma turbulence, energy cascades from large scales down to small scales until it dissipates. The dissipation rate ε_ν depends on collisionality ν. Onsager's 1949 result for incompressible fluids (the dissipative anomaly, sometimes called Onsager's conjecture) says ε_ν becomes independent of viscosity in the inviscid limit — the cascade self-organises to maintain constant flux. The kinetic analogue of this statement has been argued for in the literature (Schekochihin 2016, Adkins 2018, Eyink 2018, Nastac 2024) but hadn't been directly demonstrated in nonlinear KRMHD simulation. That was the question: can we see the ν-independent plateau?

The reason to pick this question was pragmatic. The setup is tractable, all you need is one diagnostic per run. If the simulations behaved, the result would be unambiguous. Checking the validity of the results was easy.

Figure 1: The collisional dissipation rate ε_ν stays flat to under 1% across a 50× scan in collisionality ν. This plateau is the central result of the paper.

Dissipative anomaly plateau: epsilon_nu vs nu

Figure 2: What a healthy run looks like (ν=3). Left: the time-averaged perpendicular spectrum E(k_⊥) shows a clean inertial-range cascade. Right: the Hermite-moment spectrum W(m,t) as a heatmap — energy stays confined to low m, with no pileup at the m=128 truncation. This is the "physics makes sense" check I was doing on every run.

Base-state spectrum and W(m,t) heatmap for the nu=3 run

The Workflow: Claude Does the Undergrad Work

For two months, almost every day, the rhythm looked like this:

  1. I state the next physics goal in a sentence or two.
  2. Claude proposes a config — YAML parameters, a Modal runner, sometimes a new diagnostic.
  3. I push back on the physics where it looks wrong, or say "go for it."
  4. Claude submits the run to A100 cloud GPU.
  5. Run finishes, Claude pulls the data and generates plots.
  6. I look at the plots and decide whether the physics makes sense.
  7. If yes, Claude drafts the paper section. If no, we iterate.

The bulk of the labour — writing the Modal runner, parsing diagnostic outputs, fitting power laws, generating figures, writing LaTeX, managing the BibTeX — was Claude. I never touched the cloud orchestration code. I never wrote a matplotlib script. I never edited the LaTeX preamble. I looked at outputs and either nodded or asked for something different.

As things progressed, we got into a rhythm. A normal day involved me sending 5-10 short messages, mostly along the lines of:

  • "go for it"
  • "this looks great! Let's get it merged."
  • "ok submit the M=256 run too"

This is the texture of the collaboration most of the time: short, direct, advisory messages, the kind you would send a capable grad student.

Where I Stepped In

The interesting moments are the five places where I had to nudge. None of them were heroic. Each was the kind of intervention an advisor makes when a student is going down the wrong path.

Nudge 1: Lambda

Two weeks in, the Hermite cascade wasn't cascading. The setup was right by every code-level check, but energy was just sitting in the lowest moment. I asked: isn't there supposed to be a coupling Λ between g₀ and g₁? The Alfvénic checkpoint we'd restarted from had Λ=1; for the Hermite problem at β_i=1, it should be √5. One physical constant. The cascade lit up on the next run.

The AI executes correctly inside the frame it is given. The frame — including the specific physical values that distinguish your problem from the adjacent one — is yours to set.

Nudge 2: Three Weeks Chasing a Numerical Ghost

This was the longest detour, and the one I keep thinking about. Every nonlinear run at high ν blew up. The blowup times scaled with ν cleanly — ν=1 died at 80 τ_A after the restart, ν=3 at 122 τ_A, ν=5 at 167 τ_A — and the scaling matched what the canonical "pileup at the Hermite truncation" failure mode predicts. The literature warns about it. I went deep into that hypothesis.

For three weeks Claude helped me investigate inside that frame: adjusting hyper-collisional dissipation, varying M, looking at high-m energy budgets. The frame was wrong, but it was an internally consistent wrong frame, which is what made it so hard. Every diagnostic could be interpreted as consistent with the pileup story if you squinted.

What broke it was finally asking Claude to extract the three diagnostics the pileup story actually predicts: the energy at the truncation moment, the parallel-wavenumber spectrum at the highest m, and how localised the blowup was across m. The pileup story predicted a clear signal in all three, and the data showed none of them. The energy at the truncation sat at the noise floor, the k_z spectrum at high m was down at 10⁻¹⁴, and the blowup happened simultaneously across every moment, independent of ν. That is not a physical cascade failing; that is the time integrator.

Figure 3: What the wrong story looked like. W(m,t) heatmaps for the runs that blew up, with the divergence in ΣW(m), W(m=M), and ε_ν(t) on the right. It reads as a physical pileup at the truncation, but it was actually a hidden CFL leak in the Lawson-RK4 integrator. The wrong frame produced fingerprints that looked entirely physical.

Hermite blowup W(m,t) heatmaps for the Lawson-RK4 runs

I reframed for Claude: this isn't a physics bug, it's a code-path bug. Look at the Lawson-RK4 integrator. Within an afternoon Claude had identified a hidden CFL leak in the integrator. A fix shipped as GANDALF #138 the next day.

The honest version is that the AI did not catch this. It spent three weeks helping me debug inside a confidently wrong hypothesis. What broke the frame was me coming back to first principles and asking "what would the data look like if I were wrong?" before "what would the data look like if I were right?"

This is the hardest discipline to maintain in a long project. The frame is yours to set, and questioning it is yours too.

Nudge 3: Dropping the Π(m) Panel

Late in the project Claude proposed a second panel for Figure 1 showing the constant-flux Hermite cascade, Π(m) versus m. The diagnostic worked and the figure was real, but the ν=1 curve had a clear numerical artifact left over from low-ν pileup. Claude was happy to keep the panel with explanatory caveats. My message at the time was: hmmm the flux plot is not great honestly. i think we should just remove it. The figure that survived was cleaner, and the headline result stronger.

The instinct to publish less rather than over-claim is a human one. The AI will defend a marginal figure indefinitely if you let it.

Nudge 4: Checking the Novelty Claim

The draft asserted that no prior numerical work had cleanly demonstrated a ν-independent ε_ν. I have been out of active physics for over a decade, so I am not current on the literature and couldn't vouch for that claim. What I could do was flag it. I asked Claude whether we actually had a citation for the sentence.

Claude pulled the relevant prior work, including Nastac 2024 — titled "Phase-space entropy cascade and dissipative anomaly," recent, directly adjacent to our claim, and a paper I had never seen. We turned the bare assertion into a short prior-work paragraph and cited it properly.

This nudge cuts the other way from the rest. Here the AI knew the literature better than I did. My contribution was the editorial reflex of not asserting novelty I hadn't checked; the retrieval was Claude's. The lesson is to interrogate your own strong claims and let the AI do the literature work it is genuinely good at.

Nudge 5: The Convergence Study

This is the least dramatic of the five, included because it is the routine mode. Late in the project I said: we should do the M convergence as a part of this study. Claude wrote the Modal runner, submitted two new sims (M=64 and M=256 at ν=3), did the analysis, and wrote the new subsection. The whole thing took two days, with almost no input from me beyond approving the configs. Most of the collaboration looks like this. The dramatic episodes are easy to write about, but the long calm stretches where the work just gets done are the actual story.

Memory: The New Piece of Infrastructure

For the GANDALF sprint, persistent memory didn't matter. It was thirty days in one rhythm, and the whole project fit in active context.

For this project it did matter. At sixty days you can't hold everything in working memory, because sessions interrupt each other and knowledge from Tuesday gets lost by Thursday unless you write it down. The auto-memory system in Claude Code — files that persist across sessions — turned out to be the most important piece of infrastructure for the long arc.

There are six memory files for this project right now. Two of them, verbatim:

Lambda parameter physics Lambda=1 kills Hermite cascade; use √5 for standard β_i=1

M=128 Hermite — resolved by GANDALF v0.5.0 IMEX Lawson blowup was numerical; pin scheme="imex_rk222"; ν=3 acceptance passed

These are corrections I won't have to relearn three weeks later. The "I already explained this to you" cost is the silent productivity killer in any long-running AI collaboration, and persistent memory is what prevents it.

It's a Systems Problem

The most important thing I learned from this project is that using AI effectively at the two-month scale is not a model problem but a systems problem.

The model is a given. What mattered was the system around the model: persistent memory, the choice of a tractable physics question, Modal as the cloud orchestration layer, a clean cross-repo handoff between GANDALF (the upstream library, where bugs got filed) and krmhd-research (the science repo, where the paper lives), a paper repo with curated BibTeX, the ability to look at a generated plot and decide in seconds.

The autonomy gradient framing I wrote about a few months ago — about choosing where on the spectrum from "I drive every step" to "AI runs autonomously" — already feels dated. The model capability has moved faster than the framework was ready for. The real question now isn't "how much autonomy do I give it?" but "what's the system I need around it so that the autonomy is productive?"

By "system" I mean the set of practical questions around the model. Where do corrections persist? Where do artifacts live? What is the cross-tool rhythm? Where do you intervene without breaking flow? What is the smallest unit of trustable output — a plot, a config, a paragraph? And how do you make decision-points cheap enough that you actually make them?

I don't have clean answers. What I have is the working version of one specific instance: a six-memory-file, two-repo, Modal-backed, advisor-mode rhythm that produced a paper. The recommendations below are what I've extracted from it.

What This Enables: Independent Computational Research

The category I keep thinking about is "recovering physicists" — people who left active research years ago but kept the training and the taste. The cost of returning is now genuinely low. A side project, a few hours a week, can produce real work.

Computational physics researchers today, in my reading, have undergraduate-level research assistants on tap. They are not as good as a great grad student, but they are far better than no help at all: reliable, never tired, comfortable at 2am, and never frustrated when you ask them to redo a figure for the fifth time.

This isn't an "intelligence explosion" claim. The model isn't replacing the PI. What it's replacing is the bottleneck of needing collaborators and students just to make a tractable problem possible to attack. A senior researcher who can recognise good physics and bad physics now has access to a pool of execution labour they didn't have before.

I am over a decade out of an active research role, and I am running a real physics investigation as a side project. That would not have been possible 18 months ago.

Recommendations for Long-Running AI-Assisted Research

These are opinionated, and some will age badly given how fast the model and the tooling are moving.

  1. Choose a scope you can validate at a glance. Pick a question where the headline diagnostic is a number or a single curve. If you can't tell instantly whether the result is right, neither can the AI.

  2. Build persistent memory aggressively. Every hard-won correction goes in, whether it is a specific physical value, an algorithmic gotcha, or something the AI got wrong twice. Re-learning is the dominant hidden cost.

  3. For any result you can't independently verify, ask "what would the data look like if I were wrong?" before "what would the data look like if I were right?" The Lawson-RK4 misdiagnosis cost three weeks because I never ran the falsifying diagnostic first.

  4. Default to dropping marginal results. The AI will defend a borderline figure indefinitely. The discipline to publish less is yours.

  5. Interrogate your own novelty claims. Don't let "no one has done this before" stand on faith, especially if you're not current on the literature. Ask the AI to find the prior work — retrieval is something it does well, particularly if you've had it build up a reading list you can point it back to.

  6. Run experiments on git branches and tell Claude to commit relentlessly. I leaned on git heavily. A branch lets the AI try a parameter change or a refactor in a sandbox without touching the version that works, and frequent commits turn a bad run into a one-command rollback rather than a reconstruction job. When the AI is generating most of the code and configs, cheap rollback is what lets you give it room to run.

  7. Build the cross-tool rhythm explicitly. If your work spans multiple repos or services (an upstream library + your project + a cloud compute provider + a paper repo), be explicit about the handoffs. File upstream issues. Plan for context-switching cost.

  8. Treat the AI like the smart undergrad. Validate through physics outputs, not code review. Don't read the code; look at the plot. If the plot looks right and the diagnostics check out, the code is probably right. If the plot looks wrong, no amount of code reading will tell you why.

  9. Question your framing every 1-2 weeks. If you've been working inside a hypothesis for two weeks without pushback, force a first-principles review. The AI won't supply that question.

The Numbers

  • Calendar time: ~9 weeks, including the extended detour
  • Production runs: 9 (6 in the main ν-scan, 3 in the M-convergence)
  • Modal GPU-hours: ~52 (mostly A100, mostly overnight)
  • Failed Lawson-RK4 runs along the way: ~12 (the three-week wrong frame cost compute too)
  • Memory files created: 6
  • Paper: 8 pages, 11 references, 3 figures, 1 results table, 1 convergence table

I don't have a clean dollar figure for Claude API usage on this project — the work spanned Claude Code sessions across multiple repos, various model tiers, and some agentic runs. Honest estimate: small compared to the GPU compute, which itself is small compared to a postdoc-month.

What's Next

The original experiment plan listed multi-ion turbulent heating as the actual physics target. The dissipative anomaly was a stepping-stone — a question I picked precisely because I could tell at a glance whether the answer was right. The next thing is harder. The physics is less clean, the literature is more contested, and the diagnostics don't reduce to a single number.

The thing I most want to find out is whether the rhythm scales — whether the system holds when the AI doesn't have a clear template from existing literature, when "what's the right plot?" is itself a research question, and when the answer isn't a flat line but something with structure I'll have to interpret. I'll know in a few months.

The intelligence-on-tap claim looks more real than it did a year ago. What I now think is the real constraint is the speed at which you can validate what the AI produces. The AI does the undergraduate work cleanly, and the bottleneck is the advisor looking at the outputs and deciding whether they are right.

Acknowledgements

Alex Schekochihin for reviewing the draft and continuing to point me at the right physics. The Anthropic team for the tools.

  • in fde
  • 9 min read

The FDE Fork: Platform or Outcomes

In If LEGO Had Forward Deployed Engineers, I ended with a wrinkle I promised to write up properly: AI keeps handing FDEs new bricks, the line between "forward deployed engineer" and "software engineer" is blurring, and at some point you have to ask whether you even need to productise the dragon at all.

This is that piece. It's now a real choice. There are two coherent ways to run a forward deployed company, AI made the second one viable, and a founder who hasn't consciously picked one is going to build a confused org with a confused FDE role. The nature of the FDE role isn't a fixed thing you can look up. It's downstream of a strategic decision most founders don't realise they're making.

Engineers building messy tools, a polished platform emerging behind them

Foundry was an accident

Start with where the role comes from, because the origin explains everything that follows.

Nobody at Palantir sat in a room and decided to build Foundry. Here's how I described it on a call last year:

The way Foundry as a product actually happened is very interesting. No one said, "Oh, let's build Foundry." It was literally forward deployed engineers working with customers, almost a consulting shop. And the difference between an FDE and a consultant is the alignment: we get paid to solve problems, not to spend hours solving them. Given they were engineers, what they would do is build tools to bootstrap themselves — mainly for the data integration piece. And some customers noticed this and said, "If you just license the tools, we'll pay licence fees for them." That's how Foundry happened. A couple of FDEs went away and said, "We're going to take a few months and build Foundry."

So the product and the FDE motion were entangled from day one. The FDEs weren't there to deliver Foundry. They were there to solve customer problems, and Foundry fell out of the residue — the tools they kept rebuilding to make themselves faster.

That's worth holding onto, because it means the FDE role was never defined by the platform. The platform was defined by the FDEs.

The 2015–2020 thesis: forward deployment in service of a platform

For most of the decade that followed, though, the relationship ran the other way. Once Foundry existed, the FDE motion had a job: feed the platform.

This is the role I described with the LEGO dragon. The customer wants a dragon, there's no brick for the curve of its neck, so the FDE drills holes and glues bricks and builds a Frankenstein scaffold and then builds the dragon. The deliverable to the customer is the dragon. The deliverable to your own company is the bag of weird bricks — the custom hacks you walk back to the product team so they can decide what to manufacture. That loop, customer problem → bespoke build → product signal → real product, was the whole game. The FDE was a product R&D function dressed up as a delivery function.

And the thing that made that motion sustainable — that justified years of low-margin, labour-heavy services work — was the ambition behind it. Palantir wasn't running a consultancy that happened to write software. It was building the operating system for the world's largest and most important institutions, and the services were the cost of discovering the shape of that operating system. You can't find the shape of a platform from a conference room. You find it by embedding engineers in twenty messy customers and seeing which weird bricks keep showing up.

You can see the platform doing its job in the staffing numbers. Early on, a single use case took something like three to five FDEs. By a few years in, the ratio had inverted — one FDE could carry two or three customers, because the platform had absorbed enough of the weird bricks that each new deployment needed less hand-building. The role was, by design, bending towards its own obsolescence. Every brick you productised was a brick the next FDE didn't have to drill.

That's the tell. In the platform model, a healthy FDE org is one that slowly needs fewer FDEs per dollar. The role is a scaffold. The building is the product.

A LEGO tower with its scaffolding being removed

What AI changes

Now the wrinkle.

The reason the platform model made sense wasn't just ambition, it was economics. Services scale linearly with headcount and carry consultancy margins. The only way to escape that gravity was to productise — to convert hand-built dragons into licensable bricks so that, eventually, the customer's own engineers build dragons on top of your platform while you collect licence fees. Productisation was the only exit from the margin trap.

AI weakens that constraint. When a single engineer with Claude Code, Skills, MCP servers, and a stack of internal agents can build a credible dragon in an afternoon, the cost of bespoke delivery collapses. And once bespoke delivery is cheap enough, you can run a services business at margins that used to require a product.

One engineer building a dragon, helped by automated brick machines

This is the "AI-powered services" thesis that Sequoia and YC have been talking about — services companies with software economics. The mechanism is exactly the brick library getting powerful enough that you no longer need to manufacture and sell bricks to make the unit economics work. You just keep the brick-shaping machine internal, point your FDEs at it, and sell the dragons.

So a third model becomes available — and notice it's not new, it's the original model with the economics fixed. Palantir started as "essentially a consulting shop." The reason it couldn't stay one was margins. AI is, in effect, an offer to remove that reason.

The fork

Which gives founders a genuine fork. Two coherent strategies, and you have to pick.

A LEGO road forking towards a platform on one side and a delivery workshop on the other

Path A — Platform. You productise. The FDE is a product scout. The compounding asset is the product, and you sell licences. The bet is that the weird bricks generalise — that the abstraction you extract from twenty customers is good enough that the twenty-first buys the platform instead of the service. You also have to be able to survive the valley: the years of unprofitable services before the licence revenue compounds. This is the Palantir-to-Foundry path, and it works when the abstraction is real and the market is large enough to be worth the wait.

Path B — Outcomes. You don't productise — or rather, you productise internally and only internally. You build the brick-shaping machine, the agents, the deployment tooling, and you never sell any of it. The FDE is a delivery superpower wielding private tooling no competitor can buy. The compounding asset is that internal toolchain plus the accumulated muscle memory of having deployed into a hundred messy environments. You sell outcomes, priced as outcomes. The bet is that AI keeps your margins healthy enough that you never need the licence-fee exit at all.

The honest tension between them is the one I raised in the LEGO piece. I argued there that walking the weird bricks back to product is "the step that makes it engineering" — skip it and you're just a very expensive consultancy in a t-shirt. Path B looks, from the Path A vantage point, exactly like collapsing that tension and building Accenture.

But I don't think that's quite right anymore. On Path B you still walk the weird bricks back — you just walk them back to your own internal platform team instead of to a product you'll sell. The loop still runs. It's just that the flywheel is your internal capability, and it compounds without ever being packaged, priced, documented, or supported for an external buyer. Whether that's a worse flywheel or a better one is genuinely open. It's worse because you forgo license-fee leverage and the discipline that selling a product imposes. It's better because you skip the brutal productisation tax — the years spent making a thing general, supportable, and sellable — and you keep your best tricks proprietary.

That's the fork, two different theories of where the compounding asset lives: in a product you sell, or in a capability you hoard.

What the fork does to the FDE role

Here's why this matters for the role specifically, and not just the cap table.

On Path A, the FDE is a product scout, and that has hard consequences. The incentives have to live at the company level — revenue per forward-deployed person across the whole company, never revenue per engagement. Measure engagements and your FDEs quietly become account managers: they optimise for charging more for each dragon and stop bringing back the bricks. And the role bends towards obsolescence, on purpose. The honest thing I'll say here: I left Palantir partly because I couldn't find an FDE role I'd still enjoy. The platform had matured enough that the discovery work — the actual reason I liked the job — had thinned out. That's not a failure of the model. That's the model working. On Path A, the role is supposed to eat itself.

On Path B, the opposite. There's a line I keep coming back to: when you don't have a product, the FDE is the product. On Path A that's a phase — true in the early days, less true every year. On Path B it's the steady state. The FDE never becomes a scaffold for something else, because there is nothing else; the forward deployed engineer, augmented by internal tooling, is the entire company. The role doesn't sunset. The risk is different and real: without the discipline of an external product to feed, FDEs can drift into pure delivery, and "we shape bricks internally" decays into "we don't shape bricks, we just bill." Path B without a strong internal platform culture really does become Accenture-with-better-margins.

This, by the way, is why "FDE" has become such a confused title. It's become a big fat umbrella — solutions engineer, solutions architect, the Palantir thing, all crammed under one acronym — and people complain it means different things to different people. It does. But a lot of that confusion isn't sloppy language. It's that the companies using the title haven't decided which fork they're on. A Path A FDE and a Path B FDE genuinely are different jobs, with different incentives, different career arcs, and different definitions of success. Of course the word means different things. The companies do.

The choice founders have to make

So the instruction is simple, even if the decision is hard: pick.

The Palantir FDE motion was sustainable because the ambition carried it — the operating system for the world's largest institutions was a vision big enough to justify a decade of unprofitable services. If you're running Path B, you can't borrow that vision, because you're explicitly choosing not to build the sellable operating system. You need your own sustaining story and your own scoreboard: outcomes delivered, margin per FDE, the rate at which your internal tooling makes the next deployment cheaper. Those are different KPIs than "licence revenue" and they reward different behaviour.

What you cannot do is stay ambiguous. An org that hires Path A product scouts, measures them on Path B engagement outcomes, and tells investors a platform story while running a services business will tear its FDE role apart. The FDEs will feel the contradiction first — they always do — and the best ones will leave, because the role they were sold isn't the role the incentives are paying for.

The FDE role was never one fixed thing. It's a function of strategy. In 2015 the strategy was "find the shape of the platform," and the role was a product scout. The strategy could now just as legitimately be "sell outcomes forever, keep the machine internal," and then the role is a permanent, AI-amplified delivery superpower. Both are real companies. Both can be great companies.

AI is what made the second one viable. It didn't make the choice for you. Pick on purpose.

  • in fde
  • 5 min read

If LEGO Had Forward Deployed Engineers

Forward Deployed Engineer is having a moment. Anthropic and OpenAI are pouring billions into the model. Lots of articles getting written about it. Founders are spinning up "FDE" titles before they've really worked out what the role does. And in nearly every conversation I have — with founders, recruiters, or curious engineers — the same question comes up: what actually makes an FDE different from a really good consultant?

Here's my attempt at explaining the role with a thought experiment.

Messy Lego

The customer wants a dragon

Imagine LEGO decides to spin up a Forward Deployed Engineering org tomorrow. The first customer walks in and says: I want a dragon.

You can solve that request two ways.

The solutions engineer path. A solutions engineer at LEGO has a beautifully organised inventory of every brick the company makes. They read the dragon brief, pick the right 287 pieces, write a clean instruction booklet, maybe even build the model themselves, and hand it over. The customer looks at it and goes, "Hmm — kind of looks like a parrot, but yeah, I can see the dragon. Thanks." Successful delivery. On to the next request.

The forward deployed engineer path. An FDE starts the same way, picking through the existing brick library — but they get stuck. There's no brick that gives them the right curve for the dragon's neck. The wing pieces don't articulate the way they need to. So they grab a brick, drill a hole through it, glue two together, sand a third one flat. They build a Frankenstein scaffolding of custom-modified pieces, and then they build the dragon.

Solutions Engineer vs FDE

The customer looks at the FDE's dragon and says, "Actually, I wanted a Lord of the Rings dragon, not a Zog from Julia Donaldson." Fine. The FDE iterates. More custom hacks. Eventually they hand over a dragon the customer actually loves.

The end state for the two paths look identical — both delivered a dragon. But the FDE has one more step, and that step is the entire point of the role.

The step that makes it engineering

The FDE walks back to the LEGO brick R&D team holding a bag of weird, hacked-together bricks and says: "These are the pieces I had to invent to build that dragon. We don't make any of them. Should we?"

The product team looks at those custom bricks and decides what to do. Maybe they manufacture one of them as a new SKU. Maybe they don't manufacture any specific brick, but the patterns suggest they should build a machine that lets customers shape their own bricks. Maybe they conclude the dragon use case itself isn't worth investing in, but the technique unlocked something else entirely.

That loop — customer problem → bespoke build → product signal → real product — is the whole game. Without it, you are simply a very expensive consultancy in a t-shirt.

This is where the "E" in FDE earns its keep. A forward deployed engineer has to be technical enough to actually drill the hole, glue the bricks, build the thing. Otherwise the signal that comes back is mush. "The customer wanted a dragon and we couldn't build one" is useless. "The customer wanted a dragon, and the only way I could approximate it was by violating the structural integrity of these four standard bricks in this very specific way" is a product roadmap.

Weird Brick

Misaligned incentives, by design

The dirty secret of running a healthy FDE org is that the incentives between FDEs and product teams are deliberately misaligned.

The FDE wakes up every morning thinking: how do I win this customer? What do I have to violate, hack, or hand-build to ship the dragon they want? The product team wakes up every morning thinking: what's the general abstraction that lets us serve a thousand customers without hand-building anything?

Those two incentives pull against each other constantly, and the tension is genuinely uncomfortable. It's also where good product comes from. Collapse the tension by making everyone think like a product manager, and you stop getting customer signal. Collapse it the other way, by making everyone think like a delivery engineer, and you build Accenture. The job of leadership is to hold the rope taut.

One important corollary: FDE KPIs have to live at the company level, not the engagement level. The moment you start measuring revenue per engagement, your FDEs stop being product scouts and start being account managers. They optimise for charging more for the dragon. They stop bringing back the weird bricks. The healthier metric is something like revenue per forward-deployed person, company-wide — because the win isn't the FDE working harder on each engagement, it's the FDE identifying which bricks are worth productising, so that eventually customers' own engineers end up building dragons on top of those bricks while you collect licence fees. That's the flywheel. Engagement-level metrics short-circuit it.

So what is an FDE?

If you take only one thing away: a Forward Deployed Engineer is a product R&D function dressed up as a delivery function. The deliverable to the customer is a dragon. The deliverable to your own company is the bag of weird bricks you had to invent to build it.

If no one is walking back to product with that bag of bricks, you don't have an FDE org. You have a really good services team. Both are valuable, both can be lucrative — but they're different jobs, and conflating them is how organisations end up confused about why their "FDEs" don't seem to be moving the product forward.

There's a wrinkle worth flagging, which I'll write up properly another time: AI keeps handing you new bricks. Claude Code, Skills, MCP servers, agent frameworks — the brick library itself is now powerful enough that a single engineer can build a credible dragon in an afternoon. As the bricks get more capable, the line between "forward deployed engineer" and "software engineer" starts to blur, and you have to ask whether you even need to productise the dragon at all, or whether the right move is to just keep delivering bespoke ones forever. That's a whole other topic.

For now, the LEGO test is enough: drill the brick, build the dragon, bring back the brick. That's the job.

  • in fde
  • 5 min read

What Claude Code's Creator Validated About Forward Deployed Engineering

Last week, Boris Cherny appeared on Lenny's Podcast to talk about Claude Code — the AI coding assistant that now generates 4% of all GitHub commits and helped Anthropic achieve a 200% productivity increase.

Every major insight Boris described — from building for future capability rather than current constraints to finding product-market fit through "latent demand" — perfectly captured what we'd been doing as Forward Deployed Engineers at Palantir for over a decade. It was like listening to someone independently discover gravity.

For seven years at Palantir, I lived the FDE model: small, elite teams embedded directly with customers, building systems ahead of their current capability, discovering requirements by watching how people actually worked rather than what they said they needed. Boris validated that this approach isn't legacy — it's the future of how we'll build AI products.

Building Six Months Ahead

"Build for the model 6 months from now, not today," Boris said. The Claude Code team deliberately avoided over-scaffolding. They gave the model tools and goals and got out of the way, betting on rapid capability improvements rather than constraining the system to current limitations.

This hit me because it's exactly how FDEs approach customer deployments. We don't build systems for where an organization is today — we build for where they'll be in six months. When I was deploying Palantir at large enterprises, the worst mistake was to over-constrain the system to current workflows. The org would evolve, their data would grow, their processes would mature, and suddenly the system we'd carefully tailored to their "requirements" became a straightjacket.

The best FDE deployments gave customers slightly more capability than they could immediately use. We'd build data pipelines that could handle 10x their current volume. We'd create analysis workflows that assumed they'd eventually want to ask more sophisticated questions. We'd design user interfaces that didn't require retraining when their team grew from 5 to 50 people.

This wasn't over-engineering — it was under-constraining. Just like Claude Code bet on the model getting smarter, we bet on the customer getting more sophisticated.

Latent Demand as Product Compass

One of Boris's revelations was that Claude Code's breakthroughs came from watching how people used it in creative ways. Data scientists running SQL queries in terminal windows. Non-technical users asking it to help grow tomatoes. People recovering corrupted wedding photos. This "latent demand" led to Cowork, built in just 10 days because they could see exactly what users were trying to do.

"Latent demand" is just Boris's term for what FDEs do every single day: sit with users and watch how they actually work.

The best features I ever built came from observing workarounds. An analyst who'd manually copy-paste data between systems every morning because the official integration was too rigid. An operations team that kept a separate spreadsheet to track what the official dashboard couldn't show them. An investigator who'd screenshot charts to paste into Word documents because the export function didn't capture what they needed to communicate.

These weren't feature requests — they were organizational antibodies. Users working around the system to get their real job done. Standard product management would survey these users and ask what features they wanted. They'd probably say "better export" or "more integration options." But that's not what they actually needed.

FDEs watch the workflow, not the words. We see the person taking screenshots and realize they don't need better export — they need a way to tell stories with data. We see the manual copy-pasting and realize the issue isn't integration — it's that the official process doesn't match how the work actually flows.

The most successful FDE engagements came from finding latent demand the customer couldn't articulate themselves. Not because they were dumb, but because they were so close to their daily work they couldn't see the pattern.

Ideas Over Engineering Capacity

"Coding is largely solved," Boris said. "The bottleneck is ideas and prioritisation." In the AI era, the new scarcity isn't engineering capacity — it's knowing what to build.

This validates everything FDEs were designed to solve. We were never primarily about coding. Yes, we could write software — often quite quickly — but our real value was understanding the problem deeply enough to know what to build.

The best FDE I worked with at Palantir wasn't the best coder on the team. They were the person who could sit in a room with a counter-terrorism unit and figure out what actually mattered. Who could distinguish between what the organization said it needed and what would actually make their mission successful. Who could see patterns across different deployments and recognize when a specific customer's problem was actually a general case of something we'd solved before.

This person would often write less code than junior engineers on the team. But they'd save months of work by solving the right problem the first time.

Now that AI can generate most code, this skill becomes even more critical. If Claude can write your functions, your value is knowing which functions need to exist.

The Death of "Software Engineer"

"The title 'software engineer' is dying," Boris observed. "Builder is the new reality." As AI democratizes coding, roles blur between engineering, product, design, and deployment.

FDEs were always "builders." Our job description was impossible to write because we did everything: product research, technical architecture, user interface design, data engineering, deployment operations, user training, and ongoing support. We didn't fit neatly into any org chart because the role was defined by outcome, not function.

Traditional software engineering was about implementing specifications. Someone else figured out what to build; engineers built it. But FDE work was always end-to-end ownership. We figured out what to build, built it, deployed it, and lived with the consequences.

This frustrated a lot of people who wanted clean role boundaries. But it was extraordinarily effective for solving complex, novel problems where the solution space wasn't well-defined.

The industry is catching up to what Palantir figured out years ago: when you're building something truly new, you need people who can think across the entire stack — technical, product, and operational. "Builder" is a better word than "engineer" because it captures the full scope.

What This Means for AI Companies

If you're building AI products today, the FDE model isn't legacy — it's your playbook.

Stop organizing around functional silos. Find people who can think across the whole problem, give them access to the best tools, and embed them directly with customers. Build slightly ahead of current capability rather than constraining to current workflows. Watch how people actually use your product, especially the ways they "misuse" it.

Most importantly: understand that your bottleneck isn't engineering capacity anymore. It's product judgment. It's knowing what to build. It's finding the latent demand that customers can't articulate themselves.

The companies that figure this out first will eat everyone else's lunch. Not because they have better AI models, but because they'll build the right things.

Boris Cherny just validated fifteen years of FDE practice. The future belongs to builders who can think end-to-end, work embedded with customers, and see patterns others miss.

The tooling has changed. The principles haven't.