AI coding assistants are tools that use large language models to suggest, generate, explain, and refactor code directly inside a developer's editor or terminal. Current examples include GitHub Copilot, Claude Code, and OpenAI's Codex-family tools. They range from inline autocomplete that finishes the line you are typing, to chat interfaces that answer questions about your project, to agent modes that can plan and carry out multi-step tasks across several files.
In this course these tools matter because interface work is iterative: you sketch a layout, build a prototype, test it with users, and revise. An assistant that can scaffold a component, draft placeholder content, or convert a design description into working markup shortens the distance between an idea and something you can actually put in front of a user. That speed is only useful if you can judge what comes back — AI output can be plausible but wrong, inaccessible, inconsistent with your design system, or built on assumptions you never stated.
The videos below introduce the practical shape of these tools. As you watch, pay attention to three things: where in the workflow the assistant is invoked (inline, chat, or agent), how much context the human has to supply for the output to be useful, and what the presenter does to check the result before accepting it. Those three habits — invoke, specify, verify — are what you will carry into the rest of the module.
A short tour of GitHub Copilot inside Visual Studio Code, showing the different surfaces where the assistant appears: inline suggestions as you type, the chat panel, and editor commands. It is framed as an orientation for someone who has just turned Copilot on and wants to start using it right away, including tips on how to interact with it effectively. Expect practical demonstration rather than conceptual discussion.
Produced by the Visual Studio Code team itself, so the interface details and interaction patterns are authoritative and current for the tool it covers. It gives you a concrete answer to the subtopic "What Are AI Coding Assistants?" by showing one in actual use.
An IBM Technology explainer on spec-driven development, the practice of writing a clear specification first and letting the AI assistant generate implementation from it rather than prompting ad hoc. The video discusses how AI-assisted coding fits into a development process and what changes when the specification, not the code, becomes the primary artifact you author and review.
It moves beyond tool mechanics to the workflow question at the center of this topic — where AI sits in the pipeline and what the human is responsible for. The spec-first framing also sets up the module's later emphasis on evaluating output against stated requirements.
A walkthrough of GitHub Copilot's agent mode, in which the assistant acts more autonomously: taking a high-level request, planning the steps, creating and editing multiple files, and iterating toward a working application. The demonstration starts from scratch, so you see how much scaffolding an agent can produce from a prompt and how the developer supervises the process.
Agent mode is the clearest illustration of both the opportunity and the limitation of AI-assisted design — large amounts of code quickly, with the human responsible for reviewing decisions they did not make. Again from the Visual Studio Code channel, so the demonstration reflects how the feature actually behaves.
Together these videos build the descriptive foundation MO1 asks for: the first shows what an assistant is and where it lives in the editor, the IBM explainer places it within a development process, and the agent-mode walkthrough shows how far that role can extend. The hands-on demonstrations model the scaffolding and drafting workflows you will practice for MO2, including how to phrase requests so the generated code matches your project requirements. The spec-driven framing and the supervision shown in agent mode set up MO3 by making clear that AI output is a draft to be checked — in this course, against HCI principles, accessibility expectations, and usability standards, which no assistant evaluates for you.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Working with an AI assistant on a design task is itself an interface problem. The prompt is the control surface: what you type determines what the system can do for you, and vague input produces generic, unusable output. In this topic we treat prompting as a skill with structure — giving the model role and context, stating the task and constraints, specifying the output format, and supplying examples when the format matters.
For interface work, prompts also need domain content. A prompt that asks for "a login screen" gets you a cliche; a prompt that names the target users, the platform, the design system tokens, the WCAG contrast and focus requirements, and the error states you must handle gets you something you can actually critique and refine. Refinement is the normal case, not a failure: you read the output, find where it drifted from your intent, and change one thing in the prompt to close that gap.
The three videos below move from practical technique to a research view of why prompting is harder than it looks. While watching, collect concrete patterns you can reuse — ways to supply context, to constrain output format, to ask the model to reason or to critique its own work — and note the failure modes: over-trusting a confident answer, changing many things at once between attempts, and assuming the model shares background knowledge you never stated.
GitHub's tutorial introduction to prompt engineering for developers, aimed at people who are getting vague or unusable answers from large language models. Based on its title and description, it covers the essentials of how LLMs interpret input and the components of a prompt that reliably improve results, such as supplying context, being specific about the task, and shaping the output.
It comes from GitHub, a producer of widely used AI developer tooling, and it maps directly onto the Principles of Effective Prompting subtopic with a developer-facing vocabulary you will reuse when prompting for code scaffolding.
A Visual Studio Code video presenting four prompting techniques that generalize across AI tools and tasks, not just coding. Expect concrete, reusable prompt patterns demonstrated on practical examples, with attention to how rephrasing or adding structure changes the quality of the response.
The focus on a small set of transferable techniques gives you a starting toolkit for iterative prompt refinement and for embedding design system or requirement details into prompts, and it comes from the team behind a mainstream AI-assisted editor.
A conference talk video from ACM SIGCHI presenting the research paper "Why Johnny Can't Prompt," a study of how people without AI expertise attempt to design prompts. It reports where non-experts go wrong — such as over-generalizing from a single success, treating the model like a person who shares their assumptions, and refining prompts opportunistically rather than systematically.
This is peer-reviewed HCI research presented by its authors, and it directly addresses Avoiding Common Prompting Pitfalls and Iterative Prompt Refinement by naming the specific habits that make prompting fail.
Together these videos build the prompting competence the module outcomes depend on. The GitHub and VS Code tutorials give you the structural patterns needed to apply AI tools to generate layouts, content drafts, or code scaffolding that actually reflect your project requirements, which supports MO2, while also clarifying what these assistants can and cannot do in a design workflow (MO1). The SIGCHI research talk supports MO3 by showing that prompt outputs and prompting strategies both need deliberate evaluation: recognizing common failure patterns is what lets you judge AI-generated design output against HCI principles and usability standards rather than accepting the first plausible result.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Prototyping has always been the heart of HCI practice: you sketch an idea, build something just real enough to test, and learn from how people react to it. What has changed is the cost of getting from a wireframe to something clickable. AI coding assistants and design-tool integrations can now take a rough layout, a screenshot, or a written description and produce working component code in minutes, which shifts the bottleneck from "can we build it?" to "should we build it this way?"
This topic walks through the practical side of that shift. You will look at how a low-fidelity scaffold becomes code, how to generate and reuse components rather than one-off screens, how to iterate on a prototype through conversation with an assistant, and how to fold these tools into a team's existing workflow without creating chaos. Throughout, keep the trade-off in view: speed is only valuable if the artifact you produce is still testable, accessible, and consistent with your design system.
As you watch, pay attention to three things. First, what the human provides as input — the prompt, the frame, the existing design tokens — because output quality tracks input specificity closely. Second, where the demonstrator stops and corrects the AI, since those moments show you the judgment the tool cannot supply. Third, what is missing from the generated result: states, error handling, keyboard focus, responsive behavior. Those gaps are exactly where your HCI training earns its keep.
This walkthrough covers Figma's integration with AI agents such as Claude and Cursor, showing how UI can be generated directly on the canvas rather than being hand-drawn frame by frame. Expect a demonstration of the setup, the prompting process, and the handoff between design surface and code. It is a good illustration of the wireframe-to-code path in a tool students are likely already using.
It directly addresses the "From Wireframe to Code with AI" subtopic using current, widely adopted tools, and the presenter works through a real design task rather than a toy example.
A follow-up video focused on generating design system components with Claude, and on the distinction between running an AI assistant in the terminal versus working inside the design tool. It should cover how existing component libraries and conventions shape what the AI produces. The emphasis on systems rather than single screens is the key takeaway.
Component generation and design-system consistency are central to balancing speed with quality, so this video extends the previous one from one-off screens to reusable, maintainable building blocks.
A beginner-oriented tutorial on Cursor, the AI-native code editor, covering installation, the core interface, and the main ways of asking the assistant for code. Expect coverage of inline edits, chat-based requests, and giving the model context from your project files. This is the practical foundation for iterating on a prototype once code exists.
Tech With Tim is a well-established programming channel, and this widely viewed tutorial gives students the baseline editor skills needed to iterate on AI-generated prototypes and to work alongside teammates using the same tooling.
Together these videos move from concept to practice across the module outcomes. The Figma and Claude demonstrations show where AI tools sit in a contemporary design and development pipeline, supporting MO1, while the component-generation and Cursor tutorials give you concrete procedures for producing layout suggestions and code scaffolding from project requirements, which is MO2. For MO3, treat every generated artifact in these videos as a draft to be critiqued: as you watch, note the accessibility, consistency, and usability gaps that the demonstrations gloss over, and practice articulating what you would change before such a prototype reached a user test.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
AI tools can produce interface layouts, copy, and working code in seconds, but speed is not the same as quality. This topic asks a harder question: once an AI has generated something, how do you decide whether it is actually good? Design quality in an AI-assisted project still rests on the same foundations you have used all semester — usability heuristics, accessibility standards, consistency, and fitness for the intended users and context — but the review process changes because the output arrives faster, in larger volumes, and without a human author who can explain their reasoning.
The subtopics walk through a practical review pipeline. You first define what "quality" means for your project, then apply heuristic evaluation to AI-generated screens, audit generated markup and code for accessibility problems (missing labels, poor contrast, broken focus order, non-semantic elements), and establish code review habits that treat AI output as a draft from an unfamiliar collaborator rather than a finished deliverable. Finally, you consider how to keep your own design intent intact, so that the product reflects deliberate decisions rather than whatever the model happened to produce.
The three videos below approach this from complementary angles: using language models to critique UI mockups, simulating users to surface usability feedback, and the broader practice of using an AI model as an evaluator. While watching, note what each approach can reliably catch, what it misses, and where a human designer's judgment is still required. Pay particular attention to how evaluation criteria are specified — vague prompts produce vague critiques, while criteria grounded in heuristics or guidelines produce feedback you can act on.
A conference talk from the ACM CHI research community presenting a system that uses large language models to generate automatic design feedback on UI mockups. Based on the title and authorship, it likely explains how a mockup is represented for a model, how feedback is grounded in design guidelines, and how the generated critiques compare to feedback from human designers or experts. Expect discussion of both the quality of the automated feedback and its limitations.
It directly addresses heuristic-style evaluation of interface designs with AI assistance, and as peer-reviewed CHI research presented by ACM SIGCHI it models the kind of evidence-based, criteria-driven critique this topic asks you to adopt.
Another ACM SIGCHI research presentation, this one on SimUser, an approach that generates usability feedback by simulating different kinds of users interacting with a mobile application. The talk likely covers how user personas or characteristics are modeled, how simulated interaction traces are turned into usability observations, and how the results were validated. It should also surface where simulated feedback diverges from real user testing.
It extends evaluation beyond static screen critique to simulated use, which is useful when reviewing AI-generated interfaces quickly, and it prompts you to think carefully about which user differences a simulation can and cannot represent.
A short, accessible explainer from IBM Technology on the "LLM as a judge" pattern — using a language model to evaluate the outputs of another model. It is likely to cover why automated evaluation is needed at scale, how evaluation criteria and rubrics are defined, and common pitfalls such as bias in the judging model and the need for human verification. The framing is general rather than design-specific.
It gives you the conceptual vocabulary behind automated review and its reliability limits, which is exactly the caution you need when building code review and quality-check practices around AI-generated output.
Together these videos move you from understanding AI's role in the workflow toward critically judging what it produces. The two CHI talks show research-grade methods for evaluating interface designs and usability with AI support, giving you concrete models for applying heuristic and user-centered criteria to AI-generated layouts and code (MO3), while also illustrating how AI tools fit into real design and development pipelines (MO1). The IBM explainer supplies the underlying evaluation framework — defining rubrics, scaling review, and recognizing when automated judgment must be checked by a person — which supports disciplined review of the outputs you generate in your own project work (MO2, MO3).
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Using AI tools to generate layouts, copy, or code is now a normal part of interface work, but it raises questions that a tool cannot answer for you. Who gets credit for a design that an assistant largely produced? What happens when training data encodes stereotypes that surface in generated images, personas, or default settings? Can you legally ship code or assets that a model reproduced from someone else's work? This topic looks at those questions and at the professional obligations that come with them: being transparent about how work was produced, checking outputs for bias and misrepresentation, respecting licensing, keeping your own skills sharp, and deploying AI responsibly in products real people will use.
These concerns are not abstract for HCI practitioners. The designer is usually the last human checkpoint between a model's output and a user's screen, so judgments about attribution, fairness, and appropriateness land on you. Professional codes in computing treat this as a duty of competence, not a matter of taste: you are responsible for what you ship, regardless of which tool produced the first draft.
The three talks below approach the problem from different angles — present-day harms and bias, the data behind generative models and the creators it draws from, and the effect of heavy AI use on your own thinking. While watching, keep notes on concrete practices you could adopt: what you would disclose on a project, what you would check before accepting a generated interface element, and where you would deliberately do the work yourself.
AI ethics researcher Sasha Luccioni argues that speculative existential risk distracts from harms AI systems are causing right now, and points to issues such as bias in model outputs, environmental cost, and the use of copyrighted material in training data. The talk describes work on tools that let people examine and measure these problems rather than take vendor claims on faith.
It directly supports the bias and representation subtopic and gives students a vocabulary for discussing present-day, measurable harms; the TED platform and the speaker's research background make it a credible, accessible starting point.
Ed Newton-Rex, who worked in generative AI before resigning over training-data practices, examines how models are built from people, compute, and data, and why the creative work in that third category is often used without consent, credit, or compensation. The talk lays out the argument over whether training on copyrighted material is fair and discusses what could be done differently.
This is the clearest fit for the intellectual property and licensing subtopic, and the speaker's insider perspective helps students see why attribution and provenance matter in professional practice rather than only in legal filings.
Advait Sarkar looks at what happens to human reasoning when we routinely hand tasks to chatbots, and the trade-off between working faster and thinking less. The talk suggests ways to use AI that preserve rather than erode judgment and critical engagement with the work.
It speaks squarely to maintaining professional competence, and it gives students a practical frame for deciding when to use an assistant and when deferring to one undermines the evaluation skills this course is building.
Together these talks round out the module's picture of AI in HCI workflows. The first two deepen MO1 by showing what these tools actually are — systems built on specific data, with specific costs and biases — which is context students need before describing their role in design work. All three feed MO3 most directly: Luccioni gives students bias and representation criteria to test generated interfaces against, Newton-Rex supplies the provenance and licensing questions to ask about generated assets, and Sarkar argues for the kind of active critical review that keeps evaluation meaningful. The result is that when students apply AI tools under MO2, they do so with disclosure habits, checking routines, and a clear sense of where their own professional responsibility begins.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.