zainTeaching a Design Team to Build with AI
Porter's designers were AI-curious but not AI-capable. I designed and now run a director-approved weekly program to turn the whole team into builders who can read, modify, and ship real code, taught hands-on, gated on what people can actually do rather than what got covered.
- role
- Initiative lead: curriculum design + weekly facilitation, end-to-end
- stack
- L&D · AI enablement · Facilitation · Design leadership
- status
- in progress
How I got here
A year before this program, I ran a full-day AI "playground" for the design team, an all-day workshop to get people past the friction of touching these tools. The arc in the room went from fear to a bit of awe. But a one-day spark fades, and I knew it.
The stronger signal came later: the team built CopyCat, a Figma plugin, in two days with zero development background, and won a company AI hackathon with it. That was the proof I needed that designers can build. But it was one team, one burst of adrenaline. The gap was never inspiration. It was a repeatable path from "I use AI to chat" to "I ship a working tool." So I proposed making that path a standing program, and a director signed off on running it org-wide.
How I thought about it
The north star I set was deliberately concrete: every designer able to read, modify, write, and merge code, and eventually ship real internal tools. Not "prompt better." Actual building.
The trap I kept catching myself in was teaching topics. So I gated every phase on a capability, a thing everyone can do by the end, instead of a syllabus covered. Three phases: remove the fear, build a real product, then own and ship something. And one track, one pace: a small team that splits into "product" versus "visual" fragments itself, so everyone gets to "can ship a working tool" first and specializes on their own after.
The hardest design problem was translation. These are designers, not engineers, so the whole curriculum runs on analogies to their world: an app is just a folder of text files; the code editor is "Figma for developers"; a context window is a token budget; saving to a file is Ctrl+S; Git is Figma's version history; a pull request is a design review. And I taught each concept off one vivid pain instead of a feature tour. "Add beverages to ten assistants and you're making fifty manual edits" is why file-based, shared-context tooling exists. Let the room feel the problem first, then hand them the fix.
What I actually did
Weekly ~1.5-hour sessions, shared screen, live builds, homework between, a Slack recap after each. Six delivered so far.
Session one mapped the landscape: five levels of working with AI (chat → augmented → sandbox → files and terminal → agents), what "probabilistic" actually means (same question, different answers, shown live), and the core vocabulary, walked through Unjargon, a jargon-explainer I'd built for exactly this.
Sessions two and three crossed the scary line, from Custom Gems into the terminal. We built two throwaway assistants live, hit the duplication pain on purpose, and rebuilt them as file-based skills. Then into Claude Code, where files persist and context survives closing the terminal, with a real skill I'd published (mobile-screen-eval, shipped to npm and GitHub) as the payoff.
Then I set homework that mattered: build a skill that solves your own repetitive problem. The next session was show-and-tell, and it landed. Designers demoed real tools they'd built: a design-review agent that checks screens against personas and UX laws, a brand-photography generator, a design-system token mapper. That was the moment watchers turned into builders.
The last two sessions were the unglamorous foundation: everyone stood up a real dev environment (I routed around the IT-admin wall so nobody waited on provisioning) and learned Git by hand: commit, push, branch, pull request.
Where it landed
Honest, because it's live, not finished.
Six sessions in, the team has moved from AI-curious to genuinely hands-on: working dev environments, code pushed to GitHub, and several designers now building and using their own tools day to day. This time the spark stuck, because it's a path rather than an event.
What broke taught me the most. Sessions started feeling like disconnected chapters. One person's feedback was "we raised a pull request and nobody knew why." So I'm redesigning the build phase around a single shared product, with concepts taught just-in-time, so the "why" is never abstract. Leadership backed continuing it, and the next phase hands designers ownership of real work to ship.
Two things I'd underline, and they're scars, not slogans: comprehension isn't capability, because reps and a working environment are the real gate, and the fastest way to lose a mixed-fluency room is to cram.