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.

Five abilities you will build

  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

Before you start: read the basics, set up your machine, then follow your own path in the tutor, which saves your progress to your GitHub journal. The crash course library lists the best free material for every topic, in the order to take it.

The basicsSet up your machineYour path (tutor)Crash course library

The AI stack, and where the FDE works

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 across those layers

  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.

The FDE goal

  • 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

The FDE loop

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 it 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.

Program map

Each module builds one or more of the five abilities, ends with something you hand in, and has a defined check. Follow a row to see where an ability is built and how it is proven.

Both tracks Track A software-background focus Track B domain-background focus

#ModuleWhenBuildsYou hand inAssessed by
--Before week 1: the basics and machine setupBefore week 1A GitHub learning journal with a first commitTutor steps A and BBasics / Setup
01The FDE role and the AI landscapeWeek 1
18-24 h
A1A half page in your journal on the FDE loop applied to your own work.Tutor step 01: the FDE loop applied to your projectLessons
02LLM foundations and AI fluencyWeeks 1-2
24-30 h
A3A prompt log with 10 tested prompts and a short note on failure patterns.Week 2 knowledge check; AI Fluency certificateLessons
03Building blocks: code, APIs, data and Git Track BWeeks 2-4
30-42 h
A4A working repository with a README a colleague can run.Week 4 skills check (domain track)Lessons
04Domain, business and market analysis Track AWeeks 3-4
24-30 h
A1A2A two-page industry brief with a sized opportunity.Week 4 industry brief (software track); rubric: problem framingLessons
05Discovery and requirements captureWeeks 5-6
30-36 h
A1A2Discovery notes, a process map and a one-page brief, reviewed by the mock client.Week 6 discovery role-play; rubric: discoveryLessons
06Solution design and optionsWeeks 6-7
24-30 h
A3A solution options paper with a recommendation and a one-page architecture.Options review with a mentor; rubric: solution optionsLessons
07Building the POC with LLMsWeeks 7-9
42-54 h
A4A running POC in a repository, with a README and a two-minute screen recording.POC repository and recording; rubric: build qualityLessons
08From demo to dependable: agentic system design and the FDE portfolioWeeks 8-9
30-36 h
A3A4A step-by-step operating map, a failure-mode list with how each is handled, and a one-page portfolio write-up of your POC.Failure-mode list and portfolio write-up; rubric: evaluation and safetyLessons
09Evaluate, deploy and operateWeeks 9-10
30-36 h
A4An evaluation report (before and after), a deployed URL and a short runbook.Week 10 POC demo with evaluation results; rubric: deploymentLessons
10Product ownership, demo and hand-overWeek 10
18-24 h
A5Demo recording, a pilot proposal and a hand-over pack.Mock steering demo; rubric: communicationLessons
11Final project: one client, one POC, end to endWeeks 11-12
60-75 h
A1A2A3A4A5Everything in the project checklist, scored against the rubric.Week 12 final review panel, full rubricLessons

How progress is assessed

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

Certifications

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

CertificationIssuerWho it is forFormatTrack
Anthropic Academy course certificatesAnthropicEveryone. Free completion certificates for Claude API, Claude Code and MCP courses.Course certificateBoth tracks
AWS Certified AI Practitioner (AIF-C01)Amazon Web ServicesDomain track. Foundational AI and generative AI concepts on AWS.Proctored examTrack B
AWS Certified Cloud Practitioner (CLF-C02)Amazon Web ServicesDomain track. Cloud basics, pricing, security model.Proctored examTrack B
Microsoft Certified: Azure AI FundamentalsMicrosoftEither track, for teams working on Azure.Proctored examBoth tracks
Google Cloud Generative AI LeaderGoogle CloudEither track. Business-level generative AI strategy and adoption.Proctored examBoth tracks
Professional Scrum Product Owner I (PSPO I)Scrum.orgSoftware track. Product ownership and backlog value.Online assessmentTrack A
Certified Scrum Product Owner (CSPO)Scrum AllianceAlternative to PSPO I, course-based.Course + certificateTrack A
Entry Certificate in Business Analysis (ECBA)IIBASoftware track. Requirements and business analysis fundamentals.Proctored examTrack A
PMI Certified Professional in Managing AI (PMI-CPMAI)Project Management InstituteEither track, for people who will lead AI delivery.Proctored examBoth tracks
GitHub certifications (Foundations, Copilot)GitHubDomain track. Version control and AI-assisted coding.Proctored examTrack B
Databricks Certified Generative AI Engineer AssociateDatabricksSoftware track, advanced. Building LLM applications on a data platform.Proctored examTrack A

How it 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.

A typical week

  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.

Principles

  • 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 runs it

  • 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

Tools learners use, in the order they need them

  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.