AI curriculum

Course outline for Software Engineering Foundations for AI Engineers

A model-generated report must not publish itself merely because its output looks valid. Refactor a supplied AI report feature so model proposals, deterministic rules, storage, and publication have separate responsibilities. Compare object-oriented and functional designs, swap a mock model adapter, and test the approval boundary without a live model.

Technology: Software Engineering Foundations
Duration: 4 hours
Modules: 2 · 2 hours each
Level: Level 1

About Software Engineering Foundations for AI Engineers

Software Engineering Foundations for AI Engineers Course Objectives

Separate probabilistic model proposals from deterministic rules and effects.
Compare object-oriented encapsulation with pure transformations for the same report.
Use a model adapter and justify its abstraction cost.
Specify typed generated-output and tool-input contracts.
Test malformed outputs, invalid transitions, and approval before publication.
Compare a modular application with service separation under model-service failures.

Pre-requisites

Ability to write small programs in one language.
Familiarity with basic application development.
Ability to run and interpret simple tests; a short test-runner bridge is available.

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.

Can structure and test a small program; this course supplies design boundaries for later implementation work.

Find your place in the learning map

Lab Setup

Computer with a code editor, a familiar language runtime, Git, and a test runner.
Supplied AI report repository, synthetic model responses, recorded-response fixtures, and tool contracts.
Use a local store and mock model/publication adapters; no model account or distributed deployment is required.

Detailed Course Outline

Module 1: Separate model proposals from rules and effects (2 hours)

Software design principles: Cohesion and coupling in an AI report feature; separate probabilistic model proposals from deterministic validation, storage, and publication responsibilities.
Object-oriented design: Encapsulate report state and model-adapter responsibilities; keep approval rules independent of provider-specific responses and persistence behavior.
Functional programming: Use pure transformations and immutable inputs to validate generated drafts; isolate model calls and publication effects from testable application rules.
Design patterns: Apply an adapter to mock model providers and a publication interface; compare interchangeable implementations with simpler code and maintenance costs.

Practical outcome: Refactor a supplied AI report feature into a mock model adapter, pure validation rules, and publication effects; compare object and functional designs and justify the adapter.

Module 2: Protect AI application boundaries (2 hours)

API design: Specify generated-output and tool-input schemas, errors, and version compatibility; distinguish well-formed proposals from authorized application commands.
Distributed systems fundamentals: Inspect model-service timeouts, partial failures, and retries; distinguish receiving a generated proposal from committing its requested side effect.
Microservices fundamentals: Compare a modular AI feature with separate inference and application services; justify ownership boundaries without assuming every model integration needs microservices.
Testing and quality engineering: Use mocks and recorded model responses for deterministic contract tests; reject invalid output and unapproved effects without claiming to evaluate model quality.

Practical outcome: Define generated-output and tool-input contracts, enforce draft-to-approved-to-published transitions, and compare local modules with model-service timeout and partial-failure traces.

Practical exercise

Produce a refactored AI report feature, boundary diagram, and deterministic test suite using supplied model-response fixtures.
Accept a valid draft and approved publication; reject malformed output, an unauthorized publication, and an incompatible tool input before effects occur.
Run at least six tests with mock and recorded-response adapters; verify that switching adapters preserves application rules without calling a live model.
Change one output schema assumption and revise the consumer contract, explaining whether a local module or separate service is appropriate.

What you will produce

Refactor an AI feature so model proposals, typed contracts, deterministic rules, and publication effects can be tested independently.

How the work is checked

Boundary diagram matches the implemented responsibilities.
Tests accept valid drafts and reject malformed model outputs, unapproved publication, and incompatible tool inputs.
The design comparison accounts for coupling, partial failures, and maintenance effort.
Adapter switching and a schema change preserve tested rules without an unnecessary service split.

Four hours refactoring one prepared AI feature with mock responses. Retain object, functional, API, and distributed-systems fundamentals. Tests establish application contracts, not model answer quality. Model integration and evaluation receive deeper treatment in later courses; no live model or service deployment is required.

When another approach is better

Do not introduce microservices when local module boundaries meet the workload and team needs.
Do not add design patterns or command/read separation when their complexity exceeds the change they clarify.

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