AI curriculum

Course outline for Building Applications with LLMs

An assistant can propose a valid-looking action that is unauthorized or based on an outdated record. Build a small application that separates observation, recommendation, and state-changing commands. Validate inputs and bind human approval to the exact proposed change before recording its actual effect.

Technology: AI Application Engineering
Duration: 4 hours
Modules: 2 · 2 hours each
Level: Level 3

About Building Applications with LLMs

Building Applications with LLMs Course Objectives

Separate model generation, validation, tool execution, and review responsibilities.
Implement a structured output contract and semantic checks.
Complete a mock tool-call and tool-result exchange.
Distinguish conversation history from durable application state.
Enforce authorization and approval of an exact record version outside the model.
Test malformed output, tool failure, and stale approval without committing an invalid change.

Pre-requisites

Software Engineering Foundations for AI Engineers and Applied Generative AI, or equivalent application-boundary and structured-interaction competence.
Ability to build a small application in one language.
Familiarity with APIs and JSON.
Basic local persistence is useful; a supplied store adapter avoids requiring a database course.

Before this course

Complete the required courses or bring equivalent experience. Recommended courses add useful depth; they are not enrolment gates.

Required preparation

Recommended preparation

Database Systems for AI Applications

Can implement application boundaries and validated model interactions; database knowledge helps with durable state.

Find your place in the learning map

Lab Setup

Computer with a code editor, familiar language runtime, and test runner.
Supplied application scaffold, local file or embedded store, synthetic records, dummy identities, and mocked model responses.
Optional local model; no production credentials, external mutation, or paid model service is required.

Detailed Course Outline

Module 1: Define application contracts (2 hours)

LLM application architecture: Generation, validation, execution, and review boundaries; separate observations, recommendations, and commands within the supplied draft-and-approve application.
Prompt and context design: Task instructions, source records, and minimal relevant context; keep durable business state and authorization decisions outside model-generated text.
Structured generation: Typed output contracts, required fields, and semantic checks; reject plausible but unsupported recommendations before they reach execution interfaces.
Function calling: Call arguments, identifiers, tool results, and follow-up messages; trace the complete mock exchange rather than only the initial proposal.

Practical outcome: Implement observation and recommendation interfaces, validate structure and meaning, and trace the complete mock function-call/result protocol while keeping model proposals separate from executable commands.

Module 2: Control state changes (2 hours)

Tool integration: Read and write adapters, input validation, and permission gates; enforce authority separately from the model's choice of tool.
State management: Conversation history versus durable records, versions, and mutation preconditions; invalidate previous approval when the underlying record changes.
Error handling: Malformed output, tool failure, and rejected writes; preserve final-state evidence and define recovery or escalation rather than trusting completion messages.
Human-in-the-loop interaction: Review queues, exact mutation approval, and version binding; distinguish reviewer consent from the separate permission required to execute a write.

Practical outcome: Add a local durable record and review queue, bind approval to the record version and exact mutation, enforce a separate permission gate, and return an explicit result after successful or failed execution.

Practical exercise

Produce a local draft-and-approve assistant with a mock read tool, controlled write tool, durable record, and test report.
Commit an authorized command for the approved current version; reject malformed arguments, unauthorized writes, and approval invalidated by an edit.
Run at least eight fixtures, including a tool failure, and verify the stored final state and recorded effects rather than a completion message.
Document recovery and escalation after failure, explaining why separating read and write interfaces does not itself grant authorization.

What you will produce

Build a local LLM-assisted application that commits only authorized, version-approved commands and independently verifies their effects.

How the work is checked

Model proposals and executed commands have separate contracts.
Authorization and exact-version approval are enforced outside generated text.
Invalid, unauthorized, and stale-approved requests leave the durable record unchanged.
The test report checks actual final state and tool failures independently of model claims.

Four hours extending a supplied application and store adapter, not building an application stack from scratch. Implement validation and the version/approval gate, then run prepared failure fixtures within module time. Distributed recovery and multi-agent coordination are advanced extensions.

When another approach is better

Do not add a model to a feature whose stable inputs and rules can be implemented directly.
Do not allow model-proposed arguments to bypass authorization or use conversation history as the sole durable state record.

How we train

Ask about exercises, instructor feedback and the prior knowledge you need. Tool-specific courses marked provisional may become modules in a broader course.

Discuss your learning goals