Plan: Transitioning to Forward Deployed Engineer / AI Engineer

This is the third destination role in the transition series, next to ML engineer (closer to models and data) and AI infrastructure (closer to GPUs and serving). This one is closer to customers and applications: you build working systems on top of models rather than training them or serving them. Of the three, it has the heaviest overlap with what a product-minded backend engineer already does — and the most confusing job titles.

One role, four titles

Companies currently name this role at least four ways, and the names don’t map cleanly to differences in the work:

The common core, whatever the label: an engineer who takes a foundation model someone else trained and turns it into a system that works — RAG pipelines, agents, evals, integrations into real environments — often sitting close enough to the customer or the product to see it break. The center of gravity is the deployment edge, not the training run.

Two warnings that follow from the naming mess:

• Search all the titles. If you only search “AI Engineer” you’ll miss half the FDE postings and vice versa. Companies misuse these labels routinely (as of August 2026, some “AI Engineer” postings are ML engineer roles that train models, and some “Solutions Engineer” postings are pure pre-sales with no code).
• Classify by the JD body, not the title. The reliable signals:

Who this is for

A backend or full-stack engineer with 3+ years of production experience who can design and own services, integrate third-party APIs without hand-holding, and communicate clearly — but has only casual experience with LLMs (you’ve used the APIs, maybe built a toy). You want an FDE or AI Engineer role at a model lab, AI startup, or enterprise AI company within 3–6 months. This is the fastest of the three transitions because the model-side depth required is the shallowest.

What this plan assumes

• Baseline. You ship production code, you’re comfortable in at least one of Python/TypeScript, and you can talk to non-engineers without an interpreter. The customer-facing half of this role is a requirement, not a bonus — if you want zero customer contact, pick one of the other two transitions.
• Time commitment. ~120 hours across 3–6 months at ~6–8 hrs/week. Scales: 6 weeks at 20 hrs/week is the same plan, compressed.
• Goal. This is a plan to get hired building on models, not to become an ML engineer. You will not train a model in this plan. Conflating the two is how backend engineers spend six months on gradient descent for a role that never touches it.
• Scope. Four surfaces: the applied LLM stack, a deployed project, customer-facing craft, and the interview loop.
• Out of scope. Model training and fine-tuning beyond conceptual understanding, GPU serving internals, and classical ML (feature engineering, tabular models).

One assumption worth naming: this role is roughly 60% product engineering, 25% applied-model judgment (what the model can and can’t do, how to evaluate it), 15% consulting skill. Your backend experience covers the 60% almost entirely. The plan spends its hours on the other 40%.

The four surfaces

The plan

Phase 0: Decode the market and pick your flavor (~1 week, ~6 hours)

• Collect 5 real JDs across all four titles from companies you’d actually join. Classify each with the signal table above; discard the mislabeled ones. What remains is your target set.
• Pick your flavor. The role has two poles: product-side AI Engineer (one product, deep ownership, less travel) and field-side FDE (many customers, high ambiguity, often on-site). Same skills, different week-to-week life. Decide which you’re selling yourself as.
• Gap list. Highlight every requirement in your target set you can’t currently evidence. Typical list: RAG beyond a tutorial, evals, agent tool-use, a customer-facing story.

Milestone: a target set of real JDs, correctly classified, with a written gap list — and you can say which flavor you’re pursuing and why.

Phase 1: The applied LLM stack (~4–5 weeks, ~7 hrs/week)

Conversational competence plus working code, in this order:

1. Model APIs properly. Structured output, tool/function calling, streaming, context-window budgeting, prompt caching, batch vs real-time pricing. Read the Anthropic or OpenAI docs end to end — why these: primary sources; most third-party LLM tutorials lag the APIs by months and teach superseded patterns.
2. RAG beyond the tutorial. Chunking strategies, embedding choice, hybrid retrieval, reranking, and why naive RAG fails (retrieval quality, not generation, is usually the bottleneck). The RAG walkthrough covers the full architecture.
3. Evals — the differentiator. Golden sets, LLM-as-judge and its failure modes, regression evals in CI. Most candidates skip this; it’s the single strongest “has actually shipped” signal you can send. If you learn one thing deeply, make it this.
4. Agents and tool use. When an agent loop is justified vs a pipeline, tool design, guardrails, cost/latency budgets. The agent orchestration walkthrough is the systems view.
5. Fine-tuning, conceptually only. Know when it beats prompting + retrieval (rarely, for this role) and what it costs, so you can argue against it credibly in front of a customer who read a headline.

What to skip: training from scratch, RLHF details, GPU serving, LangChain-style framework deep-dives (frameworks churn; as of August 2026 the durable layer is the model APIs and the patterns, per What’s Durable vs What’s Hype).

Milestone: you can explain, in 30-second answers, why a RAG system retrieves garbage, how you’d eval a summarizer without labeled data, and when you’d refuse to build an agent.

Phase 2: The deployed project (~4–6 weeks, ~8 hrs/week)

The resume line. Same non-negotiables as the real LLM project guide — real data, a serving component, an eval methodology, deployed and linkable — with one FDE-specific addition: build it for a user who isn’t you. A tool for a friend’s business, a team at work, an open community — because the role’s core skill is translating someone else’s fuzzy need into a working system, and the interview will probe exactly that translation.

Strongest project shapes for this role: a RAG system over a messy real corpus with a written eval report; an agent that automates a real multi-step workflow with guardrails and a cost budget; or an internal AI tool at your current job with adoption numbers. Adoption numbers beat architecture diagrams in this loop.

Milestone: deployed project + write-up covering the user’s problem, the system, the eval results, and what you’d do next — discussable for 15 minutes under hostile questioning.

Phase 3: Customer-facing craft (~2–3 weeks, ~5 hrs/week, overlaps Phase 2)

The surface backend engineers most often can’t evidence. You need three demonstrable behaviors, not a personality transplant:

1. Discovery. Practice turning a vague ask (“we want AI for our support tickets”) into scoped requirements in a 30-minute conversation. Do this for real: offer two colleagues or small-business friends a free consult each. Write up what you scoped.
2. The demo. Rehearse a 10-minute demo of your Phase 2 project for a non-technical audience: problem, live walkthrough, what it can’t do. Saying what it can’t do is the credibility move in AI demos.
3. The war story. Prepare two stories where you navigated ambiguity or a difficult stakeholder. FDE behavioral rounds weight these as heavily as technical rounds.

Milestone: one recorded demo run-through you’d show a hiring manager, and two discovery write-ups.

Phase 4: The interview loop (~2–3 weeks, ~8 hrs/week)

As of August 2026 the typical loop:

The practical build round is the one with no SWE equivalent: you’ll be asked to ship something small but working, live or as a take-home, and judged on judgment — did you eval it, did you handle the failure cases, did you spend the time budget on what mattered.

Milestone: one timed mock build (3 hours, working feature with a minimal eval) and one mock design round.

Milestones by phase

Resources by surface

Applied LLM stack

• ai-engineer-notebooks — why this: the runnable companion to Phase 1 — Colab notebooks covering model APIs, RAG, evals, and agents in this plan’s order, framework-free.
• Anthropic docs / OpenAI docs — why these: the primary sources; the patterns pages (tool use, agents, evals) are the current best free curriculum for this role.
• AI Engineering — Chip Huyen. Why this: the one book scoped to building on foundation models rather than training them; the eval chapters alone justify it.
• Skip: framework-specific courses (LangChain, LlamaIndex) — learn patterns, not wrappers; and anything teaching you to fine-tune first.

Project & portfolio

• Building a Real LLM Project for Your Resume — the requirements bar and the anti-patterns (API-wrapper demos).
• RAG walkthrough and agent orchestration walkthrough — the two system shapes your project will most likely take.

Customer-facing craft

• The Trusted Advisor — Maister. Why this: the consulting-craft canon; read for the credibility/reliability/intimacy framing, skip the sales chapters.
• Palantir’s FDE description — why this: the origin of the role, straight from the source; read a live FDE posting to calibrate what “forward deployed” concretely means.

Interview loop

• The AI/ML System Design Interview — What’s Different — the design round’s framing; for this role, weight the application-layer parts over the training-pipeline parts.
• Skip: ML breadth question banks (bias-variance, boosting) — that’s the MLE loop, not this one. If a loop asks those, re-check the JD; you may be interviewing for a mislabeled MLE role.

What to cut if time is short

If you have 6 weeks: Phase 0 in two evenings. Phase 1 compressed to API docs + RAG + evals only — skip agents unless your target JDs demand them. Phase 2 becomes a smaller project: RAG over a real corpus with an eval report, deployed. Phase 3 folds into rehearsing one demo. Phase 4 is one week of mocks.

Never cut:

• The eval methodology. “I built a RAG app” is table stakes; “here’s the eval that told me my retrieval was the bottleneck” is a hire.
• The real-user constraint on the project. A tool built for yourself doesn’t evidence the role’s core skill.
• The demo rehearsal, for FDE-flavored roles. The loop tests it.

Cut without guilt:

• Agents, if your target JDs don’t mention them.
• Fine-tuning beyond one afternoon of reading.
• A second project. One with adoption beats two without.

Common failure modes

Preparing for the MLE loop by mistake. The naming chaos claims prep time too: you grind gradient boosting and bias-variance for a loop that will ask you to build a working RAG feature in three hours. Classify the JD first (§ One role, four titles), then prep for the loop that JD actually runs.

Shipping an API-wrapper demo. A chat UI over a model API with no eval, no error handling, and no real user signals “weekend hacker” in a loop that’s screening for production judgment. The bar is a system that survives hostile inputs and a written eval — see the project guide.

Hiding the backend experience. Transitioners undersell the exact thing that differentiates them. The market is full of prompt-first builders who can’t ship reliable systems; a backend engineer who can also do the model-judgment layer is the rarer profile. Lead with the production experience; frame the LLM skills as the new layer on top.

Ignoring the customer half. Engineers treat the discovery/demo rounds as soft filler and prepare zero evidence. For FDE roles these rounds are scored as hard requirements, and “I’ve never scoped work with a non-engineer” is a rejection. Two discovery write-ups and one rehearsed demo are cheap insurance.

Framework résumé-stuffing. Listing six LLM frameworks signals tutorial-following, not judgment. One deployed system with an eval, plus fluency in the raw model APIs, reads senior. The frameworks will have churned by your start date anyway.

Treating “it’s just prompting” as beneath you. The inverse failure: backend engineers who never develop real model judgment — what the model reliably can’t do, where structured output breaks, why the eval disagrees with the demo. The 25% model-judgment slice is small but it’s the slice the interview probes hardest.

After you land it

The first 90 days are about shipping something a customer or product team actually adopts — this role is judged on deployed outcomes faster than most. Your backend habits (observability, rollback plans, honest status updates) will read as unusual maturity. The growth path forks: product-side AI Engineers grow toward staff product engineering; field-side FDEs grow toward solutions architecture or founding teams. Revisit the promotion model once you’re in — scope and visibility accrue unusually fast in customer-facing engineering roles.