Who already has a head start
Most people who do this well arrive from one of three backgrounds: product and software engineering, solutions engineering or consulting, or a founder background.
Product engineers bring the ability to ship into a real codebase. Solutions engineers and consultants bring the customer-facing instinct. Founders bring judgment about what is worth building. You do not need all three. You need to be honestly strong in one and willing to build the others.
The path, step by step
- Get genuinely good at shipping software. The role is product engineering first. If you cannot ship a feature into a real codebase with edge cases and error states, start there.
- Use frontier models every day. Work with the current Anthropic and OpenAI models until their behavior is intuitive. Adopt an agentic coding tool like Claude Code as your default way of building.
- Learn prompt and context design. Reliable output is an engineering problem: system prompts, retrieved context, structured outputs, and guardrails. Treat it like code, not like magic words.
- Learn to connect models to real systems. Understand the Model Context Protocol (MCP) and how to wire a model into a customer's data and tools safely.
- Build one narrow workflow, end to end. Pick a real use case with a named user, a clear input, and a clear output. Ship it inside a real product or a convincing clone. Narrow beats ambitious.
- Write the evaluation rubric. Define what good output looks like on a simple scale and score against it. This discipline is what separates an engineer from someone who got one lucky demo.
- Develop customer-facing judgment. Practice scoping under pressure, saying no to the wrong workflow, and protecting a fixed timeline. The hardest skill is resisting the pull of a vague request.
- Show the work. Record a short walkthrough of the code, the prompts, and the rubric. Being able to defend every decision out loud is the real credential.
What to study, and what to skip
Study product engineering, prompt and context design, data integration, and evaluation. You can skip the machine learning research track. The role applies existing models; it does not train them.
A research or MLOps background is useful in some engagements, but it is not the entry requirement, and chasing it first is the most common way to delay the thing that actually gets you hired: a shipped workflow.
Go deeper
The book
Forward Deployed AI Engineering: A Working Guide to the Hottest Job in Software covers the full path in depth, including a part on becoming an FDE, plus a workbook. It is written from inside the work.
Related
Frequently asked questions
What background do most Forward Deployed AI Engineers come from?
Three backgrounds are most common: product or software engineers who can ship into a real codebase, solutions engineers and consultants who already work with customers, and ex-founders who have built and sold something. The shared trait is the ability to ship and to make decisions in front of a customer.
How long does it take to become a Forward Deployed AI Engineer?
If you can already ship software, the AI-specific layer (prompt and context design, model integration, evaluation) takes weeks of focused practice, not years. The honest gate is not study time. It is whether you have shipped one real AI workflow end to end and can defend every decision in it.
What should I build to prove I can do the work?
Build one narrow workflow with a named user, a clear input, and a clear output, inside a real product or a convincing clone. Ship it, write an evaluation rubric for it, and record a short walkthrough of the code and prompts. That single artifact is more persuasive than any certificate.