CRCP 3315: Creative Coding III

University-review revision · September 18, 2026. Proposed revisions to an existing course. This draft strengthens creative application in the description, outcomes, demonstrations, projects, and assessment. Prepared for faculty review.

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

An advanced creative coding studio in the development of software that enables artistic and design practice. Students build and extend creative libraries, instruments, authoring tools, generative systems, and performance or installation frameworks. Each project investigates a creative possibility, realizes it in usable software, and demonstrates its value through original works or experiences made with that software.

Design patterns, abstraction, interfaces, testing, resource management, and collaborative development are introduced through problems encountered while making and sustaining creative tools. Students investigate how a tool's structure enables or constrains gesture, variation, workflow, participation, and authorship. Engineering decisions are evaluated through both reliable behavior and the creative practices they support.

Students work in substantial codebases, direct and review bounded AI-agent contributions, rehearse creative use, and refine their tools through practitioner critique. The capstone pairs a reproducible release with original creative exemplars and evidence that another person can use or extend the software. The aim is to develop durable creative capabilities with an identifiable artistic or design position.

Prerequisite: CRCP 3305 or CS 1342. Students should arrive able to architect a multi-file program, apply object-oriented design, and choose basic data structures 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 III sequence — 30 tutorials spanning codebase entry, patterns and abstraction, engineering for reality, and shipping), plus a short creative application study connected to the current project. 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 — concepts and references supporting the week's creative question; 15–30 min — instructor demonstration of a technique through contrasting expressive choices; 30–70 min — breakout studio making, testing, and revision, with the instructor rotating between rooms; 70–90 min — presentation and critique connecting the work's form, behavior, and technical decisions to its intended experience.

Class time is work time. Come with the tutorials completed, your questions ready, and your repository 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:

• CLO 1: Develop reusable structures for a creative practice — select, implement, and critique design patterns within a tool, instrument, or generative framework, demonstrating the expressive possibilities each structural choice enables.
• CLO 2: Design interfaces that support artistic agency — prototype and refine public interfaces and module boundaries through creative use, showing how they support experimentation, expressive control, and extension by another maker.
• CLO 3: Sustain creative behavior under resource constraints — measure and revise memory, lifetime, allocation, or performance decisions in a working creative system and demonstrate the effects on continuity, density, responsiveness, or scale.
• CLO 4: Evaluate creative tools through tests and use — combine software tests with creative exemplars and practitioner observation to assess reliable behavior, expressive range, and the usability of the tool in an artistic workflow.
• CLO 5: Extend an existing creative codebase — develop a reviewable contribution that enables a new expressive capability or improves a creative workflow, and demonstrate the contribution through an original study.
• CLO 6: Direct AI agents within an authored creative project — specify creative and engineering constraints, review generated changes, and verify that accepted changes preserve or extend the intended artistic behavior and the maker's control.
• CLO 7: Release software that enables further creative work — deliver a reproducible, documented creative tool or framework with original exemplars and evidence that another practitioner can use or extend it.
• CLO 8: Critically evaluate the design of creative infrastructure — explain how interfaces, defaults, dependencies, authorship practices, accessibility, maintenance choices, and resource use shape who can create and what kinds of work become possible.

The weekly applied module outcomes in the schedule identify their corresponding course learning outcomes (CLOs). They provide the alignment for Canvas modules and project feedback.

Creative Practice and Applied Learning

Creative application is the organizing purpose of the course. Every demonstration, exercise, assignment, and project is situated in an artistic or design practice and contributes to a perceptible creative result, a purposeful interaction, or a capability that enables creative making. Concepts are introduced when students need them to make, understand, revise, or sustain their work. Technical studies include a clear connection to the creative behavior being investigated.

A generative-design library, creative instrument, animation or narrative toolkit, installation framework, or open-source creative contribution can meet the same creative and engineering expectations. Its expressive value must be demonstrated through original works or creative uses made possible by the software.

Every project includes: an expressive intention or creative question; experimentation with a meaningful alternative; a working realization; and a short account of how critique, testing, or observation informed revision. These elements are integrated into the existing project and its Process, Architecture, or Engineering Record as applicable. Weekly studies and checkpoints feed the scheduled projects; they do not create an additional category of assignments or increase the project count.

Demonstrations show creative decisions in action. Instructors connect each technique to its expressive consequences, compare plausible alternatives, and model how a maker selects and revises a direction. Students adapt the demonstrated principle to an intention of their own. Examples may rotate among media while retaining the stated outcomes and assessment criteria. Reproduction of a tutorial is preparation for a creative response, not a completed project.

Designed for many students and many instructors. Briefs support visual, sonic, narrative, interactive, performative, and hybrid realizations. Instructors can draw examples and critique language from their own practices while keeping creative intent, experimentation, realization, and explanation central. Students select tools and structures for the experience they are making; additional technical complexity earns credit only through a demonstrated contribution to that experience.

Studio balance. A typical 90-minute meeting allocates 15 minutes to contextual concepts, 15 to a creative demonstration, 40 to making and testing, and 20 to presentation and critique. Thus 75 minutes are devoted to demonstration, application, and critique. Projects account for 90% of the course grade and studio participation/process for 10%. Technical understanding is developed and assessed through creative practice throughout.

Reference Environment

The catalog description of this course names no programming language, and neither do its learning outcomes. That is deliberate. Patterns, abstraction, testing, resource reasoning, and collaborative engineering 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 make memory, resource, and performance decisions visible — typically a compiled, systems-capable language with a real build system, so that engineering choices have observable consequences; it must have a mature testing and tooling ecosystem; it must have a living open-source creative-coding community whose codebases students can enter; and it must be one that current AI coding agents 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.

• Engineering — the term's reference language, build system, and creative-coding framework (announced before registration); a full IDE with debugger and profiler; a test framework; a package or dependency manager.
• AI collaboration — an AI coding agent capable of multi-file changes in a repository (e.g., Claude Code, Cursor, or GitHub Copilot); an account with at least one frontier AI assistant (Claude, ChatGPT, or Gemini).
• Collaboration and delivery — Git + GitHub with branches, pull requests, and code review; continuous integration (e.g., GitHub Actions); a documentation generator; a release channel appropriate to the project.
• Studio — Zoom with a working webcam and microphone; SMU Canvas.

Projects

Each brief begins with a required creative task and evidence of its realization. The technical and process requirements support that task and are assessed through the common project rubric below. Creative studies, documentation, and tests are integrated parts of the project.

The semester is organized around five projects plus studio participation: two four-week projects that establish the practices of entering a codebase and designing one, two two-week projects that harden a system, and a capstone. The count is deliberately smaller than in the earlier courses — engineering is the practice of sustaining one thing over time, and the projects are long enough to make that real. 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-typography library, an audio-sequencing framework, a plugin architecture for a drawing tool, a control system for an installation, and a contribution to an existing open-source creative project are all valid answers to the same brief. Students are evaluated on whether their engineering decisions serve an individual creative intention.

Every project is accompanied by an Engineering Record — architecture decision records for the significant choices; the interface contract; the test and evaluation strategy; the AI Collaboration Note, including agent-produced changes that were refused; and the verification account — and is submitted as a Git repository whose history of branches, reviews, and merges shows the work developing.

Project 1 — Creative Codebase Intervention · Weeks 1–4 · 14%

Creative brief: Identify an expressive limitation or friction in an existing creative tool, then make a bounded contribution that enables a new artistic action or improves a specific creative workflow. Demonstrate its value in a short original study.

Creative evidence: Before-and-after creative use, the original study, a reviewable contribution, and a rationale connecting the change to the maker's experience.

Outcome alignment: CLO 1, 5, 6, 8.

Technical and process requirements: enter an existing, substantial creative-coding codebase — an open-source framework, library, or tool, or one supplied by the instructor — and make a bounded, reviewable contribution. Includes a map of the codebase's architecture, build, and conventions; identification of the principal design patterns or simpler structures already present, with an assessment of how they support or constrain creative use; a repository context document written for an AI agent; a contribution implemented on a branch, with at least one agent-produced change reviewed and either revised or refused; a pull request with a description a maintainer could act on; and the first Engineering Record. The contribution need not be large; it must be correct, tested, and explicable.

Project 2 — A Toolkit for Creative Variation · Weeks 5–8 · 18%

Creative brief: Design a reusable creative capability and make two meaningfully different works or studies with it. Use their differences to evaluate the expressive range and limits of the public interface; ask a peer to attempt a small creative use.

Creative evidence: Two contrasting original exemplars, the toolkit, peer-use observations, and an interface revision supported by that evidence.

Outcome alignment: CLO 1, 2, 4, 6, 8.

Technical and process requirements: design and build a small reusable library or framework for a creative purpose — a particle toolkit, a scene-graph layer, a generative-grammar engine, an animation timeline, a sequencer, a synthesis graph — in which interface design and patterns enable artistic experimentation and variation. Required concepts: a public interface designed and documented before implementation, with the alternatives considered; patterns selected for demonstrated creative and structural needs, each justified in an architecture decision record; explain when a simpler design is preferable; a unit-test suite with meaningful coverage of the public interface; a property-based or generative test for at least one behavior; an example program that uses the library as a stranger would; and a review of an agent-produced implementation of one component, identifying what was accepted, revised, or refused and why.

Project 3 — Sustaining Expressive Behavior · Weeks 9–10 · 14%

Creative brief: Define a creative ambition that exposes a resource or performance limit, such as denser polyphony, more intricate form, longer duration, or more responsive gesture. Refine the system and compare the resulting experience.

Creative evidence: A before-and-after creative enactment, measurements and tests, and an account of what became artistically possible and what tradeoffs remain.

Outcome alignment: CLO 3, 4, 8.

Technical and process requirements: take a substantial system — the Project 2 framework, a prior project, or an existing codebase — and establish the evidence that it works and how it behaves under load. Required: a measured performance and resource baseline; explicit reasoning about memory, ownership, and lifetime for the system's principal objects; at least one optimization with before-and-after measurement and a record of what was not optimized and why; and a test suite covering the public interface, including a property-based test.

Project 4 — Refactoring a Creative Practice · Weeks 11–12 · 16%

Creative brief: Refactor a creative tool under student direction while preserving its characteristic expressive behaviors and improving its capacity for further making. Choose a concrete creative workflow or extension to demonstrate the value of the refactor.

Creative evidence: A repeatable creative exemplar before and after the change, a demonstrated workflow or extension benefit, reviewed agent changes, and regression evidence.

Outcome alignment: CLO 2, 4, 5, 6, 8.

Technical and process requirements: a significant refactor of the Project 3 system executed by an AI agent under the student's direction, plus the hardening a real system needs. Required: the specification the student wrote before the agent ran; tests written before the agent ran that define behavior to be preserved; the agent's changes as reviewable diffs; the student's review, with changes accepted, revised, and refused; the passing suite and a repeated creative exemplar as evidence that the specified behaviors were preserved; a continuous-integration pipeline that runs the suite on every change; error handling, logging, and diagnostics appropriate to the system; and a security review of the system's inputs and dependencies.

Project 5 — Individual Capstone: Creative Tool and Original Works · Weeks 13–Finals · 28%

Creative brief: Release a tool, library, framework, application, or contribution that embodies an artistic or design position. Present at least two contrasting creative exemplars, which may develop earlier studies, and observe another maker using the release for a small creative task.

Creative evidence: The reproducible release, original exemplars, practitioner-use observations and resulting revisions, and documentation explaining creative possibilities as well as technical use.

Outcome alignment: CLO 1–8.

Technical and process requirements: a released, tested, documented piece of creative software — a library, a tool, an application, a framework, or a substantial open-source contribution — 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 five dimensions:

• Creative — clearly articulated intention; identifiable users or community; evidence of individual authorship.
• Engineering — a coherent architecture with documented decisions; deliberate patterns and interfaces; resource and performance reasoning; a system the student can explain in full.
• Verification — a test suite covering the public interface; evaluation of any AI-generated components by test; a regression strategy; evidence the student inspected actual behavior rather than accepting model claims.
• Delivery — a build others can reproduce; versioned release; user-facing and contributor-facing documentation; a license; continuous integration.
• Critical — an engineering report addressing authorship, sustainability and maintenance burden, security, AI-use disclosure, and the student's own position on the changing role of the programmer.

Final presentation: a live demonstration, an engineering walk (the student explains any part of the system, its tests, or its history 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.

Weekly checkpoints are required milestones of the five projects and are assessed within the project each feeds. Late or missing milestones reduce that project's grade.

Common Project Evaluation Framework

Every project is assessed through the working creative artifact and its development. The rubric assigns 60% to creative intention, expressive realization, and experimentation, and 40% to applied technical execution, comprehension, and process. These are proportions within each project; the project weights in the course grade remain as listed above.

The same criteria apply across visual, sonic, narrative, interactive, performative, and hybrid responses. Creative achievement is judged through intention, exploration, decisions, and their realized effects; a particular aesthetic, medium, expensive tool, or level of prior arts training is not required. Originality means a purposeful, individually authored response, supported by process evidence. Technical correctness alone does not satisfy a creative brief, and creative ambition does not remove the requirement for working, explainable software.

Studio participation and process are assessed through preparation of creative studies, substantive critique, responsive revision, and constructive contribution to others' work. Technical explanations, code walks, architecture reviews, and tests are assessed in relation to the student's creative practice. Conceptual knowledge is demonstrated through making, explanation, comparison, and critique; there is no separate theory examination.

Grading Scale

Materials

Required (all free or already provided):

• tutorials.ij8.ai — the Creative Coding III 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 capable of multi-file repository changes (Claude Code, Cursor, or GitHub Copilot)
• The term's reference language, build system, and creative-coding framework (free; announced before registration) and a full IDE with debugger and profiler
• Git + GitHub account with continuous integration enabled
• Zoom + a working webcam and microphone; SMU Canvas
• A computer capable of compiling and running the reference environment (any laptop of the last several years)

Recommended readings (linked per-module on Canvas; drawn from the tutorial reference lists): Gamma, Helm, Johnson, and Vlissides, Design Patterns (the original, read critically); Robert Nystrom, Game Programming Patterns (free online); Martin Fowler, Refactoring; the reference language's official style and testing guides; Google's Software Engineering at Google (free online, selected chapters); current guidance on agentic software development and code review from the major AI providers; essays on open-source sustainability and the ethics of engineering, refreshed each term. No conventional textbook is required; the tutorial sequence is the primary text.

Course Schedule

Each weekly checkpoint includes the current creative study or prototype, the expressive decision being investigated, and a brief record of what was learned or revised. Diagrams, traces, tests, and measurements explain the behavior of that work. These materials form part of the scheduled project submission. The final week remains reserved for revision of existing work.

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 III 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 — Entering a Codebase

Week 1 — What Software Engineering Is Now

• Complete: 01 What Software Engineering Is Now · 02 Reading a Codebase You Didn't Write
• Concept thread: the difference between a program and software; what changed when agents began writing most code — and what did not; strategies for entering a large codebase: entry points, data flow, conventions, tests as documentation
• Creative demonstration and studio — Tools shape creative possibility: Demonstrate how a creative codebase's defaults and interfaces shape the work made with it; students identify an expressive limitation and map the relevant system.
• Checkpoint: candidate codebase selected + first architecture map
• Applied module outcome (CLO 5, 8): Identify and explain a creative opportunity within an existing software tool.

Week 2 — Builds and Branches

• Complete: 03 Build Systems, Dependencies, and Toolchains · 04 Version Control as Collaboration: Branches, Reviews, and Pull Requests
• Concept thread: what a build actually does; dependency management and its failure modes; the branch as a proposal, the review as a conversation, the pull request as professional writing
• Creative demonstration and studio — A contribution someone can use: Demonstrate a reproducible creative example and its reviewable change; students build an existing tool and develop a bounded contribution through peer review.
• Checkpoint: reproducible build of the chosen codebase + first reviewed pull request
• Applied module outcome (CLO 5, 7): Prepare and review a contribution in relation to its effect on a creative workflow.

Week 3 — Directing an Agent in a Real Codebase

• Complete: 05 Context Engineering at Repository Scale · 06 Directing an Agent in a Real Codebase
• Concept thread: repository instructions, architecture notes, conventions, and definitions of done at the scale of a real project; bounded tasks; what an agent needs to know and what it must not be allowed to decide
• Creative demonstration and studio — Directing a creative intervention: Demonstrate an agent task constrained by an artistic example and observable behavior; students direct and inspect changes for their codebase intervention.
• Checkpoint: context document + agent-produced change under review
• Applied module outcome (CLO 5, 6): Specify and evaluate an agent-produced contribution against creative and technical requirements.

Week 4 — Reviewing and Refactoring

• Complete: 07 Reviewing Diffs: Trust Nothing, Verify Everything · 08 Refactoring Safely
• Concept thread: the review as the unit of engineering judgment; the characteristic failures of generated code — plausible but wrong, over-general, silently breaking a contract; refactoring under test; behavior-preserving change
• Creative demonstration and studio — Demonstrating the intervention: Demonstrate a before-and-after creative use and review the supporting diff; students present original studies and critique their interventions.
• Due: Project 1 — Creative Codebase Intervention
• Applied module outcome (CLO 4, 5, 6): Demonstrate and defend the expressive value of a tested creative-codebase contribution.

Arc II — Patterns and Abstraction

Week 5 — Why Patterns

• Complete: 09 Why Patterns: Problems That Recur · 10 Creational Patterns: Factory, Builder, Singleton — and When Not
• Concept thread: a pattern as a named solution to a recurring problem, not a template; the problem before the pattern; object creation as a design decision; the singleton as a cautionary tale
• Creative demonstration and studio — Patterns that enable variation: Demonstrate a reusable brush, voice, scene, or rule generator and compare alternative structures; students propose a toolkit through two intended creative uses.
• Checkpoint: Project 2 proposal + draft public interface
• Applied module outcome (CLO 1, 2): Select a reusable structure by showing the artistic variation it should enable.

Week 6 — Structure and Behavior

• Complete: 11 Structural Patterns: Adapter, Composite, Decorator, Facade · 12 Behavioral Patterns: Observer, Strategy, Command, State
• Concept thread: composing objects into larger structures; wrapping and adapting without modifying; distributing behavior — who decides, who is told, who can undo; patterns as they appear in creative-coding frameworks
• Creative demonstration and studio — Composable creative vocabularies: Demonstrate adapters, composites, strategies, or commands within a creative instrument; students implement structures and test them through contrasting expressive studies.
• Checkpoint: Project 2 first component implemented with an architecture decision record
• Applied module outcome (CLO 1, 2): Implement and evaluate a structural choice through its contribution to a creative vocabulary.

Week 7 — Interfaces and Dependencies

• Complete: 13 Designing Interfaces and APIs · 14 Coupling, Cohesion, and Dependency Direction
• Concept thread: the public interface as a promise; designing for the stranger who will use it; minimal surface, clear naming, hard-to-misuse; which way dependencies should point and why it matters for change
• Creative demonstration and studio — An interface another maker can explore: Demonstrate an unfamiliar peer tool through a small creative task; students observe use, critique the interface, and revise it.
• Checkpoint: Project 2 interface documented + unit tests on the public surface
• Applied module outcome (CLO 2, 4): Refine a public interface using evidence of another maker's creative experience.

Week 8 — Generality and Its Abuses

• Complete: 15 Generic Programming and Type-Driven Design · 16 Anti-Patterns and Pattern Abuse
• Concept thread: writing code that works over many types without losing meaning; types as design tools; over-engineering, speculative generality, pattern-for-its-own-sake — the failures generated code is most prone to
• Creative demonstration and studio — Range without unnecessary machinery: Compare a toolkit's contrasting original exemplars and identify its limits; students remove unjustified abstractions and critique A Toolkit for Creative Variation.
• Due: Project 2 — A Toolkit for Creative Variation
• Applied module outcome (CLO 1, 2, 4): Evaluate a toolkit's expressive range and justify its abstraction choices through working examples.

Arc III — Engineering for Reality

Week 9 — Memory and Measurement

• Complete: 17 Memory, Ownership, and Lifetime · 18 Performance Engineering: Measure, Then Optimize
• Concept thread: who owns an object and when it dies; allocation as a cost; the same questions in managed and unmanaged runtimes; profiling as the first step; the optimization that was not needed
• Creative demonstration and studio — Resources and artistic ambition: Demonstrate memory or timing pressure in a dense composition or long-running creative work; students establish a baseline tied to a chosen artistic ambition.
• Checkpoint: Project 3 baseline + ownership diagram
• Applied module outcome (CLO 3, 4): Measure a resource limit and explain its consequence for an intended creative behavior.

Week 10 — Many Things at Once, and Proving It Works

• Complete: 19 Concurrency and Parallelism · 20 Testing: Unit, Integration, and Property
• Concept thread: concurrency as a source of both speed and the hardest bugs; threads, tasks, and the GPU as models of parallelism, introduced conceptually; tests as the executable specification; property-based testing for behavior that has too many cases to enumerate
• Creative demonstration and studio — Preserving feel at scale: Demonstrate tests and measurements alongside a creative enactment before and after optimization; students evaluate continuity, responsiveness, and expressive tradeoffs.
• Due: Project 3 — Sustaining Expressive Behavior
• Applied module outcome (CLO 3, 4): Improve and verify a system while demonstrating the effect on its creative use.

Week 11 — Testing the Machine's Work

• Complete: 21 Testing AI-Generated Code · 22 Evaluation, Regression, and Continuous Integration
• Concept thread: why generated code demands more testing, not less; tests written before the agent runs; turning a real failure into a regression case; continuous integration as the system's immune response
• Creative demonstration and studio — A refactor grounded in creative exemplars: Demonstrate an agent refactor constrained by repeatable artistic behavior; students define exemplars, run reviewed changes, and configure regression checks.
• Checkpoint: refactor specification + behavior-preserving tests written; agent run; review in progress
• Applied module outcome (CLO 4, 6): Direct and test a refactor that preserves creative behavior and improves a specific workflow or extension.

Week 12 — Failure and Hostility

• Complete: 23 Error Handling, Logging, and Diagnostics · 24 Security Basics for Creative Software
• Concept thread: failing well — errors that explain themselves, logs that help, diagnostics that can be read later; untrusted input, unsafe dependencies, and the ways creative software gets attacked; the security consequences of code no human wrote
• Creative demonstration and studio — Failure during creative practice: Demonstrate recovery from bad input or a failed dependency during creative use; students rehearse recovery and critique the refactored tool.
• Due: Project 4 — Refactoring a Creative Practice
• Applied module outcome (CLO 3, 4, 6): Design and evaluate error behavior that sustains a maker's control and creative continuity.

Arc IV — Shipping and Sustaining

Week 13 — Releases and Documentation

• Complete: 25 Packaging, Releases, and Semantic Versioning · 26 Documentation as Engineering
• Concept thread: what it means to release; versioning as a contract with users; documentation for users and for contributors; the README as the front door and the architecture record as the floor plan
• Creative demonstration and studio — Releasing creative possibilities: Demonstrate a release through an original example and a new maker's first use; students prepare releases and documentation organized around creative tasks.
• Checkpoint: capstone specification + first release candidate
• Applied module outcome (CLO 2, 7): Package and explain a tool so another maker can reproduce and explore its creative capabilities.

Week 14 — Community and Time

• Complete: 27 Open Source, Licensing, and Community · 28 Maintaining Software Over Time
• Concept thread: licenses and what they permit; contribution, governance, and the burden of maintenance; software that outlives its author; deprecation, migration, and the debt that accrues while no one is looking
• Creative demonstration and studio — Another maker, another interpretation: Demonstrate how an outside interpretation exposes interface assumptions; students observe peer use and refine the release and existing exemplars.
• Checkpoint: working capstone release + draft Engineering Record
• Applied module outcome (CLO 4, 7, 8): Use practitioner feedback to improve a creative tool's accessibility, documentation, and expressive scope.

Week 15 — Ethics, Roles, and Presentation

• Complete: 29 Engineering Ethics and the Changing Role of the Programmer · 30 Presenting Engineering Work: Architecture Records and Demos
• Concept thread: responsibility for software one did not fully write; authorship, credit, and disclosure; sustainability and harm; what a programmer is for in an era of agents; presenting a system through its decisions, not only its demo
• Creative demonstration and studio — Presenting a tool through its works: Demonstrate a presentation that connects original works to design decisions and maintenance; students rehearse and refine existing capstone materials.
• No new deliverable — the final week of classes is protected for revision
• Applied module outcome (CLO 7, 8): Present a released creative tool and critically explain the artistic practices its design enables.

Finals — Capstone Presentations, during the official examination period

• Due: Project 5 — Individual Capstone: Creative Tool and Original Works, presented live with an engineering 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 failing build or a broken 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 engineering exercises and code review; and 4–5 hours of project development, testing, 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, repository in hand), active building, reviewing, and debugging in breakout studios, the quality of code review and critique you give peers, helping peers reason about problems without simply producing their work for them, receiving criticism constructively, and participating in engineering 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 engineering judgment rather than volume of code. Because AI agents are used throughout, every project includes an engineering walk: during studio or the final presentation, the student explains any part of the submitted system, its tests, or its history 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 design, a test, or a regression case.

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 — but code review is inherently collaborative, and reviewing one another's pull requests is a required studio activity. Students are strongly encouraged to critique one another's work, review one another's designs, 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 Engineering Record when materially significant, and open-source contributions must respect the license and contribution guidelines of the receiving project.

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 engineering software in an era when AI agents write most of it; the use of generative AI tools is therefore expected and required for implementation, refactoring, testing, documentation, and review. 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, review, and evaluate it as a professional would.
2. Architecture and interfaces are yours. The system's structure, its public contracts, and its test strategy are decided and documented by the student. Agents implement against those decisions; they do not make them.
3. You are the author of record. You must be able to explain any part of any system you submit, including code an agent wrote; every project includes an engineering walk. "The model produced it" is not an explanation of how the system works.
4. Generated code must be tested, not trusted. Every agent-produced change is reviewed as a diff and verified by test before it is merged; an AI system's description of what it implemented is a claim, not evidence.
5. Disclose. Each project's Engineering 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, test results, user feedback, 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 and respect licenses. Do not submit confidential university information, private personal information, credentials, or other restricted data to external AI systems, and do not contribute generated code to an open-source project whose policy forbids it.

Accessibility and Audience

Software is made for people, and released software is made for people the author will never meet. Tools and applications are expected to be operable by keyboard, to consider color contrast and not rely on color alone, to give clear feedback and readable errors, and to document their accessibility limits honestly. Libraries and frameworks are expected to make accessible use the easy default for the programs built on them. This is treated as part of interface design, not as a compliance step.

Technology

To be successful in this course, students should be comfortable with object-oriented programming and multi-file projects (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.