The Agentic Design Paradigm

This is the orientation module for the whole course, so resist the urge to demonstrate tools here. The goal is shared vocabulary: what we mean by agent, loop, harness, and gate, so that when later modules say put that rule in the harness or hold the artifact at the review gate, nobody is guessing.

Set expectations about what the module is not. It is not a Claude Code tutorial, it is not a survey of every AI design tool released this quarter, and it is not a claim that agents replace designers. It is a working model of how design work changes when an agent can read your project, plan, make changes, and check its own output.

If the audience is mixed — some people already running agents daily, others who have only used chat assistants — say so out loud. The early slides will feel basic to the first group and necessary to the second. Both groups tend to share the same misconceptions covered later in the module, so the level evens out quickly.

The framing to land here is convergence. Designers have heard AI will change design every year for a decade, and most of it amounted to better autocomplete or image generation. The reason this wave is different is structural: the agent can operate on the same files, components, and tokens your product is actually built from.

Walk the three changes in order. First, coding agents stopped being single-turn code generators and became systems that read a repository, propose a plan, make changes across files, and run the checks. Second, the Model Context Protocol gave those agents a standard connector into the tools designers care about — canvases, design files, browsers, ticketing systems — instead of bespoke one-off plugins. Third, design-as-code formats mean the artifact itself is text the agent can read and modify, and a reviewer can diff.

The fourth bullet is the quiet one but it matters most for adoption inside teams: plan modes and permission systems mean the agent's work is inspectable before and after it runs. That is what turns this from a demo into something a design team can actually govern.

This comparison is deliberately about loops, not tools. The point is not Figma bad, terminal good. Plenty of agentic work still ends up on a canvas, and plenty of canvas work feeds agents. What changes is where the designer's effort and leverage sit.

In the tool-centric loop, the scarce resource is production time: every screen, state, and variant is drawn by hand, and the output is a picture that someone else rebuilds in code, losing detail along the way. In the intent-centric loop, the scarce resource is clarity: the quality of the brief, the constraints in the harness, and the sharpness of your critique determine the quality of the output far more than your speed with a pen tool does.

Be honest about the iteration-cost row. Minutes per round is real, but only when the brief and harness exist. Without them, the agent iterates quickly towards something generic, and you spend the saved time correcting it. That caveat is the bridge to Modules 3 and 4.

Definitions of agent vary wildly across the industry, so anchor on an operational one: reads, plans, acts, verifies. A chat assistant answers questions and produces text or images you then carry somewhere else by hand. An agent operates inside your project: it can open the actual component file, see the actual token names, change them, and run the actual checks.

Each verb earns a comment. Reads is why context matters so much — the agent's output quality tracks what it can see. Plans is the cheapest review point you will ever get; every major platform now has a read-only planning mode. Acts is why permissions and scope matter; an agent that can edit anything will eventually edit the wrong thing. Verifies is the most underused one — agents can run type checks, audits, and screenshot comparisons on their own output before you ever look at it.

The closing line on the slide is the cultural point: once a system can act on your project, you need a working agreement with it — which is exactly what the harness, briefs, and review gates in later modules provide.

The purpose of this slide is to remove the which tool should I learn first blocker, not to crown a winner. All four platforms read an instruction file from the project, all four have a plan-before-build mode, and all four can connect to design tools over MCP. The course's techniques are written to be portable across them.

Give the honest one-line differences. Claude Code has the deepest ecosystem of skills and design-adjacent MCP servers and is what most of the worked examples in this course use. Codex CLI fits teams already living in GitHub pull requests. OpenCode is the open-source, model-agnostic option for teams that want control over which model runs. Gemini CLI is the lowest-cost way to start experimenting.

Flag that the details in this table — entry points, file names, pricing — change quickly. The course's article on choosing your agent platform is kept current and is the reference to check before committing a team. The decision that matters in this module is simply to pick one and run the loop, because the loop is what transfers.

This slide compresses a topic that gets a full module later, so keep it to the one property that matters: diffability. When the design artifact is text — component code, a .pen or .op canvas file, a token file, an SVG — an agent can read it, modify it precisely, and produce a change you can review line by line. When the artifact is an opaque binary, the agent can at best look at exported pictures of it, and your review collapses to comparing screenshots and hoping.

Pre-empt the worry that this means designers must abandon visual tools. Connected canvases — Paper, Pencil, OpenPencil, and similar — exist precisely to give designers a visual editing surface whose underlying file is still readable text. Module 5 covers that landscape properly.

The practical takeaway for now: when you choose where a design lives, you are also choosing whether an agent can help with it, and whether its help can be reviewed honestly.

Walk the diagram left to right and call out who owns each step. The brief is human: intent, constraints, references, and review criteria. The plan is agent-run but read-only — the agent proposes structure, components, states, and risks. The review gate is human and is the cheapest correction point in the loop, because nothing has been built yet. Generate is the agent doing production. Critique is shared: executable checks the agent can run on itself, plus the human judgment about hierarchy, tone, and fit. Revise is agent-run, steered by that critique. Ship is a human decision, full stop.

Point at the dashed feedback line. Feedback that keeps recurring is a signal that something belongs in the harness rather than in the conversation — that idea gets a full module later, but plant it here.

The most common failure pattern with new agent users is collapsing the loop to brief, generate, ship — skipping the plan review and the critique. The output looks fast and reads as plausible, and the problems surface in front of stakeholders. The gates are the design work.

This slide carries the cultural weight of the module, so do not rush it. The honest claim is narrow: agents are very good at execution within stated constraints, and they are getting better at flagging issues. They are not good at knowing what the product should be, what this team can ship, what the brand should refuse to do, or which of five competent layouts is right for this audience.

Taste deserves a concrete framing: an agent will happily produce something polished and generic, because polished and generic is the centre of its training distribution. The designer's taste is what pulls the work away from that centre towards something specific. Intent is upstream of every prompt — deciding what the screen is for and, just as importantly, what to leave out. Judgment covers all the context that never appears in the repository: stakeholder history, regulatory nuance, what failed last time. Accountability is the simplest one: when the work ships, a person answers for it.

If anyone in the room hears this as reassurance that nothing changes, correct that too. The execution skills designers have charged for are getting cheaper. The judgment skills are getting more valuable. That is a real shift in what the job rewards.

Use the quote to name the gap explicitly, because most working designers feel it daily even if they have never phrased it. Designers think visually and systemically — hierarchy, rhythm, states, flows — but the product is made of syntax: components, tokens, markup, configuration. Historically the gap was crossed by handoff, and handoff is where intent leaks: spacing drifts, states get dropped, the empty state nobody specified gets invented by whoever is closest to the deadline.

The agent is the bridge in the specific sense that the designer can stay in design language — the brief, the critique, the references — while the agent does the syntax execution in the product's real materials. The designer is not pretending to be an engineer; they are directing execution they can now reach.

It is worth saying that bridge does not mean designers stop learning anything technical. Reading a diff, understanding what a token is, knowing roughly what a component boundary means — that literacy is what makes the critique sharp. The bridge removes the typing, not the understanding.

Take these one at a time, because each maps to a real failure mode you will see in teams. Just better prompting leads people to collect prompt libraries while skipping the harness and the gates — and then conclude the approach does not work when results stay inconsistent. Agents replace designers produces either panic or dismissal, and both stop people from learning the actual skill shift. The output is production-ready is the most expensive one: agent first drafts are plausible, and plausible is exactly what makes unreviewed work dangerous.

It only matters if you can code keeps designers who would benefit most on the sidelines. The literacy that matters is reading: being able to look at a diff, a component, or a token file and form an opinion. Writing the syntax is the part the agent does.

The demo misconception is the team-level one. A single strong demo proves the ceiling, not the floor. Repeatable quality comes from the boring infrastructure — shared harness files, agreed review gates, and critique habits — which is what the rest of this course builds.

This example is drawn from the school's published article on briefing, and the numbers are from that traced run, not a benchmark — say so. The task was deliberately small: one new strip on an existing page of this site, with the throwaway output kept in a scratch folder.

Walk the left column first. The one-line request is the kind everyone types when busy. The agent filled the missing context with the most common pattern on the public web: a marketing-style how it works band with a gradient and an invented call-to-action, which then failed the project's own token audit with ten hardcoded colours. Three rounds of correction later it was acceptable — and every round was just re-supplying context the request never carried.

The right column is the same task with a seven-line brief and the agent in plan mode. The plan restated the user job, named the existing components it would reuse, and flagged a real contradiction in the brief before any code existed. One fix round after generation — the implementation invented a component prop that the type check caught. That last detail matters: the brief and the plan do not guarantee the artifact. The gates still earn their keep.

The exercise is deliberately analogue: no agent, no terminal, just a page. The point is to surface how much of the loop is design thinking the participant already does — and where the gaps are. Most people discover that the hard lines to write are the user job and the review criteria, which is precisely the design work the one-line prompt skips.

Steer people towards a task that is real but bounded: a section, a component, an audit of one flow — not redesign our app. The fourth bullet, what the agent would need to read, is the harness in embryo; when participants list the design system, the existing components, and our naming rules, they are describing Module 4 before it has been taught.

Collect or discuss the could go wrong answers if running this live. They split neatly into things a plan review would catch, things only critique or a check would catch, and things no gate catches because they are judgment calls — which loops the conversation straight back to the what stays human slide.

Recap by walking the five bullets, but spend the time on the connective tissue: the convergence explains why the loop is possible, the definition of an agent explains why gates are necessary, and the what stays human slide explains why the gates are design work rather than overhead.

Preview Module 2 concretely. It takes the loop from this module and slows it down: what a good brief looks like versus a request, what to actually check at the plan review gate, how to give critique an agent can act on, and the places the loop most often breaks in practice — vague briefs, skipped gates, and feedback that never makes it back into the harness.

If participants did the exercise, ask them to keep the page somewhere they will find again. The course returns to it twice: once when running the task in Module 3, and once in Module 6 when building a personal ship checklist.