Training program / 12 weeks / 24 to 32 hours a week

Add forward deployed engineering skills to the expertise you already have.

For engineers and domain experts in R&D, quality and regulatory, clinical, supply chain, manufacturing, program management, software and digital teams. You already know the work and the customer. This program adds the skills to turn that knowledge into AI and software solutions a client approves.

What you will be able to do

  1. A1Understand the end-to-end processand spot where automation, AI or software would help
  2. A2Turn problems into requirementsa clear brief, acceptance criteria and a business case
  3. A3Design the solutionpick suitable technology and sketch the architecture
  4. A4Build and prove a POCworking software on realistic data, measured on real cases
  5. A5Present, get approval, hand overdemo to the client, agree next steps, move toward delivery

Your path through the program

Four parts, in this order. Start here once, work through the modules, practise on one real project as you go, and use the crash course whenever you want more depth.

  1. 1

    Start here

    Get the words and the tools right.

    Read the basics (what a model, an API, a harness and context are) and set up GitHub, VS Code and an AI coding assistant on your machine.

    About a week

    The basicsSet up your machine
  2. 2

    Modules

    Learn the FDE skills, one module at a time.

    Eleven modules from the FDE role to the final project. Each lesson has a diagram, a plain explanation, a worked example and practice.

    12 weeks

    Open module 01
  3. 3

    Practice

    Build one real project and prove each step.

    Pick your industry and a project, then work through 13 steps. Your evidence is saved to your GitHub journal, so your mentor sees real progress.

    Alongside the modules

    Open your learning path
  4. 4

    Crash course

    Go deeper on any topic, whenever you need to.

    431 checked videos, articles, courses and papers across systems, programming, data, cloud, security, AI and business. Start with the must-dos.

    As you need it

    Open the crash course

The 12 weeks: learn, build, prove

The 12 weeks in four stages. For each stage: what you learn, what you build, and how it is checked. Open any module to start its lessons.

Stage 1 / Weeks 1 to 4

Foundations

Learn
The FDE role, how LLMs work, and enough code, APIs, data and Git to build.
Build
Your learning journal, a prompt log and a small working script.
Prove
Week 2 knowledge check and week 4 skills check.
  1. 01The FDE role and the AI landscape

    Week 1 / 18-24 h

    A1

    You hand inA half page in your journal on the FDE loop applied to your own work.

    Checked byTutor step 01: the FDE loop applied to your project

  2. 02LLM foundations and AI fluency

    Weeks 1-2 / 24-30 h

    A3

    You hand inA prompt log with 10 tested prompts and a short note on failure patterns.

    Checked byWeek 2 knowledge check; AI Fluency certificate

  3. 03Building blocks: code, APIs, data and Git

    Weeks 2-4 / 30-42 h Track B

    A4

    You hand inA working repository with a README a colleague can run.

    Checked byWeek 4 skills check (domain track)

Stage 2 / Weeks 3 to 6

Understand the client

Learn
How the business makes money, discovery interviews, process maps and requirements.
Build
A sized business case, a process map and a one-page brief.
Prove
Week 6 discovery role-play with a mock client.
  1. 04Domain, business and market analysis

    Weeks 3-4 / 24-30 h Track A

    A1A2

    You hand inA two-page industry brief with a sized opportunity.

    Checked byWeek 4 industry brief (software track); rubric: problem framing

  2. 05Discovery and requirements capture

    Weeks 5-6 / 30-36 h

    A1A2

    You hand inDiscovery notes, a process map and a one-page brief, reviewed by the mock client.

    Checked byWeek 6 discovery role-play; rubric: discovery

Stage 3 / Weeks 6 to 9

Design and build

Learn
Solution options, security and cost, building the POC, and making it dependable.
Build
An options paper, a working POC and a list of how it handles failures.
Prove
Options review and the POC recording.
  1. 06Solution design and options

    Weeks 6-7 / 24-30 h

    A3

    You hand inA solution options paper with a recommendation and a one-page architecture.

    Checked byOptions review with a mentor; rubric: solution options

  2. 07Building the POC with LLMs

    Weeks 7-9 / 42-54 h

    A4

    You hand inA running POC in a repository, with a README and a two-minute screen recording.

    Checked byPOC repository and recording; rubric: build quality

  3. 08From demo to dependable: agentic system design and the FDE portfolio

    Weeks 8-9 / 30-36 h

    A3A4

    You hand inA step-by-step operating map, a failure-mode list with how each is handled, and a one-page portfolio write-up of your POC.

    Checked byFailure-mode list and portfolio write-up; rubric: evaluation and safety

Stage 4 / Weeks 9 to 12

Prove and hand over

Learn
Evaluation, deployment, demo craft and hand-over, then the final project.
Build
An evaluation report, a live URL, a demo, a hand-over pack and your final project.
Prove
Week 10 POC demo and the week 12 final review panel.
  1. 09Evaluate, deploy and operate

    Weeks 9-10 / 30-36 h

    A4

    You hand inAn evaluation report (before and after), a deployed URL and a short runbook.

    Checked byWeek 10 POC demo with evaluation results; rubric: deployment

  2. 10Product ownership, demo and hand-over

    Week 10 / 18-24 h

    A5

    You hand inDemo recording, a pilot proposal and a hand-over pack.

    Checked byMock steering demo; rubric: communication

  3. 11Final project: one client, one POC, end to end

    Weeks 11-12 / 60-75 h

    A1A2A3A4A5

    You hand inEverything in the project checklist, scored against the rubric.

    Checked byWeek 12 final review panel, full rubric

Where an FDE fits in the AI stack

AI runs on six layers. Most of the money goes into the bottom layers; most of what makes one company's AI different from another's is built in the top two. That is where the FDE works: choosing a model, then building the agent and observability layers so the client gets AI that fits, is safe, costs as little as possible, can be maintained and does what it was set up to do.

  1. Observabilitywatch, evaluate, governFDE builds here

    Records every step the system takes, scores the quality of its answers, catches problems before users do, and keeps the audit trail a regulator or an unhappy customer will ask for. Small layer, big consequences.

    LangSmith, Langfuse, Braintrust, Arize, Datadog, OpenTelemetry

  2. Agentdecide, call tools, actFDE builds here

    The logic around the model: routing, tools and their permissions, memory, retrieval, approvals and the loop that turns a model into something that does real work. Where the client's solution actually lives.

    Claude Agent SDK, OpenAI Agents SDK, Google ADK, LangGraph, Microsoft Agent Framework, MCP

  3. Modelweights and inferenceFDE chooses here

    The models themselves, plus the serving that turns them into answers at a price per token. Changes fastest and gets cheaper fastest.

    Anthropic, OpenAI, Google, Meta, Mistral, DeepSeek, Qwen; served by them or by clouds and hosts

  4. Computewho runs the machines

    Buys the chips, builds the data centers and rents capacity by the hour, or runs it privately. Where most of the money is spent.

    AWS, Microsoft Azure, Google Cloud, Oracle Cloud, CoreWeave, your own data center

  5. Siliconwho makes the chips

    Designs and manufactures the processors, memory and networking that everything else runs on. The hardest layer to enter.

    NVIDIA, AMD, TSMC, Samsung, SK Hynix, Micron; in-house chips such as Google TPU and AWS Trainium

  6. Energypower, grid, cooling

    Electricity, transmission and cooling for data centers. Now a real limit on how fast the rest can grow.

    Utilities and grid operators, power generators

What the FDE does, step by step

  1. Find the real jobThe process, the bottleneck, the measure
  2. Choose a suitable modelModel layer: right size for each step
  3. Build the agent layerCode, tools, data access, human approval
  4. Secure itLeast privilege, PII, injection, audit
  5. Keep cost downSmaller models, caching, batching
  6. Observe and evaluateTraces, evals, alerts, drift
  7. Hand over to maintainRunbook, owner, support model
The FDE does not train models or run data centers. They pick the right model and build, secure, measure and hand over the layers on top.

What a good solution looks like

  • SuitableThe right kind of AI for this job, or no AI where rules do better
  • SecureClient data protected, access limited, every action traceable
  • Least costSmallest model and fewest calls that still meet the measure
  • MaintainableSomeone else can run, fix and change it after you leave
  • Does the jobMeasured against the outcome it was set up to deliver

How an FDE works with a client

Every engagement, and every module in this program, follows the same loop: from "how does this work actually happen" to "a running solution the owner trusts".

  1. EmbedJoin the client team, meet the process owner and the people doing the work.
  2. DiscoverInterview, shadow, read documents and data; map the real process.
  3. FrameWrite the problem, the success measure and the business case.
  4. DesignLay out two or three options and recommend one.
  5. BuildShip a POC on realistic data with AI coding assistants.
  6. EvaluateTest on real cases; fix what fails; set human review.
  7. Demo and hand overShow the value, agree the next step, leave a runbook.

Who this program is for

Track A

Software and digital background

You can build. The program adds domain and business analysis, discovery, product ownership and communication. Fast-track Module 3 after a skills check.

Track B

Domain background

R&D, quality, regulatory, clinical, supply chain, manufacturing or operations. You know the work. The program adds code basics, APIs, data, AI-assisted building and deployment. Fast-track Module 4 after a skills check.

Learners work in mixed pairs, one from each track, so they teach each other and finish the final project together.

How your progress is checked

Three layers of evidence, so a learner, a mentor and a manager can all see the same progress.

1. Every step: the GitHub journal

In the tutor, each of the 13 steps saves evidence to the learner's own GitHub repository and must pass defined checks. A manager opens one link to see what is done.

2. Checkpoints with a mentor

  1. Week 2: knowledge check on LLM concepts and a prompt log review
  2. Week 4: track skills check: a small coding task (domain track) or an industry brief (software track)
  3. Week 6: recorded discovery role-play with a mock client
  4. Week 10: POC demo with evaluation results
  5. Week 12: final review panel: demo, questions, hand-over pack

3. Rubric and graduation

The panel scores seven dimensions as not yet, practitioner or FDE-ready. To graduate: FDE-ready in discovery, build quality, evaluation and safety, and communication, and at least practitioner in the rest.

See the full rubric
DimensionNot yetPractitionerFDE-ready
DiscoveryAsked mostly about features or opinions; process map has gaps.Captured the real process and pain from the last real cases; map is complete.Found the root problem and the hidden constraint; the client recognizes the map as their work.
Problem framing and valueSuccess is a feature list.Success is a measurable outcome with a baseline.Business case is sized, credible and agreed by the process owner.
Solution optionsOne option, no trade-offs.Two or three options with clear pros, cons and costs.Recommendation is defensible on accuracy, cost, risk and adoption; knows when not to use AI.
Build qualityWorks only on the demo case.Works on realistic data; code is readable and runs from the README.Clean, small, testable; another person can extend it in a day.
Evaluation and safetyNo test set.30+ cases, a pass rate and the top failures explained.Evaluation drives changes; human review and access limits match the risk.
Deployment and operationsRuns only on a laptop.Deployed behind access control with secrets handled properly.Tracing, cost tracking and a runbook; someone else could operate it.
CommunicationDemo is a tour of features.Demo starts from the client problem and shows real results.Handles hard questions calmly; states limits honestly; next step is agreed.

Choose a project to practice on

Pick a project from the industry you know or want to work in. You build it in the final two weeks, from discovery to demo. Filter by industry below, or find 86 more ideas in your path.

Industry:
Core

1. Invoice exception handling

Finance operations

Client
Accounts payable lead at a mid-size distributor. 3,000 supplier invoices a month; about 15% fail matching against purchase orders.
Pain
Clerks chase buyers by email, re-key data and miss early-payment discounts.
Data you get
50 sample invoice PDFs, a purchase order export (CSV), an email thread sample, the AP policy (PDF).

Deliver

  • Process map of the exception path
  • Extraction of invoice fields into JSON with a match check
  • Drafted exception summary and suggested resolution for a clerk to approve
  • Evaluation on 30+ invoices: extraction accuracy and correct routing

Tests: Document AI, rules plus LLM, human approval, business case

Core

2. Support ticket triage and reply drafting

Customer service

Client
Head of support at a software company. 1,200 tickets a week across email and chat.
Pain
Tickets sit unassigned; agents answer the same questions from scratch.
Data you get
500 anonymized tickets with categories, a help-center export, an SLA policy.

Deliver

  • Category and priority classifier with confidence
  • Reply drafts grounded in help articles, with citations
  • Routing rules and an escalation path
  • Evaluation: classification accuracy, groundedness of replies

Tests: Classification, RAG, citations, evaluation design

Stretch

3. Contract clause review

Legal and procurement

Client
Procurement manager who reviews 40 supplier contracts a month against a clause playbook.
Pain
Reviews take hours; risky clauses are missed when the team is busy.
Data you get
20 sample contracts (PDF), a clause playbook with preferred and fallback language.

Deliver

  • Clause extraction and comparison against the playbook
  • Risk flags with the exact contract text quoted
  • A review summary a lawyer approves before it is sent
  • Evaluation: recall of risky clauses on a labeled set

Tests: Long documents, quoting evidence, high-stakes review gates

Core

4. Maintenance work order assistant

Manufacturing

Client
Maintenance planner at a plant with 80 machines and paper-heavy work orders.
Pain
Technicians search manuals and old work orders to find fixes; downtime grows.
Data you get
Equipment list, 300 historical work orders (CSV), three machine manuals (PDF).

Deliver

  • Search across manuals and past fixes for a reported fault
  • Drafted work order with parts and steps, approved by the planner
  • A simple dashboard of repeat faults
  • Evaluation: usefulness rated by a mentor on 20 fault reports

Tests: RAG over manuals, structured drafts, operations data

Starter

5. HR policy assistant and onboarding checklist

Human resources

Client
HR business partner fielding the same questions from 400 employees.
Pain
Policy questions take time; new hires miss onboarding steps.
Data you get
Employee handbook (PDF), leave and travel policies, an onboarding checklist (spreadsheet).

Deliver

  • Policy Q and A with citations and a 'not sure, ask HR' fallback
  • A personalized onboarding checklist from a role and start date
  • Access rules: what the assistant must never answer
  • Evaluation: 40 questions with expected answers

Tests: Grounded Q and A, refusal behavior, privacy

Starter

6. Sales call notes to CRM updates

Sales

Client
Sales operations manager whose CRM is always out of date.
Pain
Reps do not log calls; forecasts are unreliable.
Data you get
20 call transcripts, the CRM field list, an opportunity stage definition.

Deliver

  • Extraction of next steps, stage, risks and contacts into CRM fields
  • A follow-up email draft for the rep to send
  • Change preview the rep approves before anything is written
  • Evaluation: field-level accuracy on 20 transcripts

Tests: Extraction to a schema, write-back with approval, adoption

Stretch

7. Quality deviation intake and triage

Regulated industries (life sciences, food, aerospace)

Client
Quality manager at a regulated manufacturer handling 100 deviations a month.
Pain
Intake is inconsistent; investigations start late; audit trail is weak.
Data you get
60 anonymized deviation reports, the deviation SOP, a risk classification matrix.

Deliver

  • Structured intake from free-text reports
  • Risk classification with the reasoning shown, capped at human approval
  • Investigation starter pack: similar past cases and suggested questions
  • Audit log of every AI suggestion and every human decision
  • Evaluation: agreement with quality specialists on 40 cases

Tests: Regulated workflows, audit trail, human-in-the-loop, validation thinking

Core

8. Device complaint intake and reportability flag

Quality and regulatory

Client
Complaint handling lead at a medical device maker. Complaints arrive as emails and call notes in many formats.
Pain
Handlers retype device, lot, event and patient details by hand and must judge quickly whether an event may be reportable.
Data you get
50 synthetic complaint emails written with an LLM, using public device event reports from the FDA MAUDE database as a style reference.

Deliver

  • Extraction of complaint fields into the complaint record format
  • A possible-reportability flag with the reason shown
  • A complaint specialist confirms every field and makes the reportability decision
  • Evaluation: field accuracy on 40 labeled emails and recall on potentially reportable ones

Tests: Extraction, regulated review gate, recall over precision

Core

9. Requirements to verification trace checker

R&D and design controls

Client
Design engineering lead preparing the design history file for a new device.
Pain
The trace matrix between design inputs and verification tests is built by hand, and gaps surface late in design reviews.
Data you get
A synthetic list of 60 design inputs and 70 verification test summaries for a simple device such as a home blood pressure monitor.

Deliver

  • Proposed links between each design input and its verification tests
  • A gap list: inputs with no test, tests with no input
  • The design engineer accepts or rejects every proposed link
  • Evaluation: precision and recall against a hand-built trace matrix

Tests: Matching, traceability, human acceptance of every link

Stretch

10. Clinical evaluation literature screening

Clinical affairs

Client
Clinical affairs reviewer updating a clinical evaluation report under EU MDR.
Pain
Hundreds of abstracts are screened by hand, each needing an include or exclude decision and a reason.
Data you get
200 public PubMed abstracts for one device type, with 100 labeled include or exclude and a reason.

Deliver

  • Include or exclude suggestion with a reason for each abstract
  • A screening log in the format the report needs
  • A clinical reviewer confirms every decision
  • Evaluation: agreement with reviewer labels and number of relevant papers missed

Tests: Classification with reasons, audit trail, high-recall screening

Starter

11. Supplier corrective action request drafting

Supply chain and manufacturing

Client
Supplier quality engineer handling rejected components from incoming inspection.
Pain
Each corrective action request is written by hand from inspection records and drawings, taking hours per case.
Data you get
20 synthetic incoming inspection nonconformance records and a synthetic supplier quality agreement.

Deliver

  • A drafted request with the defect, the requirement cited and the containment asked for
  • The engineer edits and approves before it is sent
  • Evaluation: reviewer score on 20 drafts and edit time per draft

Tests: Drafting from records, citing requirements, approval before sending

Every project hands in

  • Discovery notes and a process map reviewed by the mock client
  • One-page brief with the success measure and a sized business case
  • Options paper with a recommendation
  • Working POC in a repository with a README
  • Evaluation set of 30 or more cases with results and the top failures explained
  • Deployed URL behind access control
  • Ten-minute demo and a hand-over pack: runbook, owner, next step

Optional certifications

Optional, and never a substitute for the final project. Pick one or two that match your track and the platforms your clients use.

How each week runs

Every week follows the same rhythm, so learners always know what is expected and when. Read each lane left to right: it shows who does what across the week.

Who does what, day by day

  1. Learner: Mon: self-study, videos, reading
  2. Mentor: Tue: live session, worked example
  3. Pair: Wed: build the week's hand-in
  4. Mentor: Wed-Thu: office hours, unblock
  5. Mock client: Thu: answers questions as client
  6. Learner: Thu: commit evidence to journal
  7. Pair: Fri: show and tell to the group
  8. Reviewer: Fri: score on rubric, feedback
Mock clients join in discovery, demo and final project weeks. Everything a learner hands in is committed to their GitHub journal, so progress is visible to the mentor. On smaller screens, scroll sideways to see every step.

How we teach

  • Learn by doing: every week ends with something handed in and committed
  • Real material: messy documents, realistic data, real constraints
  • AI as tutor and tool: use it to explain, draft and code, then show your own reasoning
  • Evidence over opinion: every claim backed by an interview, a document or data
  • Feedback every week from a mentor and from peers

Who supports you

  • Program lead: owns cohorts, the plan and graduation decisions
  • Mentors: experienced engineers and consultants, one per four to six learners
  • Mock clients: domain experts who play the client in discovery, demos and the final project
  • Reviewers: score hand-ins and the final project against the rubric

The tools you will use, stage by stage

  1. Think and draftClaude, ChatGPT or Gemini
  2. BuildClaude Code, Cursor or Copilot; Python; Git
  3. ConnectAPIs, MCP servers, n8n
  4. EvaluateA test set; tracing with Langfuse
  5. DeployCloudflare, AWS, Azure or Google Cloud
  6. ShowDiagrams, a recording, a live demo
Learners pick one tool per stage to start; the program does not depend on any single vendor.