Prototype First, Production Later

This module sets the operating model for the whole course. Every later module — references and briefs, multi-direction exploration, parity, visual QA, the sprint — assumes the distinction drawn here between work that exists to teach the team something and work that exists to be shipped and maintained. If that distinction is fuzzy, everything downstream gets risky in the same way: convincing artifacts get treated as commitments.

Be explicit about the audience assumption. This is an intermediate course: participants are expected to already run basic agent sessions — a brief, a plan, a generated artifact, a correction round. The course does not re-teach installation or the basic loop. What it adds is the prototyping-specific discipline: scoping, fidelity decisions, disposability, and honest handoff.

Name the tension up front, because everyone in the room has felt it. Agents make prototypes fast and convincing, and convincing is exactly the property that gets prototypes promoted by accident. The answer is not to slow down or to make prototypes deliberately ugly. It is to decide, before building, what the prototype is for, what is allowed to be fake, and what happens to it afterwards.

The structural change is the material. A canvas prototype is a picture that simulates behaviour through wiring and imagination; an agentic prototype is markup, styles, and components that actually behave. That difference shows up in what you can learn: real text wrapping at real widths, real keyboard focus, real loading and empty states, real responsiveness — the things that decide whether a flow works and that static frames quietly hide.

The second change is iteration cost. When the artifact is text the agent can read and edit, a correction round is a sentence and a couple of minutes, not a re-draw. That is what makes it practical to test structure, copy, and information hierarchy before the team commits to a direction — the core argument of the prototype-first article this module draws on.

Keep the last bullet honest. Speed amplifies whatever direction you point it at. Teams that prototype faster do not automatically decide better; they just reach the decision point with more artifacts. The scoping and review discipline in the rest of this module is what converts the speed into learning rather than into a pile of plausible screens.

This run is taken from the school's published field note on a first Claude Code session, and the timings are from that executed walkthrough, not a benchmark — say so. The task was deliberately tiny: one hero section for a fictional product, one self-contained HTML file, no framework, in a scratch folder. That single-file constraint is itself a prototyping decision: nothing to install, nothing to break, an artifact you can email.

Walk the failure list from the first pass, because it is representative. Fixed 56-pixel type that broke at phone widths, cramped padding, supporting text with marginal contrast against the gradient, an almost invisible hover state, no keyboard focus state, no landmark element. None of these are exotic; they are the defaults of a competent but uninvested contractor, and none are visible unless you actually open the file and resize the window.

The lesson for this course is the shape of the session, not the hero. Even at prototype fidelity, the loop is brief, generate, review, correct — and the review is a real step, not a formality. Expect two or three correction rounds on real work, and expect the prototype at the end to be a sketch with working CSS: good evidence, not production code.

This is the first piece of discipline, and it costs five minutes. The failure mode it prevents is common: a prototype that started as a quick exploration accumulates polish over several sessions, everyone agrees it looks great, and nobody can say what question it answered. The agent is complicit in this, because making things look convincing is what it does cheapest.

Good learning goals are narrow. For an onboarding flow — the case study used in the source article — they look like: does role-first onboarding make the next step clearer, does template preview reduce uncertainty, does the mobile order keep the first useful action above the fold. Each names a decision, and each implies the evidence that would settle it.

The boundary item matters most for agent work specifically. Telling the agent what to ignore — real authentication, analytics, localisation, the parts of the page not under question — is what keeps the run short and the output reviewable. Without a stated boundary, agents tend to fill in everything, and the extra completeness reads as production-readiness it has not earned. The learning goal feeds directly into the prototype contract and fidelity decisions on the next slide.

Designers are used to talking about fidelity as one dial — lo-fi versus hi-fi. With agents the dial breaks into layers, because making any one layer realistic is now cheap. You can have production-quality visuals over completely fake data, or rough grey-box visuals over a real API, and both are legitimate prototypes for different questions.

The risk is mismatched fidelity: the layer under test stays rough while an irrelevant layer gets realistic, which skews what reviewers react to. The classic case is beautiful visuals over three rows of tidy fake data when the actual question was whether the table survives four hundred rows of messy real data. Stakeholders praise the polish; the design question goes unanswered.

The practical move is to make the fidelity decision per layer part of the prototype contract — the short statement in the brief that says what kind of artifact this is, what can be fake, and what must be representative. The source article calls this out directly: a prototype should maximise learning, production code should maximise maintainability and correctness, and the agent needs to be told which one it is building. Left unstated, agents default to adding realism everywhere, which costs time and manufactures false confidence.

This is the central risk of the whole course, so spend time on it. Agent-built prototypes look more finished than hand-built ones ever did: real components, plausible data, working interactions. That polish is exactly what creates false confidence. A stakeholder sees something that works on a laptop and reasonably asks why it cannot ship next sprint; an engineer under deadline pressure reasonably wonders why they should rebuild something that already exists.

Walk the list as named risks rather than sins. Each shortcut is legitimate inside a prototype — that is what makes prototypes cheap. They become dangerous only when they cross into production unexamined. Fake data hides integration and volume problems. Hard-coded states hide everything that happens when users do something unexpected. Local components that mimic system components are the quietest one: they look right today and drift out of sync with the design system from the day they are merged. Skipped accessibility is the one that should be a hard block, not a follow-up ticket.

The reframe to land: the answer is not to make prototypes worse or slower. It is to name the shortcuts at scoping time and again at review time, so the team always knows which parts of the convincing thing are real. That is what the two-track model on the next slide formalises.

Walk the diagram left to right. The prototype track optimises for speed of learning: it lives in a scratch branch or a prototypes folder, fake data and hard-coded states are allowed as long as they are labelled, integrations and analytics are skipped, and the output is evidence — screenshots, learning notes, and a promotion plan. The production track optimises for correctness and maintainability: product architecture, shared components, real data behaviour, accessibility, tests, and QA gates before merge.

The middle is the part teams get wrong. What carries across is the green card: validated decisions, approved patterns and flows, the learning notes and named risks. What must not carry across is the ink card: prototype files pasted into product routes, fake data, local components that mimic system ones, and accessibility deferred to later. The connective tissue is a promotion review — a human decision about what to keep, what to rebuild, what to discard, and what still needs research. The agent can prepare the evidence for that review; it should never promote its own prototype.

Pre-empt the objection that rebuilding is wasted work. The rebuild is usually fast precisely because the decisions are already made and the agent can execute them against the real architecture. What gets thrown away is scaffolding, not learning.

The boundary is not bureaucracy; it is context management for both audiences that will read the project later. Humans need to know which files represent decisions and which represent experiments. Agents need it even more, because an agent asked to extend the product next month will read whatever is in the repository as the product. If a prototype's local button component sits beside the system button with a similar name, some future run will import the wrong one, and a temporary assumption becomes permanent debt.

The structure shown is from the prototype-first article: a clearly named prototypes area inside the app, and a parallel folder holding the brief, learning goals, review notes, and promotion plan. Keeping the paperwork next to the prototype means a future reader — human or agent — can see what was learned and what was never meant to ship.

Disposability is the cultural half. If deleting the prototype after the promotion review feels like losing work, the work was not captured properly: the decisions belong in the promotion plan and the rebuilt production version, the evidence belongs in the notes and screenshots. The prototype files themselves are scaffolding. A scratch branch or a separate folder also keeps the agent's blast radius at zero, which is what lets you give it more freedom during exploration than you ever would on main.

Most prototype-to-production accidents start in a meeting, not in the repository. A polished prototype gets demoed, someone senior asks how far from shipping it is, and the honest answer — the visuals are real, everything underneath is fake — never quite gets said. From that moment the roadmap quietly absorbs an estimate based on what the prototype looks like rather than what it is.

The defence is a sentence at the start of every demo: what kind of artifact this is, what is fake, what question it was built to answer, and roughly what production would involve. The prototype contract from earlier in the module gives you that sentence almost verbatim, which is another reason to write it before building rather than reverse-engineering it under pressure in the meeting.

This is also where 'as of' framing helps with agent-built work specifically. Stakeholders who have seen agents produce working interfaces in minutes can reasonably conclude that production is also minutes away. It is worth saying plainly that the remaining work — real data behaviour, accessibility, error states, integration, QA — is the majority of the engineering effort, and the prototype was deliberately scoped to skip it. That is not a weakness of the prototype; it is the reason it was cheap.

When prototypes were expensive, the scoping question answered itself: nobody built one without a good reason. Agents removed that natural brake. The marginal cost of one more prototype is close to zero, so the constraint shifts from production effort to the team's attention — every artifact you generate asks someone to look at it, react to it, and carry an opinion about it.

Be concrete about the categories. Discovery questions — does anyone have this problem, how do they talk about it, what do they do today — are answered by research, and a prototype built before that research tends to harden guesses into commitments. Prototypes built to validate a decision that has already been made are theatre; they consume review time and produce no information. And in politically charged situations, a working artifact anchors the conversation: once people have seen a direction running, alternatives have to argue against something concrete, which is rarely a fair fight.

The useful test is the learning goal from earlier in the module. If you cannot write the decision, audience, and evidence lines, the right next step is probably an interview, a data pull, or a conversation — not a build. This is also the bridge to Module 2, which is about feeding research and references into the brief so that when you do prototype, it is grounded in something other than the agent's defaults.

This example reuses the onboarding case study from the prototype-first article and pushes it one step further: the same feature scoped three ways, to make the point that scope follows the learning goal rather than the feature. Scope A is the design question — does deciding your role first make the next step clearer — so it needs the full flow clickable and representative data, but the visuals can stay rough because polish would only distract from the structural question. Scope B exists to win a decision from a founder, so the visual and content fidelity go up, but the path narrows to one scripted run, and the rule about touching no production files gets stricter because this is the prototype most likely to be mistaken for the product. Scope C is an engineering question wearing a design hat: can the template preview be fed from the existing APIs — so it ignores visual quality entirely and touches real data in a tightly bounded way.

Notice what stays constant: every scope names what is off-limits, and every scope names the evidence it must produce. Those two lines are what make each prototype reviewable and disposable.

If running this live, ask the room which scope their last prototype actually was — and which one their stakeholders thought it was. The gap between those two answers is the trap from earlier in the module, made personal.

Like the rest of this module, the exercise is about decisions, not prompts — nothing here requires opening a terminal. Steer participants towards something real and bounded: one flow, one surface, one component family. The most common failure is picking something so large that the fidelity decisions become 'real everything', which defeats the exercise.

The two lines people find hardest are the evidence line and the stakeholder sentence. Evidence forces a commitment about what the prototype must produce — screenshots at specific widths, a recorded walkthrough, task notes — and writing it now is what makes the later review honest. The stakeholder sentence is the one-line version of the what-is-fake disclosure, and drafting it before the work exists is far easier than improvising it in a demo while someone asks about ship dates.

If running this in a group, have people swap pages and try to answer one question about each other's scope: what would convince you this prototype succeeded? If the page cannot answer that, the learning goal needs another pass. The page becomes a working input for the rest of the course: Module 2 adds references and research to turn it into a brief, Module 3 forks it into directions, and Module 6 runs the sprint and handoff against it.

Recap by connecting the pieces rather than re-listing them. The speed from slide two is only an asset because of the discipline that follows it: the learning goal decides whether the prototype is worth building, the fidelity decisions decide what it is allowed to fake, the scratch boundary and stakeholder framing keep the convincing artifact honest, and the two-track model decides what survives the prototype's own success. Skip any one of these and the failure mode is the same: a convincing thing treated as a finished thing.

Preview Module 2 concretely. This module assumed you already know roughly what you want to build; the next one is about where that knowledge should come from. References — screenshots, competitor flows, existing patterns — are the richest input designers have and the easiest to misuse, and research findings rarely make it into prompts at all. Module 2 covers annotating references so the agent borrows behaviour rather than cloning surfaces, folding research findings into the brief, and avoiding the copy-this-screenshot trap.

If participants did the exercise, remind them the page is a course-long artifact: it becomes the brief in Module 2, the direction set in Module 3, and the sprint scope in Module 6.