Teaching design and pilot plan
Session 00 adds two hours of setup to twelve two-hour learning sessions: 26 contact hours total. This is a foundation course followed by supervised apprenticeship, not a guarantee of expert performance.
Use one or two sessions per week with two to three hours of Product Studio homework between sessions, roughly 25–35 hours overall including presentation preparation. Adjust scope and support for learner circumstances. Start with an ungraded recall conversation before opening AI; revisit the concept in a new context. Demonstrate a worked example, then remove scaffolding gradually. These are the instructional choices for this pilot, not a claim that this precise schedule is experimentally optimal.
Core pattern: short demonstration, paired practice, break, independent task, peer critique, individual exit ticket. Ask learners to predict before executing a tool. After AI assistance, require them to explain the result from evidence without reading the chat verbatim.
Provide written instructions, captions for any instructor recording, keyboard operation, flexible pair roles and a low-bandwidth export path. Offer equivalent business themes; avoid assuming event-planning knowledge, gaming interest, or prior coding. No public leaderboard by bug count. Recognize clear reasoning, good questions, useful tests and collaborative review.
The individual course project is the assessment: Session 01 discussion, Session 02 approved kickoff, regular reviews and a final presentation to Jared Cluff. Two awards separate completed coursework from AIQAA skills certification. The latter requires product quality, genuine development over time and GitHub understanding; completed coursework can be recognized while certification revisions remain. No separate exams, hidden defense or numeric threshold. Keep software tests, evidence and learner explanation central; use gaps to plan coached revisions. Up to six presentations fit the Session 12 two-hour plan; larger cohorts need additional Jared-attended blocks. Pilot with 6–10 learners, record activity completion times and misconceptions, and adjust crowded lessons. Lesson 3's business surfaces are a sampler: repeat the sprint with different artifacts and approved connected work during apprenticeship.
Apprenticeship progression: supervised reproduction → own a low-risk charter → maintain a regression check → investigate integration failures → contribute to model evaluation. Grant responsibility based on observed performance and reviewer trust. Top-tier development requires sustained domain work beyond this course.
Make the learning loop visible
Each published lab has a build-time session guide with a purpose, evidence target, preparation links, optional recall prompt, supported route and previous/next navigation. Its activity/deliverable links resolve to the actual handout headings; automated checks reject missing anchors. The original Markdown remains the assignment source. The guide must not quietly change requirements or create another graded deliverable.
Use the recall prompt for about two minutes of the existing arrival/discussion slot and the closing prompt within the existing debrief. These replace portions of those activities, not add time to the two-hour agenda. Ask learners to try an explanation, check the source and correct it without shame. Offer the support described in Get unstuck; preserve both the documented blocked-tool alternatives and honest execution limits.
This design draws on the IES recommendations for revisiting learning over time, alternating examples with practice and asking explanatory questions (IES practice guide). That evidence is broader than this course; it does not establish the effectiveness of this specific AI/QA implementation. Our recall prompts are ungraded conversations, not a separate test or certification gate.
Semantic heading links and section navigation follow W3C’s heading guidance. Browser checks cover selected keyboard, layout and navigation behaviors, not a complete accessibility conformance audit. Validate the experience with real learners, assistive-technology users and supported OS/browser combinations before making stronger claims.