CRCP 1310: Creative Coding I

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 catalog number, title, credit hours, description, and role in the degree are unchanged from the in-person section.

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

Exploring computation as a powerful generative medium, students learn the fundamentals of coding and computational thinking, including an introduction to object-oriented programming. Hands-on topics may include algorithmic drawing, procedural imaging, 2-D and 3-D animation, visualization, interactivity, computational music, and gaming.

This course takes the phrase fundamentals of coding seriously at a moment when the fundamentals have shifted. AI systems now produce most of the syntax a working programmer once typed by hand. What they cannot do is decide what a program should be, know whether what they produced is what was meant, or take responsibility for it. So the fundamentals taught here are the durable ones: computational thinking — decomposing an intention into data, state, sequence, repetition, condition, and abstraction; reading and tracing — predicting what a program will do and explaining why it did something else; specification — saying precisely what you want before anything is built; and verification — running, looking, comparing, and correcting. Syntax and library APIs are learned in service of these, not memorized as an end in themselves.

Students work with AI coding tools from the second week, as a partner in the studio rather than a shortcut around it. The objective is programming literacy in an AI era: the ability to direct computation, inspect what was produced, understand it well enough to change it, and own the result. A student who can prompt but cannot read is not yet literate; a student who can read, specify, and verify is a programmer, whatever tools they use.

Just as important, computation is treated as a creative medium. Successful work might be an algorithmic drawing system, a procedural image, an animated composition, an interactive instrument, a data visualization, a computational score, or a small game. The technical sequence is shared; the creative destination is not. Students share technical competencies, not creative outcomes.

Prerequisite: None. No prior programming experience is expected or assumed. The course is open to majors, minors, and students from any school.

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 I sequence — 30 tutorials spanning first principles through a complete creative work), plus a short technical or creative exercise. 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 concept to art, design, and computational culture; 15–30 min — instructor demonstration or live-coding clinic; 30–70 min — breakout studio work (building, reading, tracing, debugging, critique) with the instructor rotating between rooms; 70–90 min — share-outs and critique of selected sketches, failures, and discoveries.

Class time is work time. Come with the tutorials completed, your questions ready, and your sketches 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: Think computationally — decompose a creative or functional intention into data, state, sequence, repetition, condition, and abstraction, and express it as a specification precise enough for a machine or a collaborator to execute.
• CLO 2: Read and trace programs — predict what a program will do before running it, trace state through execution, and explain the behavior of code written by someone — or something — else.
• CLO 3: Write and revise working programs — construct programs using variables, control flow, functions, collections, and objects in the course's reference environment, and revise them through observation rather than guesswork.
• CLO 4: Apply object-oriented thinking — model a creative system as interacting objects that carry state and behavior, and explain why that model fits the problem.
• CLO 5: Collaborate with AI as a programming partner — specify a task, prompt for it, inspect and test what is produced, correct it, and decide deliberately what to delegate and what to understand.
• CLO 6: Produce computational creative work — realize algorithmic drawing, procedural imaging, animation, interactivity, sound, visualization, or gaming as original work with an identifiable point of view.
• CLO 7: Debug and verify with evidence — reproduce, isolate, and fix errors using the program's actual output rather than assumptions or an AI system's account of what it did.
• CLO 8: Critique and contextualize computational work — discuss process, authorship, aesthetics, and the cultural position of generative computation, in one's own work and in the work of others.

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 technique discussed in the course. They are graded on whether they understand the techniques well enough to make intelligent decisions about using — or not using — them in service of an individual creative intention.

One student might build a drawing system that grows from a handful of rules. Another might make a procedural landscape, an animated typographic score, a particle instrument played with the keyboard, a visualization of a personal dataset, or a small game with strange physics. All are legitimate destinations for the same technical sequence.

A class is never added because the course covers classes; three-dimensional rendering is never added because it was in a tutorial. The simplest program that fully realizes the idea is the better program. Complexity must be earned by the idea.

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. The concepts taught here — state, control, abstraction, objects, specification, verification — are the same in every language, and the language a first course happens to use 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 three criteria: the loop from idea to visible result must be seconds, not minutes; the environment must be free and run in a browser or on any ordinary laptop; and it must be one that current AI coding tools handle fluently, so the AI partnership the course teaches is realistic from day one. 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 creative-coding environment (announced before registration); a browser-based or lightweight editor; a means of exporting stills, animations, and running sketches.
• AI collaboration — an account with at least one frontier AI assistant (Claude, ChatGPT, or Gemini); an AI coding tool integrated with the editor (e.g., Claude Code, Cursor, or GitHub Copilot) from Week 2.
• Process — Git + GitHub for every project from Week 3; a shared course gallery on Canvas where all work stays visible to the section.
• Studio — Zoom with a working webcam and microphone; SMU Canvas.

Projects

The semester is organized around nine projects plus studio participation. They begin as one-week sprints and lengthen as the course progresses, so that a student with no programming experience ships something in the first week, hears critique in the second, and builds toward a sustained final work by the end. 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 drawing system, a generative score, a playable instrument, a data animation, and a small game are all valid answers to the same brief. Students are evaluated on whether their technical decisions serve an individual creative intention, not on which medium they chose.

Every project is accompanied by a short Process Record — the specification the student wrote before building, the questions asked of AI tools and what came back, what was changed and why, and how the result was verified — and, from Project 3 on, is submitted as a Git repository whose commit history shows the work developing.

Project 1 — Creating by Instruction · Week 1 · 5%

The work: write a rule set for a drawing, a sound, or a movement in plain language; have a peer execute it by hand; then run the same rules as a first sketch in the reference environment. Includes the rule set, the peer's hand-executed result, the sketch, and a paragraph on where the two diverged. No programming knowledge is assumed — this is where it starts.

Evaluation emphasis: clarity and precision of the rule set; willingness to revise; a first identifiable creative direction.

Project 2 — Read, Predict, Partner · Week 2 · 5%

The work: three prediction traces — read a supplied sketch, draw or describe on paper what it will produce, run it, compare — completed without AI assistance; then a first session with an AI coding partner: ask for a small visual, sonic, or interactive sketch, read what comes back line by line, and change at least three things on purpose. Includes the traces, the annotated sketch, and the first Process Record.

Evaluation emphasis: reading and prediction accuracy; quality of the annotations; evidence the student changed the generated code rather than accepting it.

Project 3 — Rules as Medium · Weeks 3–4 · 8%

The work: a generative system that grows from a small set of rules the student specified before writing code — a drawing system, a rhythmic pattern, a responsive field. Required: a written specification with intention and acceptance criteria; variables as named state; at least one decision the program makes on its own; a Git repository with meaningful commits; a verification account comparing the specification to the result.

Evaluation emphasis: correspondence between specification and result; clarity of the rule set; formal quality in the chosen medium.

Project 4 — Pattern and Chance · Weeks 5–6 · 8%

The work: a pattern study built from repetition, condition, and controlled chance — a tiling, a texture, a generative sequence, a rhythm engine. Required: nested loops and conditionals used with intention; random versus noise used deliberately, with a seed so results can be reproduced; a hand-traced loop submitted before the code ran; a design space of at least four parameters, documented with examples.

Evaluation emphasis: control of repetition; expressive use of chance; tracing accuracy; range of the design space.

Project 5 — Procedural Time · Weeks 7–8 · 10%

The work: a time-based composition — an animation, a growing image, an evolving soundscape, a kinetic typographic piece — organized around named functions and the frame loop. Required: at least three functions that name ideas in the work; motion or change with deliberate easing and rhythm; transformations used to build coordinate spaces; a debugging narrative recording one real bug, how it was reproduced, and how it was fixed. AI tools are expected in the building; the student must be able to explain any function on request.

Evaluation emphasis: decomposition into functions; control of time; quality of the debugging narrative; comprehension of every part of the program.

Project 6 — First Objects · Weeks 9–10 · 10%

The work: a small world modeled as objects — a handful of creatures, notes, brushes, or players — that the audience can act on through mouse, keyboard, touch, or microphone. Required: at least one class the student designed, with a written model explaining why the world was modeled that way; a collection of instances; interaction that changes state; a trace of one input event from device to screen or speaker.

Evaluation emphasis: quality of the object model; interaction design; the student's own account of why objects were the right structure.

Project 7 — Object Worlds · Weeks 11–12 · 12%

The work: a system of many interacting objects — a flock, a particle instrument, an ecosystem, a sound-reactive environment, a playable toy — in which behavior emerges from simple rules. Required: objects that respond to one another; sound or visual output driven by the same state (either is fine; both is not required); a formative test with at least two people outside the class, documented with what surprised the student; and a critical review of a substantial piece of AI-generated code the student chose not to use, explaining what was wrong with it.

Evaluation emphasis: management of many things at once; emergent quality; evidence-based revision; critical reading of generated code.

Project 8 — Territory Sprint · Week 13 · 7%

The work: a one-week study in the territory the student intends for the final — pixels and procedural imaging, three dimensions, data and visualization, games and rules of play, or computational music — small enough to finish, real enough to learn from. Includes the study and a one-page final-project specification informed by what the sprint revealed.

Evaluation emphasis: speed and focus; what was learned; the quality of the resulting specification.

Project 9 — Final Work · Weeks 14–Finals · 25%

The work: an original creative computational work in any of the course's territories — algorithmic drawing, procedural imaging, 2-D or 3-D animation, visualization, interactivity, computational music, or gaming — that demonstrates the student's individual perspective and the course's accumulated competencies. Students may substantially develop an earlier project or pursue the direction tested in the Territory Sprint. The completed work addresses four dimensions:

• Creative — clearly articulated intention; a coherent visual, temporal, sonic, or interactive language; evidence of individual authorship rather than tutorial reproduction.
• Technical — a working program using state, control, functions, collections, and objects where the idea calls for them; readable structure; a program the student can explain in full.
• Process — a complete Process Record; a Git history showing the work developing; an AI Collaboration Note; a verification account describing how the student knows the program does what they intended.
• Critical — a short written reflection on authorship, process, and the position of the work within computational art and design.

Final presentation: a live demonstration, code walk (the student explains any part of the program the instructor or a peer selects), 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, where one exists, 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 program actually works — or whether they can explain it.

Grading Scale

Materials

Required (all free or already provided):

• tutorials.ij8.ai — the Creative Coding I 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 tool (Claude Code, Cursor, or GitHub Copilot) from Week 2
• The term's reference creative-coding environment (free; announced before registration) and a text editor
• Git + GitHub account from Week 3
• Zoom + a working webcam and microphone; SMU Canvas
• A computer capable of running a modern web browser; no special hardware is needed

Recommended readings (linked per-module on Canvas; drawn from the tutorial reference lists): the reference environment's official documentation; Ira Greenberg, Processing: Creative Coding and Generative Art (for concepts, regardless of language); Daniel Shiffman, The Nature of Code; Casey Reas and Chandler McWilliams, Form+Code in Design, Art, and Architecture; selected essays on generative art, computational aesthetics, and authorship, 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 I 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 — Thinking in Computation

Week 1 — Computation as a Creative Medium

• Complete: 01 Computation as a Creative Medium · 02 What a Program Is: Instructions, State, and Time
• Concept thread: what a program is and is not; a brief history of computational art from plotters to generative models; the three things a program always has — instructions, state, and time; why "fundamentals" means thinking, not syntax
• Studio: course orientation; examples and critique; creating by instruction (students write rules for a drawing, a sound, or a movement; other students execute them by hand); reference environment setup
• Due: Project 1 — Creating by Instruction

Week 2 — The Canvas and Reading Code

• Complete: 03 The Canvas: Coordinates, Shapes, and Color · 04 Reading Code Before Writing It
• Concept thread: the coordinate system; primitives, fill and stroke, color models; reading as the first skill — predicting what a sketch will draw before running it
• Studio: prediction exercises (read a sketch, sketch the result on paper, run it, compare); first AI coding tool session — ask for a drawing, then read what came back
• Due: Project 2 — Read, Predict, Partner

Week 3 — State and Specification

• Complete: 05 Variables and State · 06 Specifying Before Coding: From Intention to Rules
• Concept thread: variables as named state; how state changes over time; writing a specification — intention, constraints, what "done" looks like — before any code exists; the specification as the prompt
• Studio: repository setup; specification workshop — turn a vague creative idea into acceptance criteria; build from a peer's specification and see where it was ambiguous
• Checkpoint: Project 3 specification + Git repository with meaningful commits

Week 4 — Working With an AI Partner, and Verifying

• Complete: 07 Working With an AI Coding Partner · 08 Verifying: Run, Look, Compare, Fix
• Concept thread: the collaboration loop — specify → generate → read → run → compare → correct; what to delegate and what to understand; the program's actual output as the only evidence that counts
• Studio: verification clinic; deliberately break a sketch and recover it; critique of Project 3 drafts
• Due: Project 3 — Rules as Medium

Arc II — Rules, Repetition, and Time

Week 5 — Programs That Decide and Repeat

• Complete: 09 Conditionals: Programs That Decide · 10 Loops: Repetition and Pattern
• Concept thread: boolean logic and branching; iteration as the engine of pattern; nested repetition; tracing loops by hand
• Studio: pattern-generation lab; trace a nested loop on paper before running it; Project 4 proposals
• Checkpoint: hand-traced loop + first pattern study

Week 6 — Chance and Naming

• Complete: 11 Randomness, Noise, and Controlled Chance · 12 Functions: Naming Ideas
• Concept thread: random versus noise; seeds and reproducibility; functions as named ideas with inputs and outputs; decomposition — the program as a set of small, explainable parts
• Studio: refactor a long sketch into named functions; chance-versus-control critique; ask an AI tool to decompose a sketch and evaluate its choices
• Due: Project 4 — Pattern and Chance

Week 7 — Animation and Transformation

• Complete: 13 Animation: Frames, Motion, and Easing · 14 Transformations: Translate, Rotate, Scale
• Concept thread: the frame loop; motion as state changing over time; easing and rhythm; the transformation stack and coordinate spaces
• Studio: motion studies; transformation-stack exercises; timing critique
• Checkpoint: Project 5 in motion, functions named, parameters exposed

Week 8 — Debugging as Investigation

• Complete: 15 Debugging as Investigation · 16 Parameters and Design Spaces
• Concept thread: reproduce → isolate → hypothesize → test → fix; console output and visual instrumentation as evidence; why an AI system's explanation of a bug is a hypothesis, not a finding; exploring a design space systematically
• Studio: debugging clinic on real student bugs; Project 5 critique and code walks
• Due: Project 5 — Procedural Time

Arc III — Objects and Interaction

Week 9 — Many Things at Once

• Complete: 17 Arrays and Collections · 18 Objects: State and Behavior Together
• Concept thread: collections and indexing; iterating over many; the object as a bundle of state and behavior; modeling a world as things that know how to act
• Studio: object-modeling workshop — describe a system in prose, then as objects; Project 6 proposals
• Checkpoint: written object model + first class

Week 10 — Classes and Interaction

• Complete: 19 Classes: Making Many · 20 Interaction: Mouse, Keyboard, and Touch
• Concept thread: class versus instance; constructors; collections of objects; input events; the audience as part of the system
• Studio: build a class from a written model; interaction studies; trace an event from input through state to screen
• Due: Project 6 — First Objects

Week 11 — Systems and Sound

• Complete: 21 Object Systems: Particles, Flocks, and Agents · 22 Sound and Computational Music
• Concept thread: emergence from simple rules; objects that respond to one another; sound as another output of the same state; computational music as rules over time
• Studio: particle and flocking lab; sound-reactive experiments; formative user tests of Project 7 drafts
• Checkpoint: Project 7 with many interacting objects + user-test notes

Week 12 — Reading Generated Code Critically

• Complete: 23 Reading AI-Generated Code Critically · 24 Refactoring With Intention
• Concept thread: what generated code gets wrong — over-engineering, silent assumptions, plausible nonsense; deciding what to keep; refactoring toward clarity without changing behavior
• Studio: generated-code review lab; Project 7 critique and code walks
• Due: Project 7 — Object Worlds

Arc IV — Making a Work

Week 13 — Pixels and Depth

• Complete: 25 Images and Pixels: Procedural Imaging · 26 Into the Third Dimension
• Concept thread: the image as data; per-pixel computation; 3-D coordinates, cameras, and lighting as an extension of the same ideas; choosing the territory of the final work
• Studio: pixel-manipulation lab; 3-D orientation; Territory Sprint studio; final-project proposals
• Due: Project 8 — Territory Sprint, with the final-project specification

Week 14 — Data and Play

• Complete: 27 Data and Visualization · 28 Games and Rules of Play
• Concept thread: data as material; mapping values to form; games as rule systems with state, feedback, and goals; the same fundamentals, applied to two more territories
• Studio: final project work sessions; peer critique; code walks
• Checkpoint: working final project + draft Process Record

Week 15 — Process, Authorship, and Presentation

• Complete: 29 Documentation, Process, and Authorship · 30 Presenting and Critiquing Computational Work
• Concept thread: documenting a computational process; authorship when a machine wrote the syntax; how to present and critique generative work
• Studio: final technical review; presentation rehearsals; critique
• No new deliverable — the final week of classes is protected for revision

Finals — Final Presentations, during the official examination period

• Due: Project 9 — Final Work, presented live with a code 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 sketch is not automatically evidence of failure; being unable to explain what has been tried, what has been observed, and where the program 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 reading, tracing, and technical exercises; and 4–5 hours of project development, testing, documentation, and revision. Final-project 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, sketches 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 code 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 comprehension and purposeful decision-making rather than volume of code. Because AI tools are used throughout, every project includes a code walk: during studio or the final presentation, the student explains any part of the submitted program on request. A program 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.

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 individual, so that each student develops an identifiable creative and technical position. Students are strongly encouraged to critique one another's work, 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 Process 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 programming in an era when AI systems write code; the use of generative AI tools is therefore expected and, from Week 2, required for building, debugging, exploring, and documenting. Seven rules bound that use:

1. AI collaboration is expected. Students may use generative AI throughout all legitimate course activities, and are taught to do so well.
2. Reading comes first. Designated reading, tracing, and prediction exercises — in studio and in tutorials — are completed without AI assistance, because they measure the literacy that makes AI collaboration possible. These are clearly marked.
3. You are the author of record. You must be able to explain any part of any program you submit; every project includes a code walk. "The model produced it" is not an explanation of how the program works.
4. Generated code must be verified. Run, look, and compare rather than accepting an AI system's description of what it produced; the program's actual output is the only evidence that counts.
5. Disclose. Each project's Process Record includes an AI Collaboration Note identifying the tools and models used, what they contributed, what you changed, and how significant outputs were verified. Fluency in describing your process is itself a learning outcome.
6. Evidence must be real. User tests, sources, 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

Work made for an audience is expected to consider that audience. Interactive projects should be operable by keyboard as well as mouse where the idea allows; visual work should consider color contrast and not rely on color alone to carry meaning; sound work should be presentable with a visual alternative. This is introduced as part of design thinking, not as a compliance step.

Technology

No prior programming experience is required. Students should be comfortable installing free software, managing files, and using a modern web browser. 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.