AI curriculum

Course outline for AI-Assisted Software Development

Generated code can satisfy a prompt while expanding scope, hiding defects, or increasing review effort. Use AI assistance for one bounded repository change and keep requirements, design, review, and tests independently checkable. Measure the full change effort and turn a recurring check into a repeatable script.

Technology: AI-Assisted Software Engineering
Duration: 6 hours
Modules: 3 · 2 hours each
Level: Level 2

About AI-Assisted Software Development

AI-Assisted Software Development Course Objectives

Translate a change request into acceptance criteria and allowed scope.
Compare a proposed architecture with a simpler implementation.
Review generated code for defects, unnecessary complexity, and scope drift.
Debug and refactor a supplied patch using reproducible tests.
Connect affected files, test evidence, and documentation to the change contract.
Propose and retest one workflow improvement while recording review and rework effort.

Pre-requisites

Software Engineering Foundations for AI Engineers and Artificial Intelligence Foundations, or equivalent design/test skills and awareness of AI limitations.
Programming experience and basic version control skills.
Ability to run tests independently in a small repository.
Basic AI interaction skills; structured-generation or agent courses are optional preparation.

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

Readiness checks

Programming, Git, and independently run repository tests
Basic AI interaction skills

Can review and test repository changes and recognizes AI limits; full structured-generation preparation is helpful but not required.

Find your place in the learning map

Lab Setup

Computer with Git, a code editor, familiar language runtime, and a testable sample repository.
Supplied generated patches, seeded defects, synthetic test data, and a local effort worksheet.
Optional local AI tooling or approved nonproduction service; no remote merge, deployment, or production credentials are required.

Detailed Course Outline

Module 1: Scope and design the change (2 hours)

AI-assisted requirements analysis: Acceptance criteria, allowed files, constraints, and failure conditions; convert a change request into a reviewable contract before generating code.
AI-assisted architecture: Affected boundaries, responsibility allocation, and simpler alternatives; evaluate design choices before committing to generated abstractions or additional technologies.
Code generation: Bounded implementation proposals, repository conventions, and acceptance targets; distinguish a plausible generated patch from a verified correct change.

Practical outcome: Define requirements, affected boundaries, allowed files, and acceptance tests before reviewing a generated patch, comparing a simpler design with the proposed technology choices.

Module 2: Inspect and correct implementation (2 hours)

Code review: Diff inspection, seeded defects, unnecessary complexity, and unrelated edits; compare every changed file with the agreed scope and independent checks.
Refactoring: Behavior-preserving simplification, clearer responsibilities, and regression evidence; reduce generated complexity without expanding the original change contract.
Debugging: Reproducible failures, expected behavior, and defect localization; correct the supplied patch using test evidence rather than the generating model's assessment.

Practical outcome: Find a seeded defect and scope expansion, simplify the patch, and record review and rework time using tests rather than relying on the generating model's assessment.

Module 3: Verify and improve the workflow (2 hours)

Testing: Baseline results, acceptance coverage, and regression checks; verify the correction independently and automate one recurring verification step.
Documentation: Changed behavior, constraints, and verification instructions; keep explanations consistent with the implemented patch and its recorded test results.
Repository understanding: Affected files, dependency boundaries, test locations, and project conventions; assemble relevant context and account for the full change dossier.

Practical outcome: Map the changed files to tests and documentation, script a recurring verification step, and run a defect-to-improvement cycle with separate approval for the workflow change and no implied merge or deployment authority.

Practical exercise

Produce a reviewed local patch, acceptance tests, updated documentation, and a change dossier.
Accept the bounded correct change; reject a supplied patch that passes a weak check but introduces a defect or edits an unrelated file.
Run the baseline and revised tests, account for every acceptance criterion, and record generation, review, and rework time separately.
Convert one repeated check into a CLI, rerun it, and explain whether the revised process reduced total effort within this exercise.

What you will produce

Deliver a scoped, independently tested repository change with a reviewed diff and a record of review and rework effort.

How the work is checked

Every acceptance criterion maps to implementation and test evidence.
The review identifies the seeded defect and rejects unrelated scope expansion.
The final patch and documentation pass independent repository checks.
The improvement record separates generation speed from total change effort and retains explicit authority limits.

Six hours using one small repository and contrasting prepared patches. Implement one correction and one recurring-check script, not a full feature and harness. Reserve approximately one hour per module for scoped practice and verification. Deployment and general productivity claims are outside scope; a fixture-only route does not measure live generation time.

When another approach is better

Do not delegate code review when you cannot independently understand and test the affected behavior.
Use a stable script rather than repeated model generation for a known deterministic verification step.

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