CRCP 3305: Creative Coding II

Southern Methodist University · Creative Computation
Undergraduate · 3 Credit Hours · Online Section

Live class session: one 90-minute weekly studio via Zoom (day/time TBD; set against the registrar's section listing once the course is scheduled)

Course-approval draft — term and calendar dates are intentionally TBD. When the course is scheduled, university dates and the then-current SMU required syllabus statements will be inserted verbatim. The course description below is the proposed language-neutral catalog description submitted with the accompanying course-modification request; the catalog number, title, credit hours, prerequisites, and role in the degree are unchanged.

Instructor

Instructor: T.B.D.
Name, title, email, and phone will be inserted once the section's instructor of record is assigned.

Office Hours — T.B.D.; set by the instructor of record and posted on Canvas before the first live session.

Response Time — My goal is to respond to student communications within 24 hours. If for some reason I am unable to do so, I will follow up as soon as possible. I will always try to let you know ahead of time if I will be unreachable.

Assignment Feedback — My goal is to grade assignments within 48 hours. Instructor and peer feedback are also provided during each weekly live class session.

Course Description

Introduces advanced creative coding principles for the design of software systems for real-time performance and interactive applications. Students learn to architect systems with explicit models of state, time, and events; apply advanced object-oriented design and introductory data structures; reason about performance under real-time constraints; and specify, direct, and verify AI-assisted implementation of multi-component systems.

Where Creative Coding I asked how do I express this idea in code?, this course asks how should this system be structured? A real-time interactive system — an instrument, a simulation, a performance environment, a responsive installation, a game — is not a longer sketch. It is a set of parts with responsibilities, a model of time, a flow of events, and data organized so that the right thing can be found quickly enough to happen before the next frame. Getting that structure right is the work of this course, and it is work that AI coding tools make more important, not less: a system whose architecture was never decided will be built badly by any collaborator, human or machine, and the person who has to live with the result is the student.

Students therefore learn to draw a system before building it; to decompose it into parts an AI collaborator can implement one at a time; to read multi-file programs they did not write; to review generated architecture and refuse it when it is wrong; and to verify real-time behavior with instrumentation rather than trust. Advanced object-oriented principles — encapsulation, inheritance, interfaces, composition — and introductory data structures — lists, stacks, queues, maps, trees, graphs, and spatial structures — are taught as design choices with consequences, not as vocabulary.

Computation remains a creative medium. A successful project might be a live performance instrument, a generative ecosystem, a physics toy, a responsive typographic environment, a multiplayer sketch, a sound-reactive visual system, or a small game engine. The technical sequence is shared; the creative destination is not. Students share technical competencies, not creative outcomes.

Prerequisite: CRCP 1310, CS 1341, or permission of instructor. Students should arrive able to write, read, and explain small programs using variables, control flow, functions, collections, and simple classes in any language.

Course Format — Flipped Studio

This course runs as a flipped classroom:

• Before class, students complete two assigned tutorials with their produced explainer videos and written briefs at tutorials.ij8.ai (the Creative Coding II sequence — 30 tutorials spanning architecture, object design, data structures, interaction, and performance), plus a short technical or design experiment. Expect roughly 30–45 minutes of watching/reading plus preparation of that week's checkpoint.
• In class, a typical 90-minute session runs: 0–15 min — context and discussion connecting the week's structure to interaction design, performance practice, and computational culture; 15–30 min — instructor demonstration or architecture clinic; 30–70 min — breakout studio work (diagramming, building, profiling, reviewing, critique) with the instructor rotating between rooms; 70–90 min — share-outs and critique of selected systems, failures, and discoveries.

Class time is work time. Come with the tutorials completed, your questions ready, and your project open. The live meeting is studio, not a second version of the asynchronous material.

Learning Outcomes

Upon completion of the course a successful student will be able to do the following:

• CLO 1: Architect real-time systems — model a system's state, time, events, and data flow; draw its architecture before building; and defend the decomposition.
• CLO 2: Apply advanced object-oriented design — use encapsulation, inheritance, interfaces and polymorphism, and composition deliberately, and explain when each is and is not the right tool.
• CLO 3: Select and implement data structures — choose among lists, stacks, queues, maps, trees, graphs, and spatial structures for a real-time problem, implement them, and reason about the tradeoffs.
• CLO 4: Design interaction — model input, state transitions, timing, feedback, and responsiveness so that a system feels intentional to the person using it.
• CLO 5: Reason about performance — work within a frame budget; measure before optimizing; identify the structural cause of a performance problem.
• CLO 6: Direct AI-assisted implementation of multi-component systems — write context documents and bounded task specifications; review generated architecture and code; accept, revise, or refuse it on technical grounds.
• CLO 7: Verify real-time behavior — instrument, test, and reproduce bugs in systems whose behavior depends on time and input, rather than relying on inspection or an AI system's account of correctness.
• CLO 8: Produce an original real-time or interactive work — realize a system expressing an individual creative or applied perspective, and articulate its design reasoning in critique.

Module-level outcomes (MLOs) are listed within each Canvas module; the number in parentheses next to each MLO corresponds to the course-level outcomes above.

One Course, Many Directions

Students are not graded on whether they use every structure discussed in the course. They are graded on whether they understand the structures well enough to make intelligent decisions about using — or not using — them in service of an individual creative or functional intention.

One student might build a performance instrument driven by a MIDI controller. Another might make an ecosystem of thousands of agents, a physics-based drawing tool, a small networked multiplayer sketch, a sound-reactive stage environment, or a game with a hand-built scene graph. All are legitimate destinations for the same technical sequence.

A quadtree is never added because the course covers quadtrees; an inheritance hierarchy is never built because inheritance was in a tutorial. The right structure is the simplest one that keeps the system correct and fast enough. Complexity must be earned by the problem.

Designed for many students and many instructors. Because briefs name competencies rather than media, the same sequence supports a student who thinks in images, one who thinks in sound, and one who thinks in play — and an instructor whose own practice is any of those. The tutorial sequence establishes a reference path; the demonstrations, examples, and critique vocabulary of a given section may be drawn from whatever medium its instructor works in, without changing outcomes, briefs, or rubrics. Creativity is not a bonus layered on the technical sequence; it is what the technical sequence is for.

Reference Environment

The catalog description of this course names no programming language, and neither do its learning outcomes. That is deliberate. Architecture, object design, data structures, interaction, and performance reasoning are the same in every language, and the language an offering uses is an offering-level choice — like the day it meets — rather than part of what the course is.

Each offering does use a common reference environment so demonstrations, tutorials, and troubleshooting remain manageable. The reference environment for a given term is announced before registration and selected against four criteria: it must render in real time at interactive frame rates; it must support typed data and multi-file projects so that architecture is visible in the code; it must expose enough of its performance characteristics that measurement means something; and it must be one that current AI coding tools handle fluently. It is a reference environment, not an ideological commitment, and is revisited before each offering. Students may work in an alternative environment with instructor approval if they can demonstrate the same competencies.

• Creative coding — the term's reference language and real-time creative-coding environment (announced before registration); a full-featured editor or IDE; a profiler or frame-timing instrumentation.
• AI collaboration — an AI coding agent integrated with the editor (e.g., Claude Code, Cursor, or GitHub Copilot); an account with at least one frontier AI assistant (Claude, ChatGPT, or Gemini).
• Process — Git + GitHub for every project; a project context document maintained in the repository; a shared course gallery on Canvas.
• Studio — Zoom with a working webcam and microphone; SMU Canvas. Optional, per project: a MIDI controller, game controller, camera, microphone, or sensor.

Projects

The semester is organized around seven projects plus studio participation: six two-week projects, each exercising one structural competency on a system of the student's choosing, and a capstone. Project briefs are deliberately outcome-focused rather than prescriptive — each names the competency it assesses, not the medium it must take.

Every project may be realized visually, sonically, interactively, or in combination. A generative ecosystem, a performance instrument, a physics toy, a responsive typographic stage, a networked sketch, and a small game engine are all valid answers to the same brief. Students may carry one system through several projects or start fresh; either way they are evaluated on whether their structural decisions serve an individual creative or functional intention.

Every project is accompanied by an Architecture Record — a diagram of the system's parts, state, and event flow; the decisions made and the alternatives rejected; the AI Collaboration Note; and the verification account — and is submitted as a Git repository whose commit history shows the system developing.

Project 1 — System Anatomy · Weeks 1–2 · 8%

The work: dissect a working real-time system — one supplied by the instructor or one of the student's own from Creative Coding I — and map its state, its model of time, and its flow of events from input to output. Then rebuild one part of it with an explicit boundary and responsibility. Includes the map, the rebuilt part, and a first Architecture Record explaining what the original was hiding.

Evaluation emphasis: accuracy of the system map; clarity of the boundary drawn; the student's account of what was learned by looking.

Project 2 — Architecture Before Code · Weeks 3–4 · 10%

The work: design a small real-time system on paper — parts, responsibilities, state, time, events — write a project context document for an AI collaborator, decompose the design into bounded tasks, and build it task by task, verifying each before the next begins. The system may be visual, sonic, or interactive; it need not do much. It must do what the diagram says, legibly.

Evaluation emphasis: quality of the decomposition; clarity of the context document; discipline of the task-by-task build; fidelity of code to diagram.

Project 3 — Object Design · Weeks 5–6 · 12%

The work: a system of interacting entities — creatures, voices, brushes, bodies, players — whose class design is the point. Required: encapsulation used deliberately; at least one considered choice between inheritance, interfaces, and composition, with the reasoning and the rejected alternative recorded; ordered collections chosen for the problem; and a review of an AI-generated object model for the same system, identifying what was accepted, revised, or refused.

Evaluation emphasis: fitness of the object model; quality of the inheritance-versus-composition reasoning; critical review of generated design.

Project 4 — Structures Under Load · Weeks 7–8 · 12%

The work: make the Project 3 system — or a new one — survive scale. Required: at least two data structures beyond a simple list (a map, a tree or scene graph, a spatial grid or quadtree) chosen for the questions the system needs answered fastest; a performance baseline measured at three population sizes; one structural optimization with before-and-after measurement; and a record of what was not optimized and why.

Evaluation emphasis: fitness of structures to the problem; measurement-driven reasoning; judgment about when to stop.

Project 5 — Interaction Model · Weeks 9–10 · 12%

The work: an interactive application — an instrument, a tool, a game, a responsive environment — with an explicit interaction model. Required: a state machine governing the application's modes, drawn before it was coded; an input model abstracting at least two input types (mouse, keyboard, touch, controller, sensor, microphone) so the system does not care which produced the event; deliberate timing, easing, and feedback; and a formative test with at least three people outside the class, documented with what surprised the student.

Evaluation emphasis: correctness and legibility of the state model; feel; evidence-based revision.

Project 6 — Live System · Weeks 11–12 · 12%

The work: take a system into live conditions. Required: at least one real-time signal from outside the program — audio analysis or synthesis, a network peer, a sensor, external data — and the architectural changes it forced; robustness under wrong, fast, or absent input; explicit error handling and a degraded mode; a test or instrumentation strategy for at least one time-dependent behavior, with recorded-and-replayed input where appropriate; and a written review of the architecture an AI agent proposed for the integration.

Evaluation emphasis: handling of external time; robustness; verification of time-dependent behavior; architectural review.

Project 7 — Individual Capstone: Real-Time System · Weeks 13–Finals · 24%

The work: a substantial real-time performance or interactive application demonstrating the student's individual perspective and the course's accumulated competencies. Students may substantially develop an earlier project or propose a new direction with approval. The completed capstone addresses four dimensions:

• Creative/functional — clearly articulated intention; identifiable audience, performer, or player; coherent visual, sonic, and interaction language; evidence of individual authorship.
• Architectural — an understandable architecture with parts, state, time, and events made explicit; object design and data structures fit to the problem; a system the student can explain in full.
• Performance and robustness — a measured performance report; behavior under load and under adverse input; graceful failure appropriate to live conditions.
• Process — a complete Architecture Record; a Git history showing the system developing; an AI Collaboration Note; a verification account describing how the student knows the system does what they intended.

Final presentation: a live demonstration, an architecture walk (the student explains any part of the system the instructor or a peer selects, from diagram to code), and critique during the officially scheduled SMU final-examination period. The precise slot remains TBD until the Registrar's examination schedule is published; no new major assignment is introduced or due during the final week of classes.

Grades

Your work and overall performance will be recorded on Canvas. Students can access their current weighted average at any time via Grades.

Each project's midpoint checkpoint is a required milestone assessed within that project. Late or missing milestones reduce that project's grade.

Common Project Evaluation Framework

Although each project is different, a shared rubric keeps expectations equitable. Technical sophistication alone cannot compensate for an undifferentiated idea, and creatively ambitious students cannot ignore whether their system actually works — or whether they can explain its structure.

Grading Scale

Materials

Required (all free or already provided):

• tutorials.ij8.ai — the Creative Coding II sequence (30 tutorials with produced explainer videos and written briefs; access provided)
• ij8.ai studio account — AI art, code, and prototyping platform (provided)
• An account with at least one frontier AI assistant (Claude, ChatGPT, or Gemini)
• An AI coding agent (Claude Code, Cursor, or GitHub Copilot)
• The term's reference real-time creative-coding environment (free; announced before registration) and a full-featured editor or IDE
• Git + GitHub account
• Zoom + a working webcam and microphone; SMU Canvas
• A computer capable of real-time graphics at interactive frame rates (any laptop of the last several years); optional input devices per project

Recommended readings (linked per-module on Canvas; drawn from the tutorial reference lists): the reference environment's documentation; Daniel Shiffman, The Nature of Code; Robert Nystrom, Game Programming Patterns (free online); selected chapters on data structures from an open textbook chosen for the term's environment; essays on interaction design, live performance systems, and computational aesthetics, refreshed each term. No conventional textbook is required; the tutorial sequence is the primary text.

Course Schedule

Weekly rhythm: two tutorials before class → studio work in breakout rooms during class → checkpoint due before the next session. The sequence follows all thirty Creative Coding II tutorials in order at tutorials.ij8.ai. Calendar dates will be added from the Registrar's Official Dates for Terms once the course is scheduled.

Arc I — Architecture Before Code

Week 1 — From Sketches to Systems

• Complete: 01 From Sketches to Systems · 02 State, Time, and the Loop
• Concept thread: what changes when a program has to run live — the frame loop as a contract; state that persists across frames; fixed versus variable time steps; the difference between a sketch and a system
• Studio: course orientation; examples and critique; dissect a live system on screen — where is its state, where is its time; reference environment setup
• Checkpoint: state-and-time map of the chosen system

Week 2 — Events and Maps

• Complete: 03 Events and Messages · 04 Mapping a System Before Building It
• Concept thread: input events, timers, and messages between parts; the event flow as a diagram; parts, responsibilities, and boundaries; drawing a system before touching a keyboard
• Studio: architecture-drawing workshop; trace an input event through a supplied system from device to screen; Project 1 dissection; Project 2 sketches
• Due: Project 1 — System Anatomy

Week 3 — Context and Decomposition for an AI Collaborator

• Complete: 05 Context Engineering for a Codebase · 06 Decomposing Work for an AI Collaborator
• Concept thread: repository instructions, architecture notes, constraints, and definitions of done; turning an architecture into bounded tasks a collaborator can implement one at a time; why the architecture must be decided by the student before it is delegated
• Studio: write a project context document; decompose Project 2 into tasks; run the first task with a coding agent and review the result
• Checkpoint: context document + first two tasks implemented and verified

Week 4 — Reading and Verifying Multi-File Systems

• Complete: 07 Reading Multi-File Programs · 08 Verification for Real-Time Systems
• Concept thread: navigating a program that spans files; following a value across boundaries; instrumentation, logging, and frame-time overlays as evidence; why "it looks right" is not verification for a system that depends on time
• Studio: reading clinic on a substantial unfamiliar codebase; instrumentation lab; Project 4 critique and architecture walks
• Due: Project 2 — Architecture Before Code

Arc II — Objects and Structures

Week 5 — Responsibility and Relationship

• Complete: 09 Classes Revisited: Responsibility and Encapsulation · 10 Inheritance, Interfaces, and Polymorphism
• Concept thread: a class as a responsibility, not a container; hiding what should be hidden; is-a versus can-do; polymorphism as the mechanism that lets a system treat different things the same way
• Studio: object-modeling workshop; refactor a supplied hierarchy; Project 5 proposals
• Checkpoint: written object model + inheritance-versus-composition decision drafted

Week 6 — Composition and Collections

• Complete: 11 Composition Over Inheritance · 12 Lists, Stacks, and Queues
• Concept thread: assembling behavior from parts rather than inheriting it; when a hierarchy is the wrong shape; ordered collections and what each is good at; cost of insertion, removal, and search
• Studio: convert an inheritance design to composition and compare; collections lab under real-time load
• Due: Project 3 — Object Design

Week 7 — Lookup, Hierarchy, and Space

• Complete: 13 Maps and Lookup · 14 Trees, Graphs, and Hierarchies
• Concept thread: keyed lookup; scene graphs and parent–child transforms; graphs for relationships and paths; choosing a structure by asking what question the system needs answered fastest
• Studio: build a small scene graph; graph traversal on a creative problem; review an AI-generated architecture proposal for Project 4
• Checkpoint: first structure implemented + generated-architecture review

Week 8 — Neighbors and Budgets

• Complete: 15 Spatial Structures: Grids, Quadtrees, and Neighbors · 16 Measuring Performance: Frame Budgets and Profiling
• Concept thread: the neighbor problem and why naive solutions collapse; grids and quadtrees; the frame budget as a hard constraint; profiling before optimizing; the structural cause of slowness
• Studio: performance lab at three population sizes; Project 4 critique and architecture walks
• Due: Project 4 — Structures Under Load

Arc III — Interaction and State

Week 9 — Modes and Inputs

• Complete: 17 State Machines · 18 Input Models: Mouse, Keyboard, Touch, Controllers, and Sensors
• Concept thread: the application as a set of modes with explicit transitions; drawing the state machine before coding it; abstracting input so that the system does not care which device produced it
• Studio: state-machine diagramming; input-abstraction lab; Project 5 proposals
• Checkpoint: state-machine diagram + input model

Week 10 — Feel and Motion

• Complete: 19 Timing, Easing, and Feel · 20 Physics and Motion Systems
• Concept thread: why responsiveness is a design property; easing, anticipation, and feedback; forces, integration, and constraints as a structured system rather than ad-hoc motion
• Studio: feel critique — the same interaction with different timing; motion-system lab
• Due: Project 5 — Interaction Model

Week 11 — Sound and the Outside World

• Complete: 21 Sound, Signals, and Real-Time Audio · 22 Networked and External Data in Real Time
• Concept thread: audio as a real-time system with its own timing constraints; analysis and synthesis; data arriving from outside the program — networks, sensors, other machines — and what it does to the architecture
• Studio: sound-reactive and networked experiments; Project 6 integration clinic
• Checkpoint: external signal integrated + robustness pass

Week 12 — Reviewing and Testing

• Complete: 23 Reviewing AI-Generated Architecture · 24 Testing Interaction
• Concept thread: what generated architecture gets wrong — hidden global state, tangled responsibilities, premature abstraction; accepting, revising, and refusing; testing behavior that depends on time and input; recording and replaying input
• Studio: architecture-review lab on peers' systems; Project 6 critique and architecture walks
• Due: Project 6 — Live System

Arc IV — Systems That Perform

Week 13 — The Rendering Pipeline

• Complete: 25 Rendering Pipelines and the GPU · 26 Shaders as Parallel Programs
• Concept thread: what happens between the draw call and the pixel; why the GPU changes what is cheap and what is expensive; shaders as a different model of computation, introduced conceptually and through small experiments
• Studio: pipeline walkthrough; first shader experiments; capstone architecture reviews
• Checkpoint: capstone architecture specification + first build

Week 14 — Optimization and Robustness

• Complete: 27 Optimization: When and How · 28 Robustness: Errors, Recovery, and Live Conditions
• Concept thread: optimizing the structure, not the line; knowing when to stop; what happens when a system fails on stage — error handling, recovery, degraded modes, and the difference between a demo and a performance
• Studio: capstone performance and robustness clinic; peer critique
• Checkpoint: working capstone + measured performance report + draft Architecture Record

Week 15 — Records and Presentation

• Complete: 29 Documentation and Architecture Records · 30 Presenting Systems: Demo, Diagram, and Critique
• Concept thread: documenting a system so that someone else — or the student, a year later — can change it; presenting a system through its diagram as well as its demo
• Studio: final technical review; presentation rehearsals; critique
• No new deliverable — the final week of classes is protected for revision

Finals — Capstone Presentations, during the official examination period

• Due: Project 7 — Individual Capstone: Real-Time System, presented live with an architecture walk and critique in the officially scheduled examination slot (per the Registrar's examination schedule once published)

Course Guidelines

As this course is taught completely online, there are certain expectations that should be adhered to. The following guidelines detail the most important aspects of the online format:

Expectations

Students are expected to resolve ordinary technical issues, be active problem solvers, and embrace challenges as positive learning opportunities. This course explicitly normalizes documentation → inspection → experimentation → debugging → asking for help as the expected development process. A malfunctioning system is not automatically evidence of failure; being unable to explain what has been tried, what has been observed, and where the system fails is the more significant problem.

Absent questions or requests for assistance, the instructor must assume that students understand the material being covered and are able to complete the assignments. It is primarily through your questions that the instructor learns where students are struggling and which topics deserve more time.

Workload

Consistent with SMU's Credit Hour Policy, students in this three-credit course should expect approximately nine or more hours of total course engagement per week averaged across the semester, including the live session. A typical week: 1.5 hours of synchronous studio; 1–1.5 hours of tutorials and explainer videos; 1–2 hours of focused technical and design exercises; and 4–5 hours of project development, measurement, documentation, and revision. Capstone weeks may redistribute this time toward project development.

Attendance & Breakout Participation

Because class time is studio work time, attendance at live sessions matters more here than in a lecture course. Participation (10% of your grade) means more than being logged into Zoom: it is earned through preparedness (tutorials completed, project files in hand), active building and debugging in breakout studios, the quality of critique you give peers, helping peers reason about problems without simply producing their work for them, receiving criticism constructively, and participating in architecture walks when asked. More than two unexcused absences from live sessions will reduce the participation grade; see the University Policies section for excused-absence categories.

Assessment

This course consists of a number of assignments and projects to be completed throughout the term. It is expected that all students will put forth the effort required to earn an 'A' letter grade for this course. Assignment grades will be determined using evaluation rubrics. You are responsible for reviewing the rubrics and raising questions or concerns related to the assignments, their rubrics, and their grading prior to the submission of each assignment. Questions regarding the grading of any assignment should be directed to the course instructor as soon as possible.

The course evaluates architectural reasoning and purposeful decision-making rather than maximal complexity. Because AI tools are used throughout, every project includes an architecture walk: during studio or the final presentation, the student explains any part of the submitted system — from diagram to code — on request. A system the student cannot explain is not yet the student's work, whatever tool produced it. Experimentation carries legitimate risk: students will not be penalized merely because an ambitious experiment reveals that an approach does not work. What matters is the ability to observe → diagnose → understand → revise, turning failures into a better structure, an instrument, or a test.

The final grade for the course will be calculated on the basis of the earned cumulative percentage and the grade received for each of the components of the cumulative percentage. If you earn less than 60% (grade of D) in any one of these components, you will receive a final grade of F for this course. A course grade of Incomplete (I) will be given only in the case of extraordinary circumstances that prevent the student from finishing the semester; students must have completed at least 50% of the course with a passing grade to be eligible.

Collaboration

Major projects are normally individual, so that each student develops an identifiable creative and technical position. Students are strongly encouraged to critique one another's work, review one another's architecture, discuss debugging strategies, share public documentation and references, pair temporarily during technical exercises, and explain concepts to peers. Students may not submit another student's project, or significant uncredited portions of another student's implementation, as their own. Shared code, open-source components, and AI-generated material must be documented in the Architecture Record when materially significant.

Communication Patterns

Direct communications with the instructor should be made in the manner indicated by the instructor. General questions relevant to multiple students — that is, questions that are not specific to an individual and do not involve private information — should be posted on the course discussion board. It is the student's responsibility to ensure that all communications are received or acted upon. All students should be familiar with the Netiquette guidelines observed in this course.

Generative AI Policy (Course-Specific)

This is a course about designing software systems in an era when AI systems implement most of the code; the use of generative AI tools is therefore expected and required for implementation, debugging, design exploration, documentation, and testing. Seven rules bound that use:

1. AI collaboration is expected. Students may use generative AI throughout all legitimate course activities, and are taught to direct it well.
2. Architecture is yours. The system's structure — its parts, state, time, and event model — is decided and documented by the student before implementation is delegated. Generated architecture may be consulted, but it must be reviewed and is never accepted by default.
3. You are the author of record. You must be able to explain any part of any system you submit, from diagram to code; every project includes an architecture walk. "The model produced it" is not an explanation of how the system works.
4. Generated code must be verified. Instrument, run, measure, and test rather than accepting an AI system's description of what it implemented; for a real-time system, measurement is the evidence.
5. Disclose. Each project's Architecture Record includes an AI Collaboration Note identifying the tools and models used, what they contributed, what you changed or refused, and how significant outputs were verified. Fluency in describing your process is itself a learning outcome.
6. Evidence must be real. Performance measurements, user tests, and other empirical claims must correspond to real activity. Fabricating evidence and presenting it as real is an Honor Code violation.
7. Protect sensitive information. Do not submit confidential university information, private personal information, credentials, or other restricted data to external AI systems.

Accessibility and Audience

Interactive systems are made for people, and the people are part of the system. Applications are expected to be operable by more than one input type where the idea allows; to consider color contrast and not rely on color alone to carry state; to give clear feedback for every action; and to handle wrong, fast, or absent input without breaking. This is treated as part of interaction design, not as a compliance step.

Technology

To be successful in this course, students should be comfortable with introductory programming (per the prerequisite) and current AI assistant tools. This fully online course occurs primarily via SMU Canvas. Zoom web conferencing is used for the weekly live class session and breakout studios, and Panopto is used for recording audio/video assignments (including recorded project walkthroughs).

Important: A webcam is required for live sessions and recorded presentations. Please be sure your devices meet the technical requirements for Canvas and Zoom. If you run into technical problems, you can always check with me first; you can also contact the SMU IT Help Desk for assistance with Canvas, Zoom, and Panopto.

Privacy and accessibility policies: Canvas · Panopto · Zoom · SMU OIT Policies · Accessibility: Canvas · Zoom

University Policies (Required Syllabus Statements)

This course follows all current SMU required syllabus statements. The statements below reflect the official language as of August 2026; the published semester syllabus will incorporate the then-current official SMU language verbatim, with term-specific dates from the Registrar's calendar.

Academic Dishonesty / Honor Code

Students are expected to embrace and uphold the SMU Honor Code. Violations of the Honor Code — including plagiarism, fabrication of evidence, and misrepresentation of AI-generated work as required by this course's Generative AI Policy — will be handled in accordance with the policies and procedures in the Mustang Student Handbook.

Disability Accommodations

Students who need academic accommodations for a disability must first register with Disability Accommodations & Success Strategies (DASS). Students can call 214-768-1470 or visit smu.edu/DASS to begin the process. Once they are registered and approved, students submit a DASS Accommodation Letter through the electronic portal, DASS Link, and then communicate directly with each of their instructors to make appropriate arrangements. Please note that accommodations are not retroactive and require advance notice to implement.

Religious Observance

Religiously observant students wishing to be absent on holidays that require missing class should notify their professors in writing at the beginning of the semester, and should discuss with them, in advance, acceptable ways of making up any work missed because of the absence. The University Calendar's religious-holidays addendum lists the request deadline for each term; for holidays not listed, contact the Office of the Chaplain.

Excused Absences for University Extracurricular Activities

Students participating in an officially sanctioned, scheduled university extracurricular activity should be given the opportunity to make up class assignments or other graded assignments missed as a result of their participation. It is the responsibility of the student to make arrangements with the instructor prior to any missed scheduled examination or other missed assignment.

Medical-Related Absences

To ensure academic continuity and avoid any course penalties, students with a medical-related absence should follow the procedures described in this syllabus in order to be provided with appropriate modifications to assignments, deadlines, and exams: notify me as soon as reasonably possible (email is fine), and we will arrange make-up work and adjusted deadlines to maintain your academic continuity in the course.

Final Exams

Final course assessments must be administered as specified in the official examination schedule and shall not be administered or due during the last week of classes or during the Reading Period. Final capstone presentations for this course occur in the officially scheduled examination slot for the term in which the course is offered.

Title IX / Sexual Harassment

All forms of sexual harassment, including sexual assault, dating violence, domestic violence, and stalking, are violations of SMU's Title IX Sexual Harassment Policy and may also violate Texas law. Students who wish to file a complaint or to receive more information about the grievance process may contact the Title IX Coordinator at equalopportunity@smu.edu or 214-768-3601. Please note: faculty and certain staff are mandatory reporters, and all reports of sexual harassment made to them must be forwarded to the Title IX Coordinator. Anyone wishing to speak confidentially may contact SMU Counseling Services (214-768-2277) or the Chaplain's Office (214-768-4502).

Pregnant and Parenting Students

Students who are pregnant or parenting may request academic adjustments by contacting the Office of Student Advocacy and Support by calling 214-768-4564. Adjustments are not retroactive and require advance notice to implement.

Credit Hour Policy

In accordance with federal policy and SACSCOC standards, SMU defines a credit hour as the amount of work represented in the achievement of student learning outcomes that reasonably approximates one hour (50 minutes) of instruction and a minimum of two hours of out-of-class student work per week for each credit hour. See the Workload section above for how this course meets that expectation.

Inclement Weather and Emergency Operations

In the event that SMU cancels classes due to inclement weather or emergency operations, students should reference SMU's inclement weather guidelines for further information. As a fully online course, instruction will generally continue as scheduled unless university operations are suspended; any changes will be announced via Canvas.

Zoom Use Guidelines

SACSCOC and university policy require that all in-person classes be taught in person and not moved to Zoom or other technology-mediated modalities, except for extenuating circumstances. This course is approved as a fully online course; the weekly live Zoom studio is its designed instructional modality.

Recording of Classes

Unauthorized student recording of class sessions is prohibited. Recordings are permitted only with advance instructor permission or as an approved DASS accommodation. Institutional recordings of live sessions (made available for review through Canvas) are for personal educational use by students enrolled in this course and may not be shared outside the class without written consent.

Student Advising and Academic Success

Students needing assistance with writing assignments may schedule an appointment with the Writing Center through Canvas. Students who would like support for subject-specific tutoring or developing other academic success strategies should contact Student Academic Success Programs (SASP), Loyd All Sports Center, Suite 202, 214-768-3648, smu.edu/sasp.

Caring Community Connections (CCC)

CCC is a resource for anyone in the SMU community to refer students of concern to the Office of the Dean of Students. The online referral form can be found at smu.edu/deanofstudentsccc. After a referral form is submitted, students will be contacted to discuss the concern, strategize options, and be connected to appropriate resources. Anyone unclear about what steps to take should consult the CCC Reference Guide or contact the Office of the Dean of Students at 214-768-4564.

Mental Health: On-Call and Ongoing Support

Students who are in distress or have concerns about their mental health can seek support from Counseling Services by calling the Dr. Bob Smith Health Center at 214-768-2277 to schedule a same-day or next-day appointment. A counselor is also available for crisis support 24 hours a day, seven days a week at the same number. SMU Teletherapy provides additional free, on-demand counseling options.

Campus Carry

In accordance with Texas Senate Bill 11, also known as the "campus carry" law, and following consultation with the entire University community, SMU chooses to remain a weapons-free campus. Please see the SMU policy for more details.

Student Services

The following services and resources are available to SMU students:

• Student Academic Success Programs / Learning Center — study-skill workshops, learning strategies, tutoring, and test preparation. 214-768-3648.
• Writing Center — technical advice on assigned papers, by appointment. 214-768-3648.
• Caring Community Connections Program — referrals for students of concern. 214-768-4564.
• DASS — disability accommodations. 214-768-1470.
• my.SMU — personal information, class schedule, enrollment, grades, and financial aid.
• SMU Bursar — student finances and bill pay.
• SMU Counseling Services — 214-768-2277; 24/7 crisis support at the same number.
• SMU Dedman Recreation Center — regular exercise is one of the best things you can do for your mental and physical well-being.
• SMU Libraries — reference librarians happy to help with research needs. 214-768-2326.
• SMU OIT — computing and technology support services.
• SMU Student Affairs — departments, programs, and services supporting students' out-of-classroom experiences.

Syllabus Revision

Because generative AI tooling and standards are changing unusually quickly, the instructor may revise individual technologies, model providers, technical examples, tutorials, or project milestones in response to significant changes in the field. Changes will preserve the approved course learning outcomes and will be communicated through Canvas; students will not be disadvantaged by a technology change introduced during the semester. Any other changes to this syllabus will be announced in class and posted to Canvas.