How to become a forward deployed engineer is less mysterious than LinkedIn makes it. You need a software engineering bar, a customer surface, and the discipline to build on platform primitives—not a mystical “AI aura.”
The perfect profile, in Bai’s public FDE 101 framing (Anthropic Applied AI; founding FDE at Rippling; ex-Palantir), is blunt: nothing more than a customer-facing software engineer. Hire as an SWE and trust them with a customer. That is the bar to aim at.
This guide is a practical path: decide if you want the job, raise the engineering floor, practice customer trust without quitting tomorrow, learn platform thinking, add agent deploy craft if that is your lane, interview cleanly, and survive the first 90 days without becoming a snowflake factory.
Step 0: decide if you want the job, not the title
FDE work includes:
- Incomplete requirements
- Security reviews
- Politics
- Production pressure
- Travel or intense remote customer time (varies)
- Saying “no” to work that should be product—and living with the tension
It also includes:
- Fast learning
- Visible impact
- Rare end-to-end ownership
- Direct line from field pain to platform improvement
If you want only model research or only pure product tickets, pick a different path. If you want only demos, pick SE. If you want permanent custom software with no productization duty, you want consulting—not FDE.
A quick self-test
Score yourself 0–2 on each:
- I enjoy incomplete problems more than I resent them.
- I can explain a system to an executive and to an SRE without lying to either.
- I ship code I would defend in review.
- I notice when work should be configuration, not a rewrite.
- I can leave a runbook and sleep.
- I care whether the next customer is cheaper than the last.
0–4: explore adjacent roles first.
5–8: build missing muscles deliberately.
9–12: you are already practicing FDE shape—package it.
Step 1: raise the engineering floor
You cannot fake this long-term.
Target: peer of a mid/strong product SWE at a serious company.
Concrete skills
- Ship production services with tests and observability
- Understand auth, networking, and failure modes
- Be comfortable in constrained environments (VPCs, proxies, locked laptops)
- Write clear design notes
- Participate in code review culture without drama
- Debug under time pressure without turning every incident into theater
How to close the gap if you are under-bar
| Gap | Practice project | Evidence for portfolio |
|---|---|---|
| Weak production experience | Own a small service end-to-end at work | Metrics, alerts, postmortem notes |
| Weak systems design | Design multi-tenant resource isolation on paper + spike | Written design + tradeoff table |
| Weak security instincts | Threat-model a tool-using agent | Data-flow diagram + controls list |
| Weak testing habits | Add golden-path evals to an automation | Eval suite that fails on regressions |
Do not “become FDE” by collecting agent demos. Become FDE by becoming someone product eng trusts with production.
Step 2: practice the customer surface without quitting your job
You do not need “consultant” on your résumé first.
High-signal practice inside a normal SWE job
- Own an internal tool used by non-engineers
- Run office hours for a platform your team builds
- Sit in on sales/SE calls and write postmortems on why deals stall
- Mentor support through hard escalations
- Lead a design partnership-style spike with a real stakeholder
- Write the handoff document you wish last quarter’s hero had left
Goal: be someone a non-engineer trusts when something is on fire.
Discovery practice drill (30 minutes)
Pick a messy internal process. Interview one operator. Produce:
- Outcome in their language
- Constraints (security, tools, politics)
- What already exists that you must assemble on
- What would make the second team’s version cheaper
- What you will refuse to custom-build
That drill is more FDE-shaped than another weekend chatbot.
Step 3: learn platform thinking
FDE without a platform is consulting. Study:
- What is configured vs developed
- What should be productized from field work
- How multi-tenant systems isolate blast radius
- How templates prevent 55 repos
- How atomic primitives should be for your user base (broad platforms trend more granular; vertical motions sometimes ship heavier pre-built assemblies)
Bai’s FDE 101 pedagogy is explicit: if each “FDE” builds entirely from scratch, you have a dev shop, not an FDE function. Maintenance and engineer retention lose first; finance loses second. The key ingredient is building on shared primitives.
Side project that trains the muscle
Build something small with shared primitives + per-tenant config. Even two “customers” (two configs) teaches the split:
- Shared: auth, runtime, logging, template
- Tenant A: policy, tools, credentials
- Tenant B: different policy and tools—same platform
Document:
- What is forbidden to copy-paste per tenant
- What the restore path is
- What you would productize after a third tenant appears
Platform vs customer decision table (memorize this)
| Signal | Move to platform | Keep customer-scoped |
|---|---|---|
| Second logo will need it | Yes | — |
| Encodes one org’s org chart | — | Yes |
| Changes multi-tenant safety | Yes (carefully) | Never as a one-off hack |
| One-off legacy connector | Maybe later | Yes initially |
| Harness install / host pattern | Yes | No snowflake hosts |
Step 4: add AI / agent deploy craft (if that is your lane)
If you want AI-native FDE roles, classic FDE skills are necessary but not sufficient. Agent products fail in specific, boring ways.
Five skills that separate demos from delivery
- Isolation models — shared-kernel containers vs microVMs; why credentials care about blast radius
- Always-on vs ephemeral — when sandboxes lie about long-running work
- BYOK — keys in the tenant boundary, not a shared hero laptop
- Eval harnesses — golden tasks after every change
- Restore and fork — bad days and next logos
Category failures to understand deeply (no vendor shopping required)
Laptop fleets. Great for spikes. Terrible for multi-customer production: batteries, airports, device loss, unreviewable secret sprawl.
DIY VPS snowflakes. Always-on possible; template culture optional. Without discipline you invent 55 hosts instead of 55 repos.
Shared-kernel density. Efficient packing; shared kernel risk classes. Acceptable for some low-trust workloads; stressful next to production keys.
Ephemeral sandboxes. Excellent for short code execution. Poor fit for always-on agents that need memory, schedules, and durable credentials.
Portfolio piece that beats ten chat screenshots
Build one multi-environment agent setup:
- Two isolated environments (“customers”)
- Separate credentials
- Persist that survives restart
- A restore drill you have actually run
- A template or fork path for environment three
- A one-page runbook a teammate can follow
- Three golden eval tasks that gate deploys
Harness choice can be whatever you ship with—Hermes, OpenClaw, Pi, or another stack—so long as the deploy craft is real.
Step 5: package your résumé and portfolio
Résumé lines that signal FDE shape
Prefer:
- “Shipped X to production; handoff owned by Y team; reduced Z”
- “Assembled on platform primitives A/B; generalized C for next account”
- “Designed isolation for multi-customer credentials”
Avoid:
- “Prompt engineered 50 demos”
- “Collaborated cross-functionally” with no artifact
- Tool laundry lists without outcomes
Portfolio structure (one page is enough)
- Problem and buyer outcome
- Constraints
- What you assembled vs invented
- Production evidence (monitoring, handoff, restore)
- What became reusable
- What you would do differently
If you cannot fill (4) and (5), keep practicing.
Step 6: interview like an FDE
Expect
- Coding equal to SWE screens
- System design with multi-tenant twists
- A customer scenario: messy stakeholder + incomplete data
- Security and production questions
- For agent roles: isolation, keys, always-on, eval
Ask them
- What platform will I build on in 90 days?
- What fraction of field work became product last two quarters?
- How are multi-customer credentials isolated?
- What stays up when a laptop closes?
- Who owns incidents after handoff?
- When did the team last refuse a snowflake request?
- How do multiple FDEs avoid single-person bus factor?
Walk if they cannot answer isolation and handoff.
Practice prompts (self-drill)
- A non-technical VP bought an agent platform for claims triage. Security wants a review in two weeks. Design discovery and a production path that is not a laptop demo.
- Three customers need “similar” GTM agents. Two share a CRM; one does not. Where do you put primitives vs config?
- An agent can send email. Design tool permissions, human gates, and audit.
- A bad model change ships. What is the restore story?
- Your manager wants billable customization that will never reappear. How do you push productization without being obstructive?
Step 7: first 90 days on the job
- Learn primitives and anti-patterns
- Shadow discovery calls
- Ship one production handoff
- Open two platform improvements from field pain
- Refuse one request that should be product—politely, with a path
- Write the isolation and key-custody story for your engagements
- Establish a multi-FDE notes habit so context is not trapped in your head
You are not measured by how many demos you run. You are measured by outcomes that survive you.
90-day anti-patterns
- Becoming the permanent on-site hero
- Building private stacks because “the platform is incomplete” without filing platform work
- Storing customer keys on personal devices “temporarily”
- Measuring yourself only by executive smiles
- Avoiding product eng because “they move too slow”
Incomplete platforms are normal early. Silent snowflake creation is not.
Common entry paths
| From | Leverage | Gap to close |
|---|---|---|
| Product SWE | Engineering depth | Customer entropy, discovery |
| SE / SA | Customer trust | Production ownership, code bar |
| Support / success + coding | Domain empathy | Systems design, platform discipline |
| Consulting | Delivery under chaos | Productization, refuse snowflake stacks |
| Research / ML eng | Model judgment | Production systems + customer surface |
If you are a founder hiring your first FDE
You still need the same two filters from FDE 101 pedagogy:
- Do you need the motion (technical product × non-technical buyer)?
- Do you have a platform—or a funded plan to invest in one?
Hiring a “rockstar” without primitives produces revenue that later becomes a liability.
How jurniti helps you practice the hard part
jurniti lets you run agent harnesses on Firecracker microVMs with BYOK, persist volumes, and templates. That is closer to multi-customer deploy craft than a single laptop agent—useful for portfolio work and for real delivery teams.
You remain the hero: choose the harness, own the outcome, write the runbook. jurniti is the managed isolation and always-on floor so practice time does not turn into a second full-time job of host ops.
No free trial or free tier. First purchase has a 30-day money-back guarantee if you evaluate a real plan while you skill up.
12-week skill plan (condensed)
| Weeks | Focus | Exit criteria |
|---|---|---|
| 1–3 | Engineering floor | Production PR + design note you are proud of |
| 4–5 | Customer surface | One discovery write-up with a real stakeholder |
| 6–7 | Platform thinking | Two-tenant config project + reuse rules |
| 8–10 | Agent deploy craft | Isolation + BYOK + restore drill documented |
| 11–12 | Interview packaging | Résumé, portfolio page, mock customer scenario |
Adjust intensity. Do not skip the engineering floor.
Get the free series
FDE 101 is a seven-day email sequence covering role, 2×2, primitives, agentic shift, and deploy craft.
Pricing when you want a real isolated box—30-day money-back on first purchase, no free tier.