GenAI4Code
AI EngineeringDetailed student curriculum · public

AI Engineering syllabus

All 12 weeks, in full: what you learn, what you build, what you hand in, and how the work is checked. Read it before you decide anything — no signup, no email, no gate.

12 weeks · about 10 hours per week including practice 3 hours Saturday + 3 hours Sunday live (72 live hours) Project-led, one recurring project spine

Capabilities you leave with

Five things a learner can do unaided at the end, each one rehearsed in a lab and proved in a deliverable.

  1. 01Frame a problemdefine users, tasks, data, constraints, baselines, and success measures before selecting a model.
  2. 02Build model-backed features using APIs, prompts, schemas, validation, and application code.
  3. 03Ground and retrieve knowledge by preparing documents, building retrieval pipelines, citing evidence, and evaluating answer support.
  4. 04Control AI actions by connecting models to bounded tools and workflows with explicit permissions and human approvals.
  5. 05Operate and improve by deploying, tracing, monitoring, evaluating, and managing quality, latency, cost, and failure recovery.

Your working environment

What a learner actually opens each week. The tooling changes; the habits do not.

  • Python
  • Git and GitHub
  • Model APIs
  • Pydantic/FastAPI
  • Vector search
  • Docker
  • Kubernetes

The 12 weeks

Every week follows the same loop: understand the idea, test it in a guided lab, build the deliverable, then improve it with evidence. Later weeks assume the earlier ones, and the project carries forward.

Week 01

Programming foundations for AI systems

Write small, readable programs and use the developer workflow that later AI services depend on.

10 h7 lesson topics4 tools

Lesson outline · 7 topics

  1. Python values, variables, strings, numbers, lists, dictionaries, loops, and conditionals
  2. Functions, parameters, return values, modules, exceptions, and reusable code
  3. Reading and writing JSON
  4. Files and tabular data with introductory Pandas
  5. Command line, virtual environments, package installation, notebooks, and IDE basics
  6. Git commits, branches, repository structure, README files, and responsible secret handling
  7. How a browser, an API, a server, and a database exchange a request and a response

Core concepts

  • Values, collections, loops, and conditionals as the vocabulary of a program
  • Functions, modules, and exceptions: how a program is structured and how it fails
  • Files, JSON, and tabular data: getting real input into a program
  • The working environment: terminal, environments, Git, and secrets handled responsibly
  • How a request travels: browser, API, server, and database

Guided lab

Build a command-line product-data checker: load a small CSV or JSON file, normalize text, find missing fields, and write a clean report with functions, tests, and a README.

Weekly deliverable

A small Python project in GitHub with sample input, readable code, basic tests, and setup instructions.

Tools and environment

  • Python
  • Jupyter or an IDE
  • Terminal
  • Git and GitHub

How you demonstrate learning

  • Correct output on known inputs
  • Clear function boundaries
  • Sensible handling of missing or invalid values
  • Reproducible setup

Quality checks in practice

  • One script that mixes parsing, business rules, and output is hard to debug; separate functions and test them
  • Never commit credentials, and do not assume a program works because it ran once
01Learn5 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review4 evidence checksWeek 01 · estimated 10 hours · Python / Jupyter or an IDE / Terminal / Git and GitHub
How week 1 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 02

AI, ML, GenAI, data, and model choices

Understand what a generative model can do, what it cannot guarantee, and how to select a model for a real task.

10 h8 lesson topics4 tools

Lesson outline · 8 topics

  1. AI, machine learning, deep learning, and generative AI: definitions, relationships, and examples
  2. Supervised, unsupervised, and reinforcement learning at a practical level
  3. LLM overview: tokens, next-token prediction, context window, inference, and generation settings
  4. Training stages: pretraining, instruction tuning, and preference alignment
  5. Distinguishing training from inference, and why the difference changes your architecture
  6. Hosted APIs, open-weight models, and small language models: access, customization, and control
  7. Model choice: task quality, latency, cost, privacy, license, hardware, and language support
  8. Data and risk: training and evaluation data, bias, privacy, intellectual property, and misuse

Core concepts

  • AI, machine learning, deep learning, and generative AI: how the terms relate
  • How a model is trained, and how inference differs from training
  • Hosted APIs, open weights, and small models: access, control, and cost trade-offs
  • Choosing a model for a task: quality, latency, cost, privacy, license, and hardware

Guided lab

Run the same extraction or summarization task with two model approaches and record quality, latency, cost assumptions, privacy considerations, and limits.

Weekly deliverable

A one-page model selection memo naming the task, baseline, constraints, chosen approach, and risks.

Tools and environment

  • Hosted model APIs
  • Model cards
  • A small evaluation set
  • Spreadsheet or notebook

How you demonstrate learning

  • Selection matches the task
  • Trade-offs are explicit
  • Open weights distinguished from open source and from free access

Quality checks in practice

  • A leaderboard score does not predict performance on your task
  • Open weights do not automatically mean unrestricted commercial use or low operating cost
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review3 evidence checksWeek 02 · estimated 10 hours · Hosted model APIs / Model cards / A small evaluation set / Spreadsheet or notebook
How week 2 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 03

Prompt and context engineering

Design prompts and context so outputs are specific, testable, and appropriate for a defined task.

10 h9 lesson topics3 tools

Lesson outline · 9 topics

  1. Message roles and instruction hierarchy
  2. Task, input, constraints, examples, and output format in one prompt
  3. Zero-shot and few-shot prompting: when examples help and how they bias output
  4. Context selection, ordering, and length
  5. The long-context lost-in-the-middle problem
  6. Structured instructions, delimiters, and safe context boundaries
  7. Prompt injection awareness and handling untrusted text
  8. Prompt variants, versioning, A/B comparisons, and regression checks
  9. Reasoning patterns as task design, and why hidden traces are not evidence

Core concepts

  • Instruction hierarchy: what the system, developer, and user each control
  • How context shape changes output reliability
  • Prompt versioning, test sets, and regression checks as an engineering habit
  • Untrusted text and prompt injection boundaries

Guided lab

Create a prompt test matrix for product-attribute extraction covering normal, ambiguous, incomplete, and adversarial inputs, then compare prompt versions against a rubric.

Weekly deliverable

A versioned prompt pack with test inputs, expected properties, and comparison results.

Tools and environment

  • Model playground or API
  • JSON or CSV test set
  • Git

How you demonstrate learning

  • Prompt is clear and scoped
  • Edge cases are included
  • Changes are compared on the same examples rather than judged by one output

Quality checks in practice

  • A prompt can look reliable on one example and fail on varied inputs
  • Treat retrieved or user-supplied text as untrusted input; it must not silently override system rules
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review3 evidence checksWeek 03 · estimated 10 hours · Model playground or API / JSON or CSV test set / Git
How week 3 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 04

Model APIs and reliable structured outputs

Connect an application to a model API and validate every output before application code uses it.

10 h10 lesson topics4 tools

Lesson outline · 10 topics

  1. HTTP request and response structure: endpoints, headers, payloads, status codes, JSON
  2. API keys, environment variables, secret managers, access scope, and rotation
  3. Structured output schemas, nested types, and optional versus required fields
  4. Pydantic models and custom validation
  5. Streaming versus batch, and synchronous versus asynchronous calls
  6. Concurrency and back-pressure basics
  7. Timeouts, retries with exponential backoff, and rate-limit handling
  8. Quota handling, caching, and idempotency
  9. Token budgets, usage records, latency, and cost-aware request design
  10. Fallback behaviour for malformed, incomplete, refused, or unavailable responses

Core concepts

  • The HTTP request and response contract for model calls
  • Structured output schemas and validation before application code
  • Failure paths: timeouts, retries, rate limits, quotas, and malformed responses
  • Secrets, scope, rotation, and cost-aware request design

Guided lab

Implement a product-attribute endpoint that validates outputs, rejects invalid fields, retries transient errors, and has tests for malformed JSON and rate-limit responses.

Weekly deliverable

A model-backed extraction endpoint with schema validation, error handling, and a small test suite.

Tools and environment

  • Python
  • Model API
  • Pydantic
  • FastAPI or equivalent

How you demonstrate learning

  • Schema pass rate and field accuracy
  • Failure paths behave as documented
  • No hard-coded credentials
  • Tests are reproducible

Quality checks in practice

  • Valid JSON can still contain incorrect or unsafe values
  • Retry transient failures selectively; blind retries raise cost and can repeat side effects
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review4 evidence checksWeek 04 · estimated 10 hours · Python / Model API / Pydantic / FastAPI or equivalent
How week 4 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 05

Conversational interfaces, state, and memory

Build a conversation that keeps the information the task needs without carrying unnecessary or unsafe history.

10 h9 lesson topics3 tools

Lesson outline · 9 topics

  1. Chat message structure and the request lifecycle
  2. System, developer, user, and tool roles as supported by a provider
  3. Conversation state: session IDs, turns, persistence, and storage
  4. Separation between users, tested rather than assumed
  5. Short-term context, summarized history, retrieved knowledge, and persistent memory
  6. Context-window management, truncation, and summarization
  7. User correction, conversation reset, and deletion
  8. Privacy boundaries and consent for stored information
  9. Conversation tests: turn-by-turn behaviour, state leakage, repeated questions, conflicts

Core concepts

  • Conversation state as a design choice, not a side effect
  • Short-term context, summaries, retrieved knowledge, and persistent memory
  • Privacy boundaries: retention, reset, deletion, and separation between users
  • Testing conversation behaviour turn by turn

Guided lab

Build a small product-support chat flow that remembers the current task, summarizes older turns, and lets the user reset the session.

Weekly deliverable

A conversational prototype with explicit state handling and tests for session isolation and reset.

Tools and environment

  • Python or TypeScript
  • Model API
  • SQLite or another simple store

How you demonstrate learning

  • Relevant context is retained and unrelated history is dropped
  • Sessions do not leak
  • Reset and deletion behave as described

Quality checks in practice

  • Keeping the entire chat forever exposes private data and wastes context
  • Summaries lose important details; test resets, deletion, and separation between users
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review3 evidence checksWeek 05 · estimated 10 hours · Python or TypeScript / Model API / SQLite or another simple store
How week 5 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 06

RAG foundations and semantic search

Answer questions from a document collection by retrieving useful evidence and grounding the response in it.

10 h9 lesson topics4 tools

Lesson outline · 9 topics

  1. Ingestion pipeline: parse, normalize, split, enrich metadata, index, update, delete
  2. Chunking choices: fixed size, semantic boundaries, overlap, tables, and document structure
  3. Embeddings and vector similarity
  4. Lexical search such as BM25, and metadata filtering
  5. Retrieval-generation flow: query processing, top-k retrieval, and context construction
  6. Citations and source attribution
  7. Grounded answers, abstention, and no-answer behaviour
  8. How retrieval differs from knowledge stored in model weights
  9. Evaluation: retrieval recall and precision, answer correctness, and citation support

Core concepts

  • The ingestion pipeline from raw document to retrievable evidence
  • Chunking and embedding choices, and how they fail
  • Retrieval, context construction, and citation of sources
  • Evaluating retrieval and answers instead of trusting them

Guided lab

Index policy and product-guideline documents, test queries with known relevant passages, inspect retrieved chunks, then generate cited answers.

Weekly deliverable

A RAG assistant with source metadata and a repeatable retrieval and answer evaluation set.

Tools and environment

  • Document parser
  • Embeddings API or model
  • Vector index
  • Python

How you demonstrate learning

  • Relevant evidence appears in the retrieved results
  • Generated claims are supported by the cited sources
  • Unsupported questions trigger a safe response

Quality checks in practice

  • Poor parsing or chunk boundaries can defeat a good embedding model
  • Similarity scores rank results; they are not calibrated probabilities that an answer is correct
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review3 evidence checksWeek 06 · estimated 10 hours · Document parser / Embeddings API or model / Vector index / Python
How week 6 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 07

Advanced retrieval, ontologies, and GraphRAG

Choose graph-based knowledge only where explicit relationships, constraints, or multi-hop questions improve the task.

10 h9 lesson topics3 tools

Lesson outline · 9 topics

  1. Knowledge graph elements: entities, types, properties, edges, provenance, identifiers
  2. Ontology basics: classes, subclass relationships, properties, domain and range, constraints
  3. Graph structure versus chunks and embeddings
  4. Graph traversal versus vector similarity
  5. GraphRAG patterns: entity linking and neighbourhood retrieval
  6. Multi-hop questions and graph-plus-text evidence
  7. Hybrid retrieval: lexical, vector, graph, metadata filters, and reranking
  8. Graph quality risks: extraction errors, duplicate entities, stale edges, unsupported inference
  9. Decision criteria: when a relational database or a metadata filter is sufficient

Core concepts

  • Graphs and ontologies: entities, edges, provenance, and constraints
  • When relationships beat similarity, and when they do not
  • Multi-hop retrieval with graph plus text evidence
  • Hybrid retrieval and graph quality risks

Guided lab

Model product, attribute, guideline, and category relationships, then answer a multi-hop question with graph context and compare it against vector-only retrieval on the same test set.

Weekly deliverable

A small domain graph and a comparison report showing where graph retrieval helps and where it does not.

Tools and environment

  • Graph representation or graph database
  • Retrieval code
  • Python

How you demonstrate learning

  • Correct entity and edge links
  • Traceable source provenance
  • Measured benefit on the selected questions
  • Clear statements of the limits

Quality checks in practice

  • A graph adds maintenance work when the task has no useful relationships or multi-hop questions
  • Incorrect entities or edges create confident but unsupported paths; preserve source provenance
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review4 evidence checksWeek 07 · estimated 10 hours · Graph representation or graph database / Retrieval code / Python
How week 7 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 08

Tools, workflows, agents, and MCP

Let a model request bounded actions while application code controls permissions, validation, execution, and recovery.

10 h12 lesson topics4 tools

Lesson outline · 12 topics

  1. Function calling: names, descriptions, typed arguments, validation, and results
  2. Error contracts for tools
  3. Workflow versus agent: fixed sequence and explicit rules versus model-directed actions
  4. State, routing, and conditional edges
  5. Retries, stop conditions, and bounded loops
  6. Agent orchestration patterns with a workflow or graph framework
  7. MCP concepts: client, server, tools, resources, and prompts
  8. Connecting an agent to external capabilities
  9. Security: least privilege, allowlists, input validation, and injection boundaries
  10. Approval gates and audit logs
  11. Asynchronous and parallel calls, timeouts, idempotency, and fallback behaviour
  12. Human escalation

Core concepts

  • Tool contracts: typed arguments, validation, and error handling
  • Workflow versus agent, and why the simpler one usually wins
  • State, routing, retries, stop conditions, and bounded loops
  • Permissions, approval gates, audit logs, and human escalation

Guided lab

Build a catalogue assistant that retrieves a guideline, drafts an attribute correction, and requests human approval before any write action.

Weekly deliverable

A bounded tool-using workflow with schemas, an approval step, a failure path, and an inspectable execution trace.

Tools and environment

  • Model tool calling
  • Python or TypeScript
  • Workflow framework
  • MCP-compatible tools where useful

How you demonstrate learning

  • Tool arguments are valid
  • No unauthorized side effects
  • Stop conditions are clear
  • The trace shows request, result, and approval state

Quality checks in practice

  • A model suggestion is not authorization to execute a tool
  • Use stop conditions, timeouts, validation, least privilege, and approval for consequential writes
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review4 evidence checksWeek 08 · estimated 10 hours · Model tool calling / Python or TypeScript / Workflow framework / MCP-compatible tools where useful
How week 8 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 09

Application integration and AI-assisted coding

Connect the AI capability to a usable product interface and use coding assistants as reviewed engineering tools.

10 h9 lesson topics4 tools

Lesson outline · 9 topics

  1. Application boundaries: UI, backend API, model layer, retrieval service, and persistent data
  2. REST API contracts and request validation
  3. Authentication basics and user or session isolation
  4. Error messages that a user can act on
  5. Frontend and backend integration in a small application
  6. Database choices for application state, product records, vectors, and graph relations
  7. Assistant-assisted workflow: clarify, plan, generate, inspect the diff, test, revise
  8. Reviewing generated code: types, edge cases, dependencies, secrets, license, security
  9. Why every generated change is reviewed and tested before it merges

Core concepts

  • Application boundaries: UI, API, model layer, retrieval, and storage
  • API contracts, validation, authentication, and user isolation
  • Assistant-assisted workflow with review of every change
  • What generated code still gets wrong, and why review is the job

Guided lab

Build one vertical slice: a user submits a product record, the backend calls the extraction service, and the UI displays validated fields and lets the user correct them.

Weekly deliverable

A working application slice with a UI, an API contract, validation, and a test or review record.

Tools and environment

  • TypeScript with React or equivalent
  • Python with FastAPI or Node
  • GitHub
  • A coding assistant

How you demonstrate learning

  • The end-to-end task completes
  • Errors are understandable
  • Generated code is reviewed and tested
  • User data is isolated

Quality checks in practice

  • Generated code can compile and still mishandle permissions, edge cases, or sensitive data
  • Review the diff, the dependency changes, and the tests before merging or deploying
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review4 evidence checksWeek 09 · estimated 10 hours · TypeScript with React or equivalent / Python with FastAPI or Node / GitHub / A coding assistant
How week 9 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 10

Deployment, security, and production operations

Deploy the system with enough controls and visibility to diagnose problems and keep usage within limits.

10 h12 lesson topics5 tools

Lesson outline · 12 topics

  1. Configuration separation, environment variables, and secrets
  2. Containers, deployment targets, and rollback
  3. Authentication and authorization boundaries
  4. Data minimization, personal-data handling, retention, and redaction
  5. Observability: request IDs, model and tool traces, latency, token use, and errors
  6. Retrieval results and user feedback as monitoring signal
  7. Operational quality: budgets, quotas, rate limits, caching, and circuit breakers
  8. Security threats: prompt injection, unsafe tool inputs, insecure output rendering
  9. Data exposure and dependency risk
  10. Monitoring quality across prompts, models, data, and releases
  11. Versioning and regression checks
  12. Human review and escalation for low-confidence or high-impact actions

Core concepts

  • Configuration, secrets, containers, and rollback
  • Observability that answers a real question during an incident
  • Operational limits: budgets, quotas, caching, and graceful degradation
  • Security, data handling, and human escalation for high-impact actions

Guided lab

Deploy the catalogue workflow to a staging environment with Docker and Kubernetes, then trigger a timeout, an invalid output, and a low-retrieval case and demonstrate recovery from the logs.

Weekly deliverable

A deployed staging application with environment configuration, smoke tests, trace samples, and an operations checklist.

Tools and environment

  • Docker
  • Kubernetes
  • Cloud or app platform
  • Logs and traces
  • Git-based release process

How you demonstrate learning

  • Deployment succeeds and is repeatable
  • Sensitive data is not logged
  • Failure cases are visible
  • Rollback and fallback behaviour are documented

Quality checks in practice

  • Logging full prompts and documents can expose personal or confidential data
  • A successful deploy does not prove answer quality; monitor quality and keep a rollback path
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review4 evidence checksWeek 10 · estimated 10 hours · Docker / Kubernetes / Cloud or app platform / Logs and traces
How week 10 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 11

Small models, fine-tuning, and inference

Decide whether model adaptation is justified, run a bounded experiment where feasible, and measure change against a baseline.

10 h15 lesson topics3 tools

Lesson outline · 15 topics

  1. Transformer overview: tokens, embeddings, attention, and feed-forward layers
  2. The next-token training objective
  3. Task baselines: prompt-only, retrieval, and rules
  4. Defining what behaviour must change before training
  5. Data strategy: approved sources, cleaning, and deduplication
  6. Train, validation, and test splits
  7. Synthetic-data review
  8. Supervised fine-tuning and parameter-efficient methods
  9. What adapters change, and what they do not
  10. Training loop: batches, loss, learning rate, and gradient accumulation
  11. Overfitting and checkpointing
  12. Evaluation: task metrics, held-out examples, capability and safety checks
  13. Data leakage checks
  14. Inference: quantization, memory, throughput, time to first token, inter-token latency
  15. Preview: domain-adaptive pretraining and preference methods such as DPO

Core concepts

  • What fine-tuning changes, and what it cannot fix
  • Baselines and data design before any training run
  • Evaluation that survives held-out data and leakage checks
  • Inference cost: quantization, memory, throughput, and latency

Guided lab

Use a small, permitted dataset to compare a prompting baseline with a supervised adaptation experiment in a hosted notebook when suitable compute is available.

Weekly deliverable

An experiment report with a data description, baseline, method, evaluation results, cost and compute notes, and a go or no-go recommendation.

Tools and environment

  • Python
  • PyTorch and a training library
  • Hosted GPU notebook when needed

How you demonstrate learning

  • No train or test leakage
  • Measurable comparison against the baseline
  • Limitations stated
  • Adaptation chosen only when it improves the target behaviour

Quality checks in practice

  • Fine-tuning is a poor substitute for current facts that should come from retrieval
  • Training leakage, noisy synthetic examples, and a missing baseline make gains look misleading
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review4 evidence checksWeek 11 · estimated 10 hours · Python / PyTorch and a training library / Hosted GPU notebook when needed
How week 11 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Week 12

Capstone, technical review, and presentation

Bring the system together and demonstrate that it solves a defined task under documented constraints.

10 h9 lesson topics3 tools

Lesson outline · 9 topics

  1. Scope and acceptance criteria
  2. User journey, baseline, data inventory, and risks
  3. Architecture and data flow across UI, API, model, retrieval, tools, and storage
  4. End-to-end evaluation plan with normal, edge, and adversarial cases
  5. Security, privacy, and human-review points
  6. Failure recovery and operational budget
  7. Release readiness: tests, trace review, deployment evidence, known limitations
  8. Rollback plan
  9. Technical communication: design choices, alternatives, results, and next steps

Core concepts

  • Defining done: acceptance criteria, baselines, and risks
  • End-to-end evaluation with normal, edge, and adversarial cases
  • Release readiness, rollback, and known limitations
  • Explaining design decisions to a non-specialist stakeholder

Guided lab

Complete a capstone review: run the test set, inspect traces, demonstrate a failure and its recovery, and present a short product demo.

Weekly deliverable

A deployed or runnable AI product with source code, README, architecture diagram, evaluation report, demo, and an improvement backlog.

Tools and environment

  • The stack selected in earlier weeks
  • Project repository
  • Evaluation artifacts

How you demonstrate learning

  • The stated task works
  • Metrics are reproducible
  • Risks and failure modes are addressed
  • Decisions can be explained to a non-specialist stakeholder

Quality checks in practice

  • A polished happy-path demo can hide failures; test edge cases and show one recovery path
  • Do not report a metric without describing the test set, baseline, and known limitations
01Learn4 core concepts02PractiseGuided lab03BuildWeekly deliverable04Review4 evidence checksWeek 12 · estimated 10 hours · The stack selected in earlier weeks / Project repository / Evaluation artifacts
How week 12 is delivered: understand it, test it, build it, then improve it with evidence.

Connection to the project spine. Apply this week's concepts to the recurring catalogue and listing-improvement project, or use the same methods on an approved project of your choice.

Systems you will build

Four systems, one capstone. Every system is built on the same running project, so the work compounds instead of resetting each week.

01

Document-grounded answer service

Take the retrieval work from weeks 6 and 7 and ship it as a real service: a chat surface, an API, packaging, and a repeatable release.

What you hand in

Deliverable

A deployed assistant that answers from your documents and cites the passage behind every claim.

Evidence a reviewer checks

  • Retrieval and answer evaluation on a fixed test set
  • API tests for empty, unsupported, and malformed questions
  • Release logs and a health check
  • Python
  • FastAPI
  • Vector search
  • Docker
02

Deep research agent

Build a research assistant that searches sources, separates research from critique, and asks a human when the evidence is weak instead of guessing.

What you hand in

Deliverable

A multi-step research workflow with citations, review checkpoints, and an inspectable trace.

Evidence a reviewer checks

  • Task completion on a defined question set
  • Trace showing where the critic changed the answer
  • Written comparison against a single-pass baseline
  • Workflow orchestration
  • Model APIs
  • Tracing
03

Catalogue improvement workflow

Extract product attributes, retrieve the guideline that applies, propose a correction, and stop for human approval before anything is written.

What you hand in

Deliverable

A bounded workflow with typed outputs, validation rules, approval state, and a measured quality check.

Evidence a reviewer checks

  • Schema pass rate and field accuracy
  • Proof that no write happens without approval
  • Failure path for an invalid tool argument
  • Tool calling
  • Validation
  • Approval gates
  • Audit trail
04

Small-model adaptation experiment

Pick one narrow sub-task from your own project, compare a prompting baseline with a parameter-efficient adaptation, and report what actually changed.

What you hand in

Deliverable

A reproducible training notebook, a held-out evaluation, a model card, and a go or no-go recommendation.

Evidence a reviewer checks

  • No train or test leakage
  • Before and after comparison against the baseline
  • Compute and cost notes
  • Python
  • PyTorch
  • Parameter-efficient tuning
  • Hosted notebook
C

Capstone: research assistant end to end

Build a research application that answers from uploaded documents and live sources, then defend it: what it does, what it costs, how it fails, and how you would operate it.

6 phases
  1. 01Scope and planDefine the question, the domain, the users, the sources, and the success criteria.Problem brief, source map, baseline
  2. 02Document retrievalIngest documents, chunk and index them, and retrieve passages with source metadata.Retrieval recall, relevance, provenance
  3. 03Research toolsAdd permitted external sources and validate every tool input before it runs.Tool correctness, source coverage, permissions
  4. 04OrchestrationCoordinate researcher, critic, and writer roles with state, budgets, checkpoints, and traces.Task completion, budget adherence, recovery
  5. 05Synthesis and reviewProduce cited answers and reports, flag conflicting evidence, and route weak claims to a human.Citation accuracy, groundedness, review notes
  6. 06Deploy and evaluateShip it with authentication and monitoring, then compare quality, latency, and cost against a single-pass baseline.Working deployment, evaluation results, cost and latency

How progress and the capstone are assessed

Assessment rewards working behaviour and clear evidence, not a polished demo. Feedback arrives throughout the course and is meant to be used to revise the work.

Weekly practiceShort exercises, concept checks, and review questions.
Module deliverablesPrompt tests, API schemas, retrieval evaluations, graph comparisons, workflow traces.
Project checkpointsProblem brief, prototype, evaluation, and production-readiness review.
Capstone presentationDemo, architecture explanation, metric interpretation, limitations, next steps.

Who teaches it, and what support means

Instructors

Taught by AI professionals with 7+ years of combined experience at FAANG companies.

Placement support means

Resume and interview preparation, and guidance on applying through job portals. It is not a job guarantee, and we do not promise interviews or salaries.

What you need

Basic coding experience is useful. Programming foundations are included, so you can build the basics and start using tools at your own comfort.

Certificate

A GenAI4Code completion certificate is issued after the capstone review is passed. It is a GenAI4Code credential: no partner or university co-branding is implied.

Still being confirmed

Session times, cohort start date, and fees are confirmed per cohort. This page never promises a start date or a price.

Weekly videos, labs, quizzes, and assignments are authored week by week. This page is the committed structure, and the project spine is one running project from week 1 to the capstone.

Questions worth asking

Straight answers to what people ask before they join. If something is not settled yet, this page says so instead of guessing.

Do I need to be an experienced developer?

No. Week 1 covers programming foundations, and every later week states the foundation it assumes. Basic coding experience helps, but the first weeks are written for someone building the basics.

How much time does a week take?

Plan for 3 hours on Saturday, 3 hours on Sunday, and roughly 4 hours of practice during the week. The weekly deliverable is what you are actually committing to.

What if I cannot attend a live session?

Session recordings and the week's materials stay available, and the deliverable is what is graded. The exact make-up and replay policy is confirmed per cohort.

Do I need a GPU or paid infrastructure?

Not for the core path. Hosted notebooks are used where a week needs real compute, and any cost is confirmed before a cohort starts rather than discovered mid-course.

Which tools will I actually use?

Python, Git, model APIs, structured output validation, vector search, containers, and deployment tooling. Tooling is chosen to serve the week's objective, and the tools you are handed are reviewed, not trusted blindly.

How am I assessed?

Weekly deliverables with a written review, four project checkpoints, and a capstone review covering problem framing, functionality, evaluation quality, safety, production readiness, and communication. Evidence matters more than a polished demo.

What does placement support include?

Resume and interview preparation, and guidance on applying through job portals. It is not a job guarantee, and we do not promise interviews or salaries.

Is the syllabus the whole course, or a summary?

Every week is listed with its concepts, lab, deliverable, tools, evidence, and the failure modes to watch for. You can read all of it here before deciding anything.

What certificate do I get?

A GenAI4Code completion certificate, issued after the capstone review is passed. It is a GenAI4Code credential, so nothing in our material implies partner or university co-branding.

Will I build something I can show?

Yes. Four systems plus a capstone, each with a deliverable and evidence: an installed, deployed product with evaluation results, not a folder of exercises.

What happens after the cohort ends?

You keep the project repository, the evaluation results, and the written reviews. Access arrangements beyond the cohort are confirmed per cohort.

Next cohort

Live class runs 3 hours on Saturday and 3 hours on Sunday, 12 weeks in total. Start date, session times, and fees are confirmed per cohort, so nothing here promises a date or a price.

Dates to be announcedRegister interest

Read it, then decide.

If this looks like the work you want to be able to do, open the programme page and register your interest — cohort details follow from there.

View the programme Fees and waitlist