8. How to Manage Coding Projects with AI

Course Positioning

This course teaches learners how to use AI coding tools without creating unmaintainable chaos. The key idea is that AI is strongest when the human provides architecture, specifications, tests, constraints, and review. The course covers planning, scaffolding, debugging, refactoring, documentation, testing, Git, deployment, and handoff.

Learning outcomes

Turn a vague app idea into requirements, user stories, architecture, and implementation tasks.
Use AI coding assistants to generate, explain, debug, refactor, and document code.
Create tests, review diffs, manage Git branches, and avoid blindly accepting generated code.
Use AI to understand unfamiliar codebases and plan safe changes.
Deliver a small working project with README, tests, issue tracker, and deployment notes.

Expanded Topic-by-Topic Coverage

Module 1. The AI-assisted software lifecycle

Module focus: Idea, requirements, architecture, implementation, tests, review, deployment, maintenance. Primary live activity or lab: Compare chaotic prompting vs structured spec-driven prompting. Expected take-home output: Project workflow map.

Topics and coverage

Idea

What it means: define Idea clearly and connect it to the module focus: Idea, requirements, architecture, implementation, tests, review, deployment, maintenance.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

requirements

What it means: define requirements clearly and connect it to the module focus: Idea, requirements, architecture, implementation, tests, review, deployment, maintenance.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

architecture

What it means: place architecture inside the AI system stack so learners know what problem it solves and what tradeoffs it introduces.
What to cover: inputs, outputs, system boundaries, evaluation criteria, cost or latency implications, and common failure cases.
Demonstration: use a diagram, small code sample, worksheet, or tool trace to make the mechanism visible.
Evidence of learning: learners compare two approaches and explain which one they would choose for a realistic constraint.

implementation

What it means: define implementation clearly and connect it to the module focus: Idea, requirements, architecture, implementation, tests, review, deployment, maintenance.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

tests

What it means: define tests clearly and connect it to the module focus: Idea, requirements, architecture, implementation, tests, review, deployment, maintenance.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

review

What it means: define review clearly and connect it to the module focus: Idea, requirements, architecture, implementation, tests, review, deployment, maintenance.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

deployment

What it means: place deployment inside the AI system stack so learners know what problem it solves and what tradeoffs it introduces.
What to cover: inputs, outputs, system boundaries, evaluation criteria, cost or latency implications, and common failure cases.
Demonstration: use a diagram, small code sample, worksheet, or tool trace to make the mechanism visible.
Evidence of learning: learners compare two approaches and explain which one they would choose for a realistic constraint.

maintenance

What it means: define maintenance clearly and connect it to the module focus: Idea, requirements, architecture, implementation, tests, review, deployment, maintenance.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

Practice and evidence of learning

Learners complete or discuss: Compare chaotic prompting vs structured spec-driven prompting.
Learners produce: Project workflow map.
Instructor checks for accuracy, practical usefulness, clear assumptions, appropriate human review, and fit with the course audience.
Learners revise once after feedback so the module contributes to the final project, portfolio, or playbook.

Minimum coverage before moving on

Learners can explain the module vocabulary without relying on tool-generated text.
Learners have seen one worked example, one hands-on application, and one limitation or failure case.
Learners know what must be verified, what data must be protected, and who remains accountable for the output.

Module 2. Writing strong project specs

Module focus: Problem statement, users, constraints, data model, APIs, UI, non-functional requirements. Primary live activity or lab: Turn an idea into a PRD and technical spec. Expected take-home output: Spec document.

Topics and coverage

Problem statement

What it means: define Problem statement clearly and connect it to the module focus: Problem statement, users, constraints, data model, APIs, UI, non-functional requirements.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

users

What it means: define users clearly and connect it to the module focus: Problem statement, users, constraints, data model, APIs, UI, non-functional requirements.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

constraints

What it means: define constraints clearly and connect it to the module focus: Problem statement, users, constraints, data model, APIs, UI, non-functional requirements.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

data model

What it means: connect data model to the data lifecycle from source and structure through analysis, interpretation, and decision-making.
What to cover: source reliability, missing or biased data, leakage, assumptions, calculations, and the difference between correlation and decision-ready evidence.
Demonstration: walk through a small dataset or example table and mark the checks required before trusting the result.
Evidence of learning: learners produce a short analysis note that includes assumptions, limitations, and verification steps.

APIs

What it means: define APIs clearly and connect it to the module focus: Problem statement, users, constraints, data model, APIs, UI, non-functional requirements.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

UI

What it means: define UI clearly and connect it to the module focus: Problem statement, users, constraints, data model, APIs, UI, non-functional requirements.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

non-functional requirements

What it means: define non-functional requirements clearly and connect it to the module focus: Problem statement, users, constraints, data model, APIs, UI, non-functional requirements.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

Practice and evidence of learning

Learners complete or discuss: Turn an idea into a PRD and technical spec.
Learners produce: Spec document.
Instructor checks for accuracy, practical usefulness, clear assumptions, appropriate human review, and fit with the course audience.
Learners revise once after feedback so the module contributes to the final project, portfolio, or playbook.

Minimum coverage before moving on

Learners can explain the module vocabulary without relying on tool-generated text.
Learners have seen one worked example, one hands-on application, and one limitation or failure case.
Learners know what must be verified, what data must be protected, and who remains accountable for the output.

Module 3. Project scaffolding

Module focus: Folder structure, framework choices, dependency management, environment files, secrets. Primary live activity or lab: Generate and inspect a starter project. Expected take-home output: Project scaffold.

Topics and coverage

Folder structure

What it means: define Folder structure clearly and connect it to the module focus: Folder structure, framework choices, dependency management, environment files, secrets.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

framework choices

What it means: define framework choices clearly and connect it to the module focus: Folder structure, framework choices, dependency management, environment files, secrets.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

dependency management

What it means: define dependency management clearly and connect it to the module focus: Folder structure, framework choices, dependency management, environment files, secrets.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

environment files

What it means: define environment files clearly and connect it to the module focus: Folder structure, framework choices, dependency management, environment files, secrets.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

secrets

What it means: define secrets clearly and connect it to the module focus: Folder structure, framework choices, dependency management, environment files, secrets.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

Practice and evidence of learning

Learners complete or discuss: Generate and inspect a starter project.
Learners produce: Project scaffold.
Instructor checks for accuracy, practical usefulness, clear assumptions, appropriate human review, and fit with the course audience.
Learners revise once after feedback so the module contributes to the final project, portfolio, or playbook.

Minimum coverage before moving on

Learners can explain the module vocabulary without relying on tool-generated text.
Learners have seen one worked example, one hands-on application, and one limitation or failure case.
Learners know what must be verified, what data must be protected, and who remains accountable for the output.

Module 4. Coding with AI safely

Module focus: Small tasks, diff review, asking for rationale, avoiding giant patches, code style. Primary live activity or lab: Implement one feature using AI and review every change. Expected take-home output: Feature branch.

Topics and coverage

Small tasks

What it means: define Small tasks clearly and connect it to the module focus: Small tasks, diff review, asking for rationale, avoiding giant patches, code style.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

diff review

What it means: define diff review clearly and connect it to the module focus: Small tasks, diff review, asking for rationale, avoiding giant patches, code style.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

asking for rationale

What it means: define asking for rationale clearly and connect it to the module focus: Small tasks, diff review, asking for rationale, avoiding giant patches, code style.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

avoiding giant patches

What it means: define avoiding giant patches clearly and connect it to the module focus: Small tasks, diff review, asking for rationale, avoiding giant patches, code style.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

code style

What it means: define code style clearly and connect it to the module focus: Small tasks, diff review, asking for rationale, avoiding giant patches, code style.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

Practice and evidence of learning

Learners complete or discuss: Implement one feature using AI and review every change.
Learners produce: Feature branch.
Instructor checks for accuracy, practical usefulness, clear assumptions, appropriate human review, and fit with the course audience.
Learners revise once after feedback so the module contributes to the final project, portfolio, or playbook.

Minimum coverage before moving on

Learners can explain the module vocabulary without relying on tool-generated text.
Learners have seen one worked example, one hands-on application, and one limitation or failure case.
Learners know what must be verified, what data must be protected, and who remains accountable for the output.

Module 5. Debugging and error literacy

Module focus: Reading stack traces, minimal reproductions, logs, dependency conflicts, AI debugging prompts. Primary live activity or lab: Fix injected bugs with AI assistance. Expected take-home output: Debugging journal.

Topics and coverage

Reading stack traces

What it means: define Reading stack traces clearly and connect it to the module focus: Reading stack traces, minimal reproductions, logs, dependency conflicts, AI debugging prompts.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

minimal reproductions

What it means: define minimal reproductions clearly and connect it to the module focus: Reading stack traces, minimal reproductions, logs, dependency conflicts, AI debugging prompts.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

logs

What it means: define logs clearly and connect it to the module focus: Reading stack traces, minimal reproductions, logs, dependency conflicts, AI debugging prompts.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

dependency conflicts

What it means: define dependency conflicts clearly and connect it to the module focus: Reading stack traces, minimal reproductions, logs, dependency conflicts, AI debugging prompts.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

AI debugging prompts

What it means: explain how AI debugging prompts changes the interaction between human intent, model behavior, external information, and final output.
What to cover: inputs, constraints, examples, output format, grounding, iteration, failure modes, and when a human must intervene.
Demonstration: show a weak attempt, a stronger structured attempt, and a reviewed final version with explicit checks.
Evidence of learning: learners create a reusable prompt, schema, retrieval note, or workflow pattern and test it on at least two examples.

Practice and evidence of learning

Learners complete or discuss: Fix injected bugs with AI assistance.
Learners produce: Debugging journal.
Instructor checks for accuracy, practical usefulness, clear assumptions, appropriate human review, and fit with the course audience.
Learners revise once after feedback so the module contributes to the final project, portfolio, or playbook.

Minimum coverage before moving on

Learners can explain the module vocabulary without relying on tool-generated text.
Learners have seen one worked example, one hands-on application, and one limitation or failure case.
Learners know what must be verified, what data must be protected, and who remains accountable for the output.

Module 6. Testing and quality

Module focus: Unit tests, integration tests, UI checks, test data, coverage, regression tests. Primary live activity or lab: Ask AI to propose tests, then improve them manually. Expected take-home output: Test suite.

Topics and coverage

Unit tests

What it means: define Unit tests clearly and connect it to the module focus: Unit tests, integration tests, UI checks, test data, coverage, regression tests.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

integration tests

What it means: define integration tests clearly and connect it to the module focus: Unit tests, integration tests, UI checks, test data, coverage, regression tests.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

UI checks

What it means: define UI checks clearly and connect it to the module focus: Unit tests, integration tests, UI checks, test data, coverage, regression tests.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

test data

What it means: connect test data to the data lifecycle from source and structure through analysis, interpretation, and decision-making.
What to cover: source reliability, missing or biased data, leakage, assumptions, calculations, and the difference between correlation and decision-ready evidence.
Demonstration: walk through a small dataset or example table and mark the checks required before trusting the result.
Evidence of learning: learners produce a short analysis note that includes assumptions, limitations, and verification steps.

coverage

What it means: explain how coverage changes the interaction between human intent, model behavior, external information, and final output.
What to cover: inputs, constraints, examples, output format, grounding, iteration, failure modes, and when a human must intervene.
Demonstration: show a weak attempt, a stronger structured attempt, and a reviewed final version with explicit checks.
Evidence of learning: learners create a reusable prompt, schema, retrieval note, or workflow pattern and test it on at least two examples.

regression tests

What it means: place regression tests inside the AI system stack so learners know what problem it solves and what tradeoffs it introduces.
What to cover: inputs, outputs, system boundaries, evaluation criteria, cost or latency implications, and common failure cases.
Demonstration: use a diagram, small code sample, worksheet, or tool trace to make the mechanism visible.
Evidence of learning: learners compare two approaches and explain which one they would choose for a realistic constraint.

Practice and evidence of learning

Learners complete or discuss: Ask AI to propose tests, then improve them manually.
Learners produce: Test suite.
Instructor checks for accuracy, practical usefulness, clear assumptions, appropriate human review, and fit with the course audience.
Learners revise once after feedback so the module contributes to the final project, portfolio, or playbook.

Minimum coverage before moving on

Learners can explain the module vocabulary without relying on tool-generated text.
Learners have seen one worked example, one hands-on application, and one limitation or failure case.
Learners know what must be verified, what data must be protected, and who remains accountable for the output.

Module 7. Git, issues, and project management

Module focus: Commits, branches, PRs, issue templates, changelogs, documentation, code review. Primary live activity or lab: Create issues and PR description for the project. Expected take-home output: Git workflow artifact.

Topics and coverage

Commits

What it means: define Commits clearly and connect it to the module focus: Commits, branches, PRs, issue templates, changelogs, documentation, code review.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

branches

What it means: define branches clearly and connect it to the module focus: Commits, branches, PRs, issue templates, changelogs, documentation, code review.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

PRs

What it means: define PRs clearly and connect it to the module focus: Commits, branches, PRs, issue templates, changelogs, documentation, code review.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

issue templates

What it means: define issue templates clearly and connect it to the module focus: Commits, branches, PRs, issue templates, changelogs, documentation, code review.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

changelogs

What it means: define changelogs clearly and connect it to the module focus: Commits, branches, PRs, issue templates, changelogs, documentation, code review.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

documentation

What it means: define documentation clearly and connect it to the module focus: Commits, branches, PRs, issue templates, changelogs, documentation, code review.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

code review

What it means: define code review clearly and connect it to the module focus: Commits, branches, PRs, issue templates, changelogs, documentation, code review.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

Practice and evidence of learning

Learners complete or discuss: Create issues and PR description for the project.
Learners produce: Git workflow artifact.
Instructor checks for accuracy, practical usefulness, clear assumptions, appropriate human review, and fit with the course audience.
Learners revise once after feedback so the module contributes to the final project, portfolio, or playbook.

Minimum coverage before moving on

Learners can explain the module vocabulary without relying on tool-generated text.
Learners have seen one worked example, one hands-on application, and one limitation or failure case.
Learners know what must be verified, what data must be protected, and who remains accountable for the output.

Module 8. Deployment and handoff

Module focus: Readme, setup instructions, environment variables, deployment platforms, monitoring basics. Primary live activity or lab: Deploy or simulate deployment and create handoff docs. Expected take-home output: Demo and handoff package.

Topics and coverage

Readme

What it means: define Readme clearly and connect it to the module focus: Readme, setup instructions, environment variables, deployment platforms, monitoring basics.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

setup instructions

What it means: define setup instructions clearly and connect it to the module focus: Readme, setup instructions, environment variables, deployment platforms, monitoring basics.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

environment variables

What it means: define environment variables clearly and connect it to the module focus: Readme, setup instructions, environment variables, deployment platforms, monitoring basics.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

deployment platforms

What it means: place deployment platforms inside the AI system stack so learners know what problem it solves and what tradeoffs it introduces.
What to cover: inputs, outputs, system boundaries, evaluation criteria, cost or latency implications, and common failure cases.
Demonstration: use a diagram, small code sample, worksheet, or tool trace to make the mechanism visible.
Evidence of learning: learners compare two approaches and explain which one they would choose for a realistic constraint.

monitoring basics

What it means: define monitoring basics clearly and connect it to the module focus: Readme, setup instructions, environment variables, deployment platforms, monitoring basics.
What to cover: the core concept, why it matters, what good usage looks like, and where learners are likely to misunderstand it.
Demonstration: give one simple example, one realistic example, and one failure or limitation example.
Evidence of learning: learners explain the topic in their own words and apply it to a small artifact or decision.

Practice and evidence of learning

Learners complete or discuss: Deploy or simulate deployment and create handoff docs.
Learners produce: Demo and handoff package.
Instructor checks for accuracy, practical usefulness, clear assumptions, appropriate human review, and fit with the course audience.
Learners revise once after feedback so the module contributes to the final project, portfolio, or playbook.

Minimum coverage before moving on

Learners can explain the module vocabulary without relying on tool-generated text.
Learners have seen one worked example, one hands-on application, and one limitation or failure case.
Learners know what must be verified, what data must be protected, and who remains accountable for the output.

Labs, projects, and assessments

Lab 1: Convert an app idea into a PRD and technical implementation plan.
Lab 2: Build one feature using AI, but require tests before acceptance.
Lab 3: Use AI to explain an unfamiliar codebase and propose a safe refactor.
Capstone: Working mini-app or automation with Git history, tests, README, and deployment notes.

Evaluation approach

20% project specification.
20% AI-assisted implementation quality.
25% tests and debugging journal.
15% Git/project management hygiene.
20% final demo and handoff documentation.

Recommended tools and materials

Cursor, GitHub Copilot, Replit, VS Code, GitHub, local terminal, package manager, testing framework, deployment platform such as Vercel/Render/Fly.io if appropriate.
Optional: issue tracker, diagrams, API testing tool.

Safety, ethics, and governance emphasis

Never paste production secrets, private keys, client data, proprietary code, or credentials into tools without explicit approval.
Require code review and tests before deployment.
Discuss license risks, dependency risks, generated code ownership, and security scanning.

Delivery notes

Make learners work in small increments. The biggest failure mode is asking AI to build the entire app at once.
Non-technical founders can take a product-management version focused on specs, vendor review, and prototype oversight.

Instructor Build Checklist

Prepare one short demo for each module and one learner activity that creates a saved artifact.
Prepare examples that match the audience, local context, and likely tools learners can access.
Add a verification step to every AI-generated output: factual check, source check, data sensitivity check, and quality review.
Keep a running portfolio folder so each module contributes to the final project or learner playbook.
Reserve time for reflection on what the learner did, what AI did, what was checked, and what remains uncertain.