Canvas-to-Production Pipelines

This module takes the orchestration patterns from earlier in the course and applies them to the workflow most teams care about most: getting an approved design into production code without the intent leaking on the way. The framing to establish up front is that the pipeline replaces the handoff. In the old model, a designer finished a picture of the product and a developer rebuilt it, and the gap between those two artifacts is where spacing drifted, states got dropped, and the empty state nobody specified got invented under deadline pressure. In the pipeline model, the design artifact feeds an agent that builds in the product's real materials, and a sequence of gates verifies the result against the artifact and the intent.

Be clear about what this module assumes. It assumes the promotion decision has already been made — that this design should become production code at all — and it assumes a harness exists: a design-system file, semantic tokens, and at least one executable audit. Module 3 covered the MCP chains that connect canvas to code; this module covers the stages and gates those chains run through.

Also set the honest tone early. The export step has become genuinely good by mid-2026, and it is still the smallest part of the work. Most of the session time in the worked example later in this module went into gates, rebuilding on real primitives, and review — not generation. If participants leave with one habit, it should be accounting for that time honestly.

Walk the six stages and emphasise the ownership split rather than the stage names, because the names vary by team and the split does not. The human owns the two ends: the artifact and intent going in, and the judgment at review plus the merge decision coming out. The agent owns the mechanical middle: resolving tokens and components, generating the implementation, producing breakpoint variants, and running every check that has a command line.

Stage one deserves the most attention because it is the cheapest place to buy quality. An artifact that carries structure — layout built with auto-layout or flex, real component references, token names rather than raw values, realistic content — gives the generator something to be faithful to. A flat picture gives it something to imitate, and imitation is where the plausible-but-wrong output comes from. Every credible teardown of design-to-code tooling this year converges on the same finding: artifact structure and component mapping decide more of the output quality than the choice of generator.

Note what is deliberately absent from the stages: there is no stage called handoff. The artifact does not get reinterpreted by a person; it gets read by an agent and verified by gates. That is the structural change, and it is also why the gates matter more here than in a single-agent workflow — nobody is manually rebuilding the design, so nobody is manually noticing what the rebuild missed.

Walk the diagram in order and name the owner of each card. The approved canvas is human: it carries the structure, the component references, and the written behaviour. Token and component resolution is agent-run, and it is a real step — the agent maps canvas values to the project's semantic tokens and frames to the real component library, and flags anything it cannot map rather than inventing a substitute. Code generation happens on a branch, outside production paths, against the harness. The checks-and-visual-QA card is the automated gate: type check, token audit, accessibility scan, and breakpoint screenshots compared against the canvas. The PR review gate is human-led and uses the same P0–P3 severity vocabulary as the critique module earlier in the curriculum. The merge is a person's decision.

Spend time on the dashed return line, because it is the difference between a pipeline and a conveyor belt. Work that fails a gate does not continue with a comment attached; it returns to the agent, gets fixed or regenerated, and re-enters at the gate it failed — and everything earlier gets re-run, because a fix can introduce a new defect upstream of the gate that caught the old one.

The last bullet on the production card previews the measurement discipline later in the module: the defect log is kept by stage, so that recurring defects tighten the stage responsible for them instead of becoming permanent review burden at the end.

This table is the working definition of the module. A gate is not a vibe check and not a dashboard; it is a check with a tool that runs it, an owner who acts on the result, and a named defect class it exists to catch. Naming the defect class in advance is what keeps gates honest — when nobody can say what a gate is for, it drifts into ritual, and ritual gates are how P1 defects get waved through alongside the noise.

Point out the owner column. The first two gates are fully agent-owned: the agent runs the type check and the token audit, and it fixes what they find without waiting to be asked. The responsive gate splits the work: the agent captures the evidence — screenshots at the agreed widths — and a human judges whether task order survived, not just whether things stacked without overflowing. The accessibility gate is shared because the automated scan is necessary and not sufficient: practitioner analyses consistently estimate that automated tools catch on the order of a third of real WCAG issues, so the gate has to be scan plus heuristics. The final review gate is human, full stop.

The highlight line is the cultural test to give teams: if the audit fails and the work merges anyway, or the scan is green and nobody does the heuristic pass, the pipeline exists on paper only. The fix is rarely more tooling — it is deciding, in advance, that a failed gate stops the work.

This slide covers the stage most teams skip and then pay for at review. The canvas and the codebase each have an opinion about what the design system is, and unless something actively reconciles them, the agent will resolve the disagreement silently — usually by hardcoding whatever value the canvas happens to show. That is how a pipeline produces code that compiles, looks right, and contains eleven hex colours standing in for semantic tokens, which is exactly what the worked example later in this module found on its first iteration.

The mechanics differ by stack but the principle is constant. With Figma's Dev Mode MCP server, the mapping investment is Code Connect: when components are mapped, the exported code imports the team's actual components with their real props instead of lookalike markup, and independent reviews consistently identify that mapping work — not the generator — as the difference between code you keep and code you rewrite. With connected canvases the mapping is closer to free: Pencil's .pen variables map to CSS custom properties, and Paper's HTML-native canvas means export is serialisation rather than translation. Either way, the pipeline should treat resolution as an explicit step with an output a human can read: which values mapped, which did not, and what the agent proposes to do about the gaps.

The last bullet is the operational point for teams running this at scale: sync decays. Tokens get renamed, components get deprecated, and a mapping that was complete in March is partial by June. Re-running resolution when the system changes is much cheaper than rediscovering the drift one review at a time.

Parity checks answer one question with evidence: does the built page match what was approved, at the sizes the design committed to? The mechanism is straightforward — the agent drives a browser, captures screenshots at the agreed widths, and pairs each one with the corresponding canvas frame so the reviewer is comparing like with like. What keeps this from becoming busywork is being clear about what kind of match you are checking. Pixel-for-pixel sameness is the wrong target: fonts render differently, content is real rather than placeholder, and some divergence is deliberate. The reviewer is checking intent — is the hierarchy the same, did the task order survive on the small width, do the states the canvas showed actually exist in the build.

It helps to know what to expect from the export step, because the fidelity gaps are well documented. Independent hands-on tests of the strongest export paths in 2026 still report drifted colours and border radii, the wrong number of repeated elements, placeholder data wiring, and interactions left unfinished. None of these are reasons to abandon the pipeline; all of them are reasons the parity gate exists. The agent can also do a useful first pass on the comparison itself — flagging obvious geometric and colour differences — but the severity call stays human, because only a human knows which deviation is a defect and which is a sensible adaptation to real content.

Findings from this gate use the same P0–P3 vocabulary as the rest of the curriculum, with evidence attached: the screenshot, the frame, and one sentence on why it matters. That keeps the return trip to the agent cheap and unambiguous.

This slide is the evidence base for the gate sequence, and it is worth giving the numbers with their caveats. On accessibility, a practitioner benchmark published in 2025 and updated since had frontier models generate UI components with no accessibility instructions in the prompt and ran automated checks against the output: the average pass rate was roughly 12%. The same benchmark found that loading accessibility instructions or skills changed the result substantially — which is an argument for the harness as much as for the gate. Treat it as a practitioner benchmark rather than a peer-reviewed study, but the direction matches what accessibility teams report.

The second documented problem is that the automated checks themselves only see part of the standard: Deque's analyses and independent practitioner write-ups estimate automated tools such as axe-core catch on the order of 30–40% of real WCAG issues. Heading logic, focus order coherence, link text in context, and keyboard usability mostly are not in that set, which is why the accessibility gate is scan plus heuristics, never scan alone.

There is also a cost that never shows up in the generated files: review. A 2025 randomized study by METR found experienced open-source developers were a net 19% slower with AI assistance on their own mature codebases, largely because reviewing plausible-but-incorrect output ate the time generation saved. That population is not designers running this pipeline, so do not quote it as a design-to-code statistic — but the mechanism it documents, confident output that costs more to verify than to admire, is exactly the failure mode this pipeline is built to manage. The last bullet, product rules invented from a static frame, is the one no gate fully catches; it is prevented by writing behaviour down in the brief rather than letting the agent infer it.

This defect log comes from a documented run in the school's own repository on 2026-06-01: a small lab-sessions section built through the pipeline, with the type check and the design-system audit executed for real and the responsive and accessibility findings coming from a checklist-driven manual review of the markup. It is one section and one session of work, so do not present it as a statistic — present it as a shape, because the shape matches the larger published picture. The automated gates caught the cheap, mechanical defects fast: the type error that would have thrown at runtime, and the eleven hardcoded colours. Everything else needed a heuristic checklist or a human looking at the result with the original intent in mind.

Two rows carry the lesson. The hardcoded-colour row is the one a decent harness largely prevents — the same audit run on the site's real component directories passes, because the harness teaches the agent to use semantic tokens in the first place. So a recurring defect at that gate is a signal to tighten the harness, not to review harder. The div-title row is the opposite case: a defect introduced by doing the right thing — reusing the site's card primitive, whose title slot renders as a div — invisible to the type checker, the token audit, and most automated accessibility scans, and meaningful to exactly the users least likely to be in the room when the demo happens. A pipeline that stopped at "both commands exited zero" would have shipped it.

The measurement discipline this slide introduces is the one to take back to a team: keep the defect log by stage. When you know which gate catches which class of defect, and how often, you know which stage to tighten — the harness, the artifact, the mapping, or the review — instead of letting every defect become permanent review burden at the end of the pipeline.

Once a pipeline runs reliably with a human watching every stage, the next question is which stages can run without one. The useful dividing line is the cost and detectability of failure. Token resolution, generation on a branch, the executable checks, and evidence capture all fail cheaply and visibly: a failed audit or a missing screenshot blocks the work and tells you why. Those are safe to run unattended, and CI is their natural home — Lighthouse budgets, accessibility scans, and audits expressed as assertions that fail the build, rather than reports that depend on someone noticing. The stages that must keep a human are the ones whose failures are expensive and silent: a wrong artifact going in, a severity judgment made too generously, an accepted finding that never got written down, and the merge itself.

The condition for unattended stages is evidence. An unattended stage that leaves no artifact behind is just a gap in the pipeline with extra steps. The agent should leave the check output, the captured screenshots, and a short report of anything it flagged or could not resolve, so the human gates downstream are reviewing evidence rather than reconstructing what happened.

Scope is the other half of the eligibility decision, and it connects back to Module 1's cost accounting. Content and marketing surfaces, settings panels, and simple lists are good candidates for the mostly automated path. High-stakes flows — checkout, permissions, anything where the artifact cannot express the product rules — are places where the generated code is the least important part of the work, and where the gates cannot save you from a wrong understanding of the problem. Keep those on the slow path deliberately.

This trace is the same run as the defect log, viewed as a sequence with timings, and the honest accounting is the lesson. Generation was minutes per iteration. The brief took about ten minutes to write. The rebuild on real primitives took roughly twenty. The review passes, the heuristic checklists, and the re-runs consumed the rest of a working session. That ratio — fast generation, slow verification — matches the published evidence about where time actually goes with AI-assisted work, and it is why the time you report for design-to-code work has to include gate and review time, not just the satisfying first generation.

Walk the iterations briefly. Iteration one is what an unharnessed export looks like: self-contained markup, inline colour values, its own card structure. It compiled and looked broadly right, and the gates disagreed — which is the pipeline doing its job. Iteration two rebuilt the same content on the site's own primitives with semantic tokens, and both automated gates passed cleanly. Then human review caught the defect that justifies the whole final gate: card titles that were no longer headings at all because the card primitive renders its title slot as a div. Every automated gate was satisfied; a screen-reader user navigating by headings would have found nothing inside the section. Iteration three fixed it, re-ran the gates, and recorded one accepted finding — the orphan card at 768px — as a P3 rather than silently ignoring it.

If the gates routinely cost more than building the section by hand would have, treat that as a real signal rather than a failure of discipline: sometimes the answer is a better artifact or a tighter harness, and sometimes the answer is that this surface was not a good candidate for the pipeline.

The pipeline only becomes a team capability when it stops living in one person's head. Writing the gate sequence into the repository — as a checklist file the brief points at — does three things at once. It makes the sequence the same regardless of which designer or which agent runs it. It lets the agent run every gate that has a command line without being asked, and report results instead of waiting for someone to remember the audit exists. And it creates the place where accepted findings and after-merge notes accumulate, which is what feeds the measurement discipline from the defect-log slide.

Two usage notes matter in practice. First, the checklist is a contract with the agent: include it in the brief, and instruct the agent to stop and report at the marked decision points — after the automated gates, and before anything merges — rather than fixing and merging in one motion. The stop-and-report behaviour is what keeps the human gates real when the agent is doing most of the running. Second, keep the commands yours: the excerpt on the slide uses this site's tools, and the right version for any team substitutes its own type checker, audit, scan, and budget tooling while keeping the order and the ownership.

Date-stamp the claims the checklist relies on. Export capabilities, scanner coverage, and CI syntax all change quickly in this space; the shape shown here was last verified against the underlying tools in June 2026, and a team adopting it should re-check before relying on the specifics. The structure — entry conditions, agent-run gates, shared gates, human review, after-merge notes — is the durable part.

The exercise is deliberately retrospective: rather than designing an ideal pipeline, participants reconstruct the path one real piece of work actually took. That keeps the answers honest, because the gaps show up as specific events — the audit that was red but merged anyway, the responsive check that was someone resizing a browser once, the accessibility issue found by a user rather than a gate. Steer people towards a recently shipped piece of work that was big enough to involve more than one person but small enough to trace in fifteen minutes.

The fourth bullet is the one that produces the most useful discussion: where were the defects actually found? Defects discovered at the end — in final review, in QA, or in production — are almost always defects that a named earlier gate would have caught more cheaply, and mapping them backwards to the stage that should have owned them is the measurement habit this module is trying to build. The fifth bullet forces a single choice. Most maps reveal several gaps at once, and the instinct is to fix everything; the discipline is to tighten one stage, give its gate an owner and an evidence requirement, and run the next piece of work through it before adding more.

If running this with a team rather than individually, have two people map the same piece of work independently and compare. The differences between the two maps are usually the undocumented steps — and the undocumented steps are exactly the ones an agent-run pipeline cannot inherit, because nobody ever wrote them down.

Recap by connecting the bullets rather than repeating them. The pipeline replaces the handoff, which is why the ownership split matters: the agent runs resolution, generation, and every executable check, and the human owns the artifact going in, the severity calls, and the merge. Gates are what make that split safe — a tool, an owner, and a named defect class, with the rule that failed work returns to the agent rather than moving forward annotated. The sync and parity steps are where most informal pipelines leak, because both get assumed rather than executed. And the worked example showed the honest division of labour: automated checks caught the cheap defects fast, and the defect that mattered most needed a human asking a question no command knows how to ask.

The measurement habit is the bridge out of the module: a defect log kept by stage tells you which stage to tighten — harness, artifact, mapping, or review — and that is an operational practice, not a tooling one.

Which is exactly where Module 6 goes. One pipeline run by one designer is a workflow; several pipelines run by a team of designers and agents is an operation, and operations need cost visibility, permissions, audit trails, onboarding, and review capacity that scales with the volume the agents produce. The final module covers how to run the whole thing as a durable team capability rather than a collection of impressive individual setups.