AI curriculum

Course outline for Web Application Foundations for AI Engineers

An AI-generated action proposal must follow the same server rules as a browser submission. Build a small approval feature with an accessible frontend, typed tool API, and server-owned transitions. Inspect streamed progress without confusing it with a committed action, then test duplicate, stale, and unauthorized requests in a reproducible local preview.

Technology: AI-Native Web and Application Development
Duration: 6 hours
Modules: 3 · 2 hours each
Level: Level 1

About Web Application Foundations for AI Engineers

Web Application Foundations for AI Engineers Course Objectives

Implement an accessible approval form and explicit browser error states.
Connect a frontend scaffold to a backend endpoint and supplied mock progress stream.
Validate generated action inputs and enforce server-owned business rules.
Distinguish identity, authorization, and approval before a tool mutation.
Test duplicate, stale, and unauthorized browser/mock-agent requests.
Package a repeatable preview without implementing a live model or production login.

Pre-requisites

Basic programming experience with functions and data structures.
Familiarity with browser use and introductory HTTP/web concepts.
Ability to use an editor and run supplied command-line scripts; software design and database courses are useful but not gates.

Before this course

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

No prerequisite course is required. The entry skills above still apply.

Recommended preparation

Can write basic programs and understands introductory web concepts; design/data-modeling courses help but do not gate the basic web course.

Find your place in the learning map

Lab Setup

Browser, editor, Node.js, supplied backend runtime, and framework scaffold.
Local services, synthetic users, an embedded store, and supplied mock generation/progress and agent-client fixtures.
No AI prerequisite, live model, hosting subscription, protocol implementation, or production identity infrastructure is required.

Detailed Course Outline

Module 1: Browser approval and progress states

HTML/CSS: Build accessible forms for reviewing generated action proposals; expose approval, pending, and error states without implying that presentation enforces server permissions.
JavaScript / TypeScript: Handle typed submissions and supplied streamed progress; distinguish partial generated output from server-confirmed success and apply runtime validation to external inputs.
Frontend frameworks: Connect proposal, approval, and progress components within a supplied scaffold; keep browser interaction state separate from authoritative action records.

Practical outcome: Implement a labeled approval form in a supplied framework scaffold; inspect a mock progress stream and keep pending output separate from server-confirmed success.

Module 2: Tool API and authoritative state

Backend development: Validate generated action proposals on the server; separate deterministic approval rules, persistence, and mock tool effects from model suggestions.
APIs: Specify typed tool requests, responses, errors, and read/mutation contracts; browser and mock-agent clients must obey the same server rules.
Server-owned state and invariants: Enforce draft-to-approved-to-executed transitions on the server; reject unapproved actions and schema-valid rule violations regardless of generated text or client progress.

Practical outcome: Implement a local endpoint for a generated action proposal with schema/business-rule checks and draft-to-approved-to-executed transitions shared by browser and mock-agent clients.

Module 3: Access, retries, and packaging

Authentication: Use supplied identity fixtures to distinguish identity verification from server authorization; reject another user's update without implying production login infrastructure.
Duplicate and stale-update checks: Use request keys to deduplicate creates and object versions to reject stale edits; verify retries do not corrupt protected state.
Deployment: Package an identifiable local build and document reproducible preview steps; distinguish tested application artifacts from production hosting and identity operations.

Practical outcome: Test synthetic identity, server authorization, request-key deduplication, and version-checked approval; produce a documented local build and preview.

Practical exercise

Submit a small action-approval feature, tool API/state contract, integration suite, and local preview instructions using a supplied mock generation/progress adapter.
Send valid proposals through the browser and mock-agent HTTP client; test malformed generated input, another user's update, unapproved execution, a repeated create, and a stale edit.
Require both clients to follow the same server rules; repeated requests create one record, and streamed completion alone cannot authorize or confirm a mutation.
Run all acceptance cases and reproduce the preview; reject schema-valid but rule-breaking actions without altering protected state.

What you will produce

Build an AI action-approval web feature whose browser and mock-agent clients share validated tool contracts and protected server state.

How the work is checked

Browser and mock-agent cases enforce identical schema, authorization, and approval rules; streamed progress does not establish committed state.
Duplicate creation yields one record; unauthorized and stale updates preserve protected state.
All supplied integration cases pass and the documented local preview is reproducible.

Six-hour scaffolded web foundation lab with mock generated proposals and a supplied progress-stream adapter. Implement one protected vertical slice, not live model integration or a streaming protocol. Framework mastery, production identity, advanced conversational UX, and distributed transactions follow in later courses.

When another approach is better

A static page is simpler when the feature does not need mutable server state.
Do not rely on client validation or mock authentication for real access control.
The local version-check example cannot replace transaction design for a distributed application.

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