Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path →
A day in the life of
an FDE
A composite built from the published first-hand accounts — Palantir, PostHog, Baseten — and from the split frontier labs put in their own job descriptions. Three day shapes, because the honest answer to “what is a typical day” is that there are three of them and you rarely choose which one you get.
Day shape 1 — on the customer site
Week three of a deployment. You are in their building. This is the day people imagine when they hear "forward deployed" — and it is roughly a third of the calendar.
| Time | What happens | What is really going on |
|---|---|---|
| 08:40 | You arrive early and get pulled into a stand-up you were not invited to. | This is good. Being in the room is 80% of the trust-building, and you just learned that a system migration lands next month — which changes your integration plan. |
| 09:20 | Shadow an analyst doing the workflow by hand. | Discovery. She does two undocumented steps she never mentions in meetings because “everyone knows that”. One of them invalidates your data model. |
| 10:30 | Rework the mapping over coffee, on a laptop, in a corridor. | Ugly, hardcoded, correct on one real record. Speed over polish is not a slogan here; it is what keeps the loop tight. |
| 11:00 | The third source system returns 403 from inside their network. | Egress rules. Ninety minutes with their network team, most of it waiting. You use the waiting to write the eval that will define “working”. |
| 13:00 | Lunch with the champion. Not scheduled. | The highest-leverage hour of the week. You learn a VP is sceptical, and why. That reframes your next demo entirely. |
| 14:00 | Security questionnaire, 140 rows. | Nobody’s favourite. Doing it early instead of at the end is the difference between shipping and a great POC that IT vetoes in month four. |
| 15:30 | Demo the one-record prototype to three people. | Their reaction reshapes the scope. Five new “can it also…” requests, two of which reveal the actual problem. |
| 17:00 | Write it up: what changed, what you are not building, what you need by Friday. | The written trail is what makes the next scope conversation short instead of political. |
| 20:30 | Hotel. Fix the mapping properly, push, sleep. | The travel tax. Nabeel Qureshi’s account of four days a week on site for a year is the canonical version of this rhythm.14 |
Code written today: maybe two hours. If that number horrifies you, weigh it against the alternative: everything else on this list is what stops the two hours from being wasted on the wrong problem.
Day shape 2 — remote build day
The other two-thirds. Closer to a normal engineering day, with three interruptions that are not optional.
| Time | What happens |
|---|---|
| 09:00 | Triage overnight messages from two customers in other timezones. Answer the one that unblocks someone; schedule the rest. |
| 09:30 | Real building block. The retrieval pipeline over their document store, or the agent’s tool definitions, or the eval harness. This is the block you protect. |
| 12:00 | Internal sync: what you are seeing at the customer that the product should absorb. Roughly a third of the job at a frontier lab is exactly this feedback loop.10 |
| 13:00 | Second building block, usually the unglamorous half — retries, idempotency, the reconciliation job, the runbook. |
| 15:00 | Customer call. Weekly demo of whatever is working. Never skip it, even when there is little to show — the cadence is the trust. |
| 16:00 | Eval run against the golden set. Two regressions. One is a genuine bug, one is a labelling disagreement between their experts — which is a meeting, not a fix. |
| 17:00 | Write the generalisation note: what from this engagement should become a product capability. The rung-four habit that moves careers. |
16:00. “A regression that is actually a labelling disagreement” is the most FDE sentence there is: a technical signal whose resolution is a human negotiation. Handling that gracefully is the skill that separates senior from mid.
Day shape 3 — launch week
Two or three of these per engagement. Highest stress, highest payoff, and the day the previous six weeks get graded.
Pre-flight
Run the eval suite. Check the integrations against production data, not staging. Confirm the rollback path with someone who is awake. Print the demo script.
Training session with the users
Twelve people who did not ask for this tool. Half are curious, two are hostile, one will become your best advocate if you can find out what they care about in the first ten minutes.
The first real failure
A record shape nobody mentioned. It fails loudly in front of four people. What you do in the next sixty seconds — name it, scope it, commit to a time — determines whether trust goes up or down. Handled well, a visible fix builds more credibility than a flawless demo.
Executive readout
Answer first, evidence second. The number that moved, the adoption you can prove, the risks you are managing. Fifteen minutes, no live demo, no surprises.
Handoff planning
Who runs this in ninety days? What is in the runbook? What is still only in your head? The unglamorous work that prevents you owning this system forever.
How the mix shifts across a deployment
The frontier-lab framing of roughly 40% building / 30% customer / 30% internal feedback10 is a yearly average, not a weekly one. Inside a single engagement it swings hard:
| Phase | Building | Customer | Internal | The dominant activity |
|---|---|---|---|---|
| Discovery (wk 1–2) | 15% | 70% | 15% | Watching people work; starting the security review immediately. |
| Prototype (wk 2–5) | 60% | 30% | 10% | Weekly demos on their data; scope changing every time. |
| Integrate & harden (wk 5–12) | 65% | 20% | 15% | Their auth, their edge cases, evals, retries, runbooks. |
| Launch & hand off (wk 12+) | 25% | 45% | 30% | Training, adoption chasing, the generalisation memo. |
Two implications worth planning around. First, the discovery weeks feel unproductive and are the highest-leverage weeks of the engagement — engineers who measure themselves in commits suffer here. Second, the customer share rises again at the end, which surprises people who expect the job to get quieter after launch. It gets louder, because that is when real users arrive.
Run the day shapes as drills
Each of the hard moments above is a graded simulation here: the scoping call, the demo that fails live, the deployment-target decision, the rollout plan.
The picture: the weekly loop and the lane beside it
Worked example: where 14 weeks of hours go
Take the page’s phase table and run one engagement through it. Say discovery lasts 2 weeks, prototype 3, hardening 7 and launch 2, at 40 hours a week. That is 560 hours. The week counts are illustrative; the shares are the page’s.
| Phase | Hours | Building | Customer | Internal |
|---|---|---|---|---|
| Discovery (2 wk, 15/70/15) | 80 | 12 | 56 | 12 |
| Prototype (3 wk, 60/30/10) | 120 | 72 | 36 | 12 |
| Integrate & harden (7 wk, 65/20/15) | 280 | 182 | 56 | 42 |
| Launch & hand off (2 wk, 25/45/30) | 80 | 20 | 36 | 24 |
| Engagement total | 560 | 286 (51.1%) | 184 (32.9%) | 90 (16.1%) |
| At the yearly 40/30/30 | 560 | 224 | 168 | 168 |
| Gap | +62 | +16 | −78 |
Two things fall out. First, the engagement is build-heavy: 51% building, not 40%, because hardening is long and 65% build. Second, internal work comes out at 16%, about half the yearly figure, a gap of 78 hours. For the year to average 30% internal, those hours have to land somewhere else: between engagements, or in a protected weekly slot like the 12:00 sync and the 17:00 generalisation note. They do not happen on their own. And notice discovery: 12 hours of building in two weeks. That is the stretch that feels unproductive and sets up everything after it.
Cost and trade-offs: what each choice in the day buys
Here Time is what the choice costs you today, Space is what it buys or risks later, and Why is the reason to pay it.
| Case | Time | Space | Why |
|---|---|---|---|
| A day on site | About two hours of code, plus travel | The undocumented steps, the champion, the sceptical VP | None of these show up in a meeting or a ticket. |
| A remote build day | Two protected blocks, three fixed interruptions | Most of the actual system | Without the demo and eval run, the build drifts from what they need. |
| Security review in week 1 | An afternoon of a 140-row questionnaire | No veto from IT in month four | It runs on the customer’s clock, so start it first. |
| Weekly demo with little to show | 30 to 60 minutes, some awkwardness | The cadence, and with it the trust | Skip one and the next one has to carry two weeks. |
| Hardcode one record first | Throwaway code | A real reaction days earlier | The demo changes scope; build properly after it, not before. |
| The generalisation note | 30 minutes at the end of the day | A product capability, and a career step | It is the internal share the engagement never schedules for you. |
The pattern: almost every high-value item costs coding time. The job is deciding which code time to give up, and the cheapest thing to give up is building the wrong thing well.
Common mistakes
- Measuring the week in commits
In discovery, building is 15% of the time. An engineer who judges the week by commits will cut the shadowing short to get back to code, and miss the undocumented step that breaks the data model. Measure discovery by what you learned that changed the plan.
- Treating a labelling disagreement as a bug
When two experts label the same case differently, no code change fixes the regression. If you “fix” it, you have picked one expert’s answer without telling the other. Put both cases in front of them, agree a rule, write it down, then relabel.
- Building every “can it also” request
Five new requests after a demo are information, not a backlog. Usually two point at the real problem and three are curiosity. Write down which ones you are not building, and why, in that day’s write-up.
- Promising a fix time you cannot keep
When something fails live, naming it and scoping it is right. A guessed deadline that slips costs more trust than the failure did. Commit to when you will report back, not when it will be fixed, unless you already know the cause.
- Leaving the handoff for the last week
If the runbook gets written in launch week, it only covers what you remember then. Add to it as you go, every time you fix something by hand. Otherwise the only runbook is you, and you end up owning the system for good.
Where this shows up in interviews and offers
- “Walk me through a typical week”
A behavioural round will often ask this. A strong answer names the phase you were in and how the mix moved, the way the table above does. “Mostly coding” and “mostly meetings” both sound like someone who never ran an engagement end to end.
- The live-failure question
“A demo fails in front of the customer: what do you do?” is the 11:00 launch-week moment. Answer in the same order: name the failure, say how far it reaches, commit to a time, then say how you would stop it happening again.
- Reading a job description
A stated travel range and a building / customer / internal split, like the 40/30/30 on the frontier-lab posting this page cites, tell you which day shape you will mostly get. If a posting gives neither, ask what share of the time is on site.
- Judging whether it suits you
Work out how you would feel about week one of discovery: 12 hours of building in two weeks, in the example above. If that sounds like waste, a platform or product engineering role is probably a better fit. If it sounds like the interesting part, this role is.
Check yourself
It is week 3 and you have written almost no code. The customer’s network team has not opened egress yet. Is the engagement behind?
Not necessarily. Week 3 sits in the prototype phase, but the access work runs in its own lane on the customer’s clock. The question is whether you started it in week one. If you did, use the waiting the way the 11:00 entry does: write the eval that will define “working”. If you did not, that is the actual delay.
An eval run shows two regressions. One is a genuine bug, one is a labelling disagreement. Which do you take to the customer?
The labelling disagreement. The bug you fix and mention in the weekly demo. The disagreement needs their experts to agree a rule, and until they do, no version of your system can pass both labels. Fixing it alone just hides a decision that belongs to them.
Your engagement averages 51% building and 16% internal. Your manager expects 40/30/30 over the year. What do you change?
Schedule the internal share, because the engagement will not. In the example the gap is 78 hours over 14 weeks, about 5.6 hours a week. That is the 12:00 sync plus the 17:00 generalisation note on most days. Writing it down weekly beats one big memo at the end, which tends not to get written.
Three weeks after launch the customer messages you more, not less. Is something wrong?
Probably not. The launch phase is 45% customer time against 20% during hardening, because launch is when real users show up. What matters is whether the messages are new edge cases, which is expected, or the same question asked twice, which means the runbook or the training has a gap.
Quick answers
What does a forward deployed engineer do all day?
It depends which of three day shapes you are in. On a customer site: shadowing users, unblocking access and network issues, demoing, and roughly two hours of code. On a remote build day: two protected building blocks, an internal product-feedback sync, a weekly customer demo and an eval run. In launch week: training, live failures handled in public, an executive readout and handoff planning.
How much do forward deployed engineers actually code?
Roughly 40% of the time as a yearly average at a frontier lab, with 30% customer-facing and 30% carrying learnings back into the product. Inside a single engagement it swings widely — about 15% building during discovery weeks and 60–65% during prototype and hardening phases.
Do forward deployed engineers work at the customer office?
Often, but not exclusively. A common pattern is extended periods on site during discovery and launch phases with remote build days in between; published first-hand accounts describe four days a week on a customer site for a year during a deep engagement. Remote-first deployment organisations and internal platform roles travel much less.
What is the hardest part of an FDE day?
Two things recur in first-hand accounts: a technical signal whose resolution is a human negotiation — such as an eval regression that turns out to be two domain experts labelling the same case differently — and handling a live failure in front of the customer. Both are judged on how you frame and scope the problem in the first minute, not on the fix.
Sources
Every number on this page traces to one of these. Where a figure is self-reported or crowd-sourced rather than first-party, it is labelled inline.
Cited on this page
- Anthropic — Forward Deployed Engineer, Applied AI (JD) — 40/30/30 split; MCP servers, sub-agents and agent skills as deliverables. jobs.menlovc.com/companies/anthropic/jobs/69674588-forward-deployed-engineer-applied-ai
- Nabeel S. Qureshi — “Reflections on Palantir” — first-hand account of forward-deployed work, including the Airbus engagement. nabeelqu.co/reflections-on-palantir
- PostHog — “WTF is a forward deployed engineer?” — first-party account of the role at a product company, including travel reality. posthog.com/blog/forward-deployed-engineer
- Baseten — “What I learned as a forward deployed engineer at an AI startup” — www.baseten.co/blog/what-i-learned-as-a-forward-deployed-engineer-working-at-an-ai-startup/
- Palantir blog — a day in the life of an FDSE / Deployment Strategist — blog.palantir.com/
Explore the topic
See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.
More Handbooks
- The Agentic AI Interview HandbookTwenty topics every senior AI engineer should be able to reason about live — from eval pipelines to reliability patterns for generative systems.Read →
- The Senior AI Engineer Interview Handbook60 questions across architecture, production incidents, agentic systems, RAG, evals, cost, safety, and leadership — what staff-level AI interviewers actually probe for.Read →
- 50 Angular Interview QuestionsA visual handbook covering components, change detection, RxJS, signals, routing, forms, performance, and testing — what interviewers actually probe for in senior Angular roles.Read →
- 50 Python Interview QuestionsFundamentals to advanced: data structures, OOP, iterators & generators, the GIL, asyncio, memory, testing, and the standard library — a visual walk through everything a Python interview touches.Read →
- 51 LLM Evals Interview QuestionsGolden sets, LLM-as-judge, regression testing, offline vs online evals, RAG evals, agent evals, red-teaming, and observability — demystified for interviews and production.Read →
- The Agent Evaluations HandbookA self-contained handbook on evaluating AI agents — theory, interactive widgets, and practical guidance. Trajectory evals, tool-use scoring, LLM-as-judge, observability, and reliability for PMs, engineers, and founders.Read →