The Design–Code Gap

This is the framing module for the whole course, so resist the urge to open a terminal here. The job is to make the gap concrete: every designer in the room has watched a carefully specified screen come back from implementation slightly wrong, and most have stopped noticing because the loss is normal. Naming where and why it happens is what makes the rest of the course feel necessary rather than novel.

Be explicit about scope. This module does not install anything, does not require a paid plan, and does not assume any terminal experience. Module 2 handles setup, and it deliberately offers paths that avoid the terminal entirely. The only prerequisite for today is having shipped design work through a handoff at least once.

It also helps to defuse the obvious anxiety early: this is not a course about turning designers into engineers. The closing slides return to that, but say it in the first minute too — the skill being taught is directing and reviewing work in the product's real materials, not writing that work by hand.

Walk the chain slowly: design file, handoff package, rebuilt implementation. At each step a human translates one representation into another, and translation is where loss happens. The design file knows things the exported spec does not — why the spacing is what it is, what happens when the list is empty, which states the designer considered and rejected. The spec captures whatever the designer remembered to annotate. The implementation captures whatever the engineer inferred from the spec, filled in with sensible defaults wherever it was silent.

Industry practitioners have described handoff as a tense phase precisely because the two sides speak different languages and work within different constraints — the designer thinks in frames and pixels, the engineer in components, props, and breakpoints. That observation comes from handoff-tooling vendors with a product to sell, so treat the framing as directional rather than data, but it matches what most teams experience.

The useful reframe for this audience: the leak is structural, not a competence problem. No amount of better annotation fully closes it, because annotation is itself another translation layer. That sets up the next two slides — what the leak costs, and why a decade of tooling aimed at better handoff did not remove it.

Walk the top path first and point at the leak markers. Between intent and handoff, spacing and type decisions flatten into whatever the export format carries. Between handoff and the rebuild, states and edge cases drop, because the spec only covers what was annotated. Inside the rebuild, the gaps get filled at the keyboard — the empty state nobody specified gets invented by whoever is closest to the deadline. The shipped product is close to the mockup, not equal to it, and the difference compounds with every release because nobody owns it.

Then walk the bottom path and stress what changes and what does not. The designer still starts the work — the brief and the mockup are designer-led, marked blue. The agent does the production in the product's real components and tokens, marked yellow. The designer holds the review gate: diffs, side-by-side screenshots, parity against the mockup. Shipping is still a human decision. What disappears is the pair of hand translations in the middle, which is where the loss lived.

Be careful not to oversell the bottom path here. The agent's first pass has its own failure modes — the worked example later in this module shows several — but those failures are visible and correctable in review, rather than discovered in production three sprints later.

Make each cost concrete with an example the room will recognise. Rework is the QA-style review pass where the designer files a dozen tickets that all amount to please match the mockup — work that produces nothing new, only recovers what was already decided. Drift is the slower one: each rebuilt screen lands a few pixels and one token away from the system, and after a year the audit finds dozens of near-identical greys and spacing values nobody chose deliberately. Practitioners maintaining design systems describe exactly this pattern of mockup-to-code divergence; it is why visual QA exists as a job.

Dropped states are the cost users actually feel. The happy path gets designed and built; the empty state, the error state, the long-name overflow case get invented during implementation if they were not specified, and they are the screens users meet on their worst day with the product.

The fourth bullet is the cultural cost and worth dwelling on: once the live product diverges from the design file, engineers reasonably start treating production as the source of truth, and the design file quietly becomes a suggestion. At that point the designer's leverage over the product has eroded without anyone deciding it should.

The point of this slide is not to mock the handoff-tool category — many of these tools are genuinely useful, and the sheer size of the category is itself evidence of how real the pain is. Zeplin, Avocode, Sympli, and the inspect modes built into the major design tools all exist because teams keep paying to soften the same wall. The structural critique is narrower: each of them makes the translation step better documented or partially automated, but the translation step remains.

Code export deserves the most attention because it sounds like it should be the answer. The generated code is typically built from absolute positions and generic markup; it does not know your component library, your tokens, your naming conventions, or your accessibility patterns, so engineering teams treat it as a starting sketch at best and rewrite it. The output is code, but it is not your product's code.

This is the setup for the next slide: the missing ingredient is not a smarter exporter, it is something that can read the product's actual materials — the real components, the real tokens, the real files — and work within them. That is what a coding agent is.

This slide turns the structural argument into the course's thesis. The product is, concretely, a folder of files: component code, token definitions, stylesheets, copy strings. Everything that previously made that folder off-limits to designers — unfamiliar syntax, fear of breaking things, no time to learn the stack — is exactly what a coding agent absorbs. The agent reads the folder, finds the existing components and tokens, and makes changes within them, while the designer supplies what the agent cannot: the intent, the references, and the judgement about whether the result is right.

The reviewability point matters as much as the capability point. Because the agent's output is a change to text files, it produces a diff — a precise record of what changed — plus screenshots you can put next to the mockup. That is a far stronger review position than the old one, where the designer's only instrument was eyeballing a staging build and filing tickets.

Pre-empt the objection that this is just the export plugin again with better marketing. The difference is the direction of work: an exporter pushes a foreign artifact into the codebase from outside; an agent starts inside the codebase and works with what is already there. That distinction — working in the product's real materials — is the reason this approach can close a gap the exporters could not.

Anchor the definition in Anthropic's own framing: Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with development tools. The contrast with a chat assistant is the operative point for designers. A chatbot produces text or code in a window, and you carry it somewhere else by hand — which is just another translation step. Claude Code operates inside the project folder you point it at: that folder is its world, and its output is changes to the actual files.

Walk the four verbs. Reads includes images — you can paste a screenshot or a mockup and ask for an implementation that matches it, which is documented in Anthropic's own workflow guidance and is the core move of Module 3. Plans matters because every Claude Code surface has a plan mode where the agent proposes its approach while still read-only; for a nervous first-time user this is the safety rail. Acts is governed by permission modes — from ask-before-every-action through to more autonomous modes — covered properly in Module 2. Verifies is the underused one: the agent can take a screenshot of what it built and compare it against the design before the designer ever looks.

Two practical notes worth stating now and date-stamping: as of mid-2026 Claude Code is available across several surfaces — terminal, VS Code and JetBrains, a desktop app, the web, and mobile — and it requires a paid Claude plan or API access. Module 2 covers both in detail; the specifics move quickly, so the course points at the official docs rather than baking in numbers.

This comparison exists because the three categories blur together in conversation — they are all AI, and most designers have touched at least the first two. The distinguishing question is the last row: where does the output land, and who carries it the rest of the way? A chat assistant's answer lands in a chat window; even when the answer is correct code, moving it into the product is still a manual translation done by someone. A design-tool plugin's output lands on the canvas or as exported code that ignores the product's existing components, so it gets rebuilt — the same fate as the exporters on the earlier slide.

Claude Code's output lands in the codebase as a change to the files the product is actually built from, which is why it can close the gap — but only when paired with review. Be careful with the yes in the last cell: unreviewed agent output is plausible-looking work with the same dropped-state and drift risks as a rushed human rebuild. The course's claim is agent plus designer review, never agent alone.

If someone asks where tools like in-canvas AI generation or prompt-to-app builders sit: closer to the plugin column for the canvas tools, closer to Claude Code for the code-native ones, and the same question applies to all of them — does the output respect the product's existing materials, and can you review it as a change rather than a replacement?

This slide is the course map disguised as a use-case list, so connect each bullet to the module that teaches it. Mockup-to-code is the foundational move and the most direct attack on the gap: give the agent the artifact you already have — a screenshot, a frame, a reference — and get back an implementation in the product's components, then run a parity check. Prototyping extends that to flows: real components, realistic data shapes, the states that matter, honest about what is prototype-quality and what is not.

Design-system work is where the leverage compounds, because the system is upstream of every screen: building a component inside the system's rules, generating its documentation in the same run, and running audits that find token violations and drift with evidence rather than vibes. Automation is the long tail — the audits, asset exports, and documentation chores that every team agrees matter and no team staffs — turned into runs that can repeat.

It is worth saying that none of these use cases is hypothetical for this school: the worked example on the next slide is a traced run from the school's own published field note, and later modules trace runs against real projects in the same way. The course's standing rule is real projects over sandboxes.

This run comes from the school's published field note on the first-session prototype, executed for real in a scratch folder on 1 June 2026 — say that, because the honesty is the point. The brief was deliberately constrained: a single self-contained hero.html for a fictional product, inline CSS, no frameworks, so the output either renders when double-clicked or it does not, and the session stays about design judgement rather than tooling.

Spend the time on the first-pass failures, because they are the agent's defaults made visible: a fixed 56-pixel heading that wrapped badly on small screens, thin section padding, marginal contrast on the supporting line, a barely-there hover state, no keyboard focus state, no landmark element. None of these are exotic; they are exactly what a competent but uninvested contractor would ship, and none are visible unless you open the file and resize the window. The correction round was one message naming each problem specifically, in the same register as the brief, and the second pass addressed all of it.

The two takeaways to land: first, the leak points from earlier in the module — dropped states, invented details — do not vanish with an agent; they move to a place where the designer can catch them in minutes instead of discovering them in production. Second, the review is not overhead on top of the design work. It is the design work. Expect real projects to take two or three correction rounds, not zero.

Each bullet answers a fear that genuinely keeps designers away, so take them seriously rather than briskly. The engineer fear is the biggest: the literacy this course builds is reading — being able to look at a diff, a component, or a token file and form an opinion — not writing syntax from memory. Claude Code is honestly a developer-built tool with developer-oriented documentation and no designer onboarding path; that is precisely the gap this course fills, and it is also why the course does not pretend the learning curve is zero. There are real concepts to absorb: files and folders, what a project is, what a diff is, roughly what a token and a component are.

The terminal fear gets a concrete answer in Module 2: the desktop app and the editor extensions are legitimate first surfaces, and the loop — describe, review, refine — is identical everywhere. The prompt-wizard fear gets answered by the worked example just shown: the brief was plain design language, and the correction round was a designer naming problems precisely, which is a skill the room already has.

The last two bullets carry the cultural weight. Agent output is a draft; shipping remains a decision made with the team, inside whatever review process already exists — this approach works with engineering partners, not around them. And the value shift runs towards the designer: when execution gets cheaper, the clarity of intent and the quality of judgement are what differentiate the work.

The exercise is deliberately analogue and slightly uncomfortable: it asks people to document losses they have learned to shrug off. That discomfort is useful. Most participants find that the differences cluster exactly where this module said they would — states that were never specified, spacing that drifted in the rebuild, details that the handoff format simply could not carry — and that more of them were found in production than anyone is proud of.

The third bullet matters most for what comes later: distinguishing leaks caused by a silence in the spec from leaks caused by the translation itself. Spec silences are the designer's to fix, and they remain the designer's to fix on the agent path too — an agent fills unspecified decisions with defaults just as an engineer under deadline does. Translation leaks are the ones the agent path removes.

The circled task feeds forward twice: it becomes the participant's own conversion exercise at the end of Module 3, and it is also the most persuasive artifact they can show a sceptical lead or engineering partner — not a claim about AI, just a documented record of what the current path loses. Keep the scope honest when they choose: a section or a component, not an entire product area.

Recap by reconnecting the bullets rather than repeating them: the gap is structural, which is why a decade of handoff tooling softened it without closing it; the agent closes it because it works in the product's own materials; and the designer's leverage on the new path is the brief and the review, which the worked example showed are design skills, not engineering ones. If the room did the exercise, the page they produced is the local proof of the first three bullets.

Preview Module 2 concretely so the next step feels small. It covers the three ways in — the desktop app, the VS Code extension, and the CLI — and which suits which working style; what each permission mode actually allows, and why starting in the most conservative mode that works is the right call for the first week; plan mode as the safe default; a first session that is purely read-only exploration of a real project; and plans and pricing without the sales pitch, date-stamped because those numbers move.

Set one expectation for homework if the format allows: arrive at Module 2 knowing which real project you would point the agent at first — ideally something connected to the task circled in the exercise — and check your organisation's policy on what can be shared with an AI tool before then, so the first session starts on safe ground.