NCAD AI Workshop Week 11 / 15

All tracks · especially UX, motion, graphic design, 3D — 4 hours, drop-in friendly

Coding for Artists: Websites, Tools, and Tiny Apps with Codex/Claude Code

Turn a recurring annoyance in your practice into a working tiny tool — spec-first, built by AI, inspected by you. Zero coding experience required.

▶ HTML Slides

01This Week at a Glance

You will make: a tiny tool spec — user, problem, inputs, outputs, UI sketch, build prompt. Building it is the bonus round; many of you will.

1 · Concepts (40 min)

The tiny tool category; spec-first; the build loop; inspection; the scope fence.

2 · Demo (45 min)

A working app built live from a spec the room writes — including the inspection and the planned failure.

3 · Lab (70 min)

Your friction → your spec → (your tool).

4 · Pitches (35 min)

60 seconds each, with honest ledgers.

Why this matters in real work

Not to become software engineers — code does four things for artists: prototype, automate, publish, make interactive work. The barrier collapsed; the bottleneck moved from "can you code?" to "can you specify?" — and specification is design thinking. The spec is the skill; the build is increasingly free.

02Key Concepts

1 · The tiny tool category (where artists win)

One user (you), one problem, one file if possible, no accounts, no server, no other people's data. Examples students actually use: a moodboard prompt generator, an export checklist app, a riso separation previewer, a commission price calculator, a crit-notes formatter. Single-file HTML runs in any browser, can't touch anything else, and is fully inspectable — the most reliable, lowest-risk zone for AI coding.

2 · Spec-first: the interview method

Don't start with "build me an app." Make the model interview you — one question at a time, max 6. Your answers become the spec: user, problem with honest frequency, inputs (≤6), outputs, UI in words with exact button labels, what it does NOT do (the feature-creep fence), and acceptance checks (3–5 testable sentences). Template: tiny-tool-spec-template.md.

The professional sentence

"Wrote the spec, directed the build, verified the result." Current, honest, hireable — and exactly how you'll work with human developers later.

3 · The build loop: client-revision thinking

One prompt builds the file. Open it, use it. Then: change requests describe outcomes ("the Copy button should visibly confirm"), and bug reports describe steps and symptoms. Same spirit as Blender week's error loop — you report, it repairs.

4 · Inspection habits (the trust layer)

After any build, three questions: what are the three main parts, where does my data go when I type it, does anything leave my computer? For a true tiny tool the answer is "nothing leaves your machine" — and you can verify it: skim the file for fetch or http. Ten seconds.

The big idea

Privacy became checkable the day software became readable conversation.

5 · The scope fence

The fence doesn't move

The moment a tool needs accounts, payments, or other people's data — it's not a tiny tool. App-builder platforms (Lovable/Bolt/v0-class) will happily build past the fence; the inspection habits stay mandatory and the risks multiply.

6 · The deeper route: creative coding as craft

Tiny tools are utility; creative coding (p5.js and friends) is art-making with code. AI is a patient tutor for it — and if today lights a fire, The Coding Train is where it goes next.

03This Week's Words

Tiny toolOne user, one problem, one file. No accounts, no server, no others' data.
SpecThe structured description a build runs from. The skill of the week.
Single-file HTMLA whole app in one file any browser opens.
Acceptance checks3–5 testable sentences defining "done." You wrote them; you check them.
Change requestDescribing a revision by outcome, not code.
Vibe codingBuilding by description without inspection. Fine for toys; reckless past the fence.
The scope fenceAccounts / payments / others' data = not a tiny tool.
Inspection questions"Three parts, where does my data go, does anything leave my machine?"
Coding agentClaude Code / Codex-class tools that read and edit real files.
Creative codingCode as art medium (p5.js etc.) — the deeper craft route.

Full course glossary →

04Demo: The Moodboard Prompt Generator, Built Live

I made this, so can you

The room writes the spec by answering the model's interview; the spec becomes a working app; the app survives a change request, an inspection, and a planned failure.

Prepared demo artifact

Instructor backup / finished example: moodboard-generator.html. Use it if the live tool run fails, or to reveal the finished structure after critique.

  1. The interview: the model asks; the room answers; the instructor arbitrates. Six questions → a complete spec.
  2. The build: spec + build prompt → saved as .html → opened → used live with shouted test inputs.
  3. The change request: the room picks one feature, pasted verbatim in client voice.
  4. The inspection: the three questions, then the proof — one scroll of the file: no fetch, no http, nothing leaves the machine.
  5. The planned failure: the change request breaks something; a client-voice bug report fixes it. "Describe the bug, not the code."

05Step-by-Step Workflow: Friction to Tool

  1. Catch the friction: what do you rebuild, retype, recalculate weekly? Write the honest frequency down.
  2. Interview: the model asks you 6 questions, one at a time.
  3. Spec it (template): user, problem + frequency, inputs ≤6, outputs, UI in words, NOT-list, acceptance checks.
  4. Build prompt: spec + "single self-contained HTML file, no frameworks, no build step, no network calls, mobile-friendly."
  5. Save as .html, open in browser, run your acceptance checks.
  6. One change request in client voice.
  7. Inspect — the three questions.
  8. Honest ledger: spec time / build time / savings per week. If saved < cost, killing the tool is also success.

06Prompt Recipes

The spec interviewHelp me write a build spec for a tiny tool. Interview me: ask one question at a time, max 6 questions. The tool solves this friction: [describe the recurring annoyance + how often it bites]. When you have enough, output a spec with exactly these sections: user, problem, inputs (max 6 fields), outputs, UI layout in words (with exact button labels and empty-state text), what it does NOT do, acceptance checks (3–5 testable sentences).
The build promptBuild this as a single self-contained HTML file, no frameworks, no build step, no network calls, mobile-friendly, pleasant typography. [PASTE SPEC]. When done, tell me how to save and open it, and list 3 things you'd improve with more time.
The change request (client voice)Change request on the tool you built: [describe the outcome you want, not the code — e.g., "when I press Copy, the button should visibly confirm, and the prompt should include today's date at the end"]. Keep everything else exactly as it is.
The bug report (client voice)Bug report: when I [exact steps], the tool [what actually happens] instead of [what should happen]. Fix it and tell me in one sentence what was wrong.
The inspectionWalk me through this file like I'm an artist, not a programmer: what are the three main parts, where does my data go when I type it, and does anything leave my computer? Point to the exact part of the file that proves your answer to the last question.
The p5 tutorHere is a p5.js sketch: [paste]. Explain it line by line for a visual artist meeting code for the first time. Then suggest 3 one-line changes I could make, each with what it will do visually. I'll make them myself.

07Lab: Tiny Tool Pitch (70 min)

Cold start friendly. Friction-starved? Standing options: export checklist for your main platform · commission price calculator · crit-notes formatter.

  1. Friction hunt (10 min): three recurring annoyances; pick the one with the most honest frequency. Write the number down. The boring candidate beats the impressive one.
  2. Interview + spec (25 min): run the interview; fill the template completely — NOT-list and acceptance checks are where specs earn trust. ✏️ the decisions only you could make.
  3. Build (20 min, bonus round): build prompt → save .html → open → run your acceptance checks. No build? Spec + build prompt is the full deliverable.
  4. Inspect + one change request (15 min): the three questions; one client-voice revision.
Zero-AI track (fully equal)

Template filled by hand + hand-drawn UI sketch; the "build prompt" becomes a brief you could hand any developer. Arguably the purer version of the skill.

Pitch format

60 seconds: the friction (with frequency) → the tool → one acceptance check → the honest ledger. And every pitch answers: "Where does the data go?"

08Integrity Check

This week's four
  1. Could you explain to a classmate, without hand-waving, what your tool does with their input?
  2. Did the tool pass your checks — or did you adjust your standards to what it built?
  3. Does anything in your spec smell like accounts/payments/others' data? Redraw the fence now.
  4. Shipping it anywhere public: "Built with AI assistance from my spec; inspected and tested by me."

09Troubleshooting

ProblemFix
"I don't have friction worth a tool"You do. What did you retype, re-look-up, or recalculate this week? The boring-est candidate is the best one
The interview asks dull questions"Ask harder questions — edge cases, misuse, what I'd never want it to do"
The tool ignores part of the specQuote the spec line in a change request: "The spec says X; the tool does Y. Fix to spec."
It looks uglyTaste is a change request: "more whitespace, bigger type, calmer colours." You're the art director here too
File won't open / blank pageCheck it saved as .html (not .txt — TextEdit trap), then: bug report with exact steps
"This feels too easy to be real"Run your acceptance checks. If it passes, it's real. Spend the unease on a better spec

10Resources

Optional extension

Next week: Agentic Workflows → — when the AI doesn't just write the file, but organizes the whole folder. With checkpoints.