GitHub opened Replica for design-system prototypes. Make the demo confess what is fake

THE SIGNAL IN ONE SENTENCE

A prototype is supposed to answer a question. Can a customer understand the new filter? Will a reviewer find the approval step? Does this workflow feel faster than the old one? Then the prototype gets polished. The buttons look right. The data looks plausible. The transition is smooth. Someone says it is basically done. That is how a question accidentally becomes a promise. GitHub has open sourced Replica, an AI prototyping tool created by GitHub Design for designers, product managers and engineers. Replica uses a team’s existing components, patterns and documentation as guidance. A person describes an idea through the GitHub Copilot app, sees the prototype beside the conversation and refines it. The project is available under the MIT license. Teams can work locally without a server or Replica Hub. An optional self-hosted Hub can publish prototypes for teammates to explore and comment on. The plain-language signal is useful. AI prototypes are moving closer to real product systems because they can borrow the design system that makes those products recognizable. That makes the demo more convincing. It also makes the gap between visible polish and invisible reality more dangerous. The fix is not to make prototypes uglier. It is to make them honest. Attach an assumption receipt to every generated prototype. The receipt begins with the question. Write one sentence describing what the prototype is meant to learn. Not what it contains. Not which feature someone requested. Name the uncertain decision. For example: Can an account owner understand why a payment is paused and choose the correct recovery action without contacting support? That question determines what the prototype needs to simulate and what evidence counts. If the team cannot name the question, the prototype is probably becoming a decorative roadmap argument. Next, declare the audience and scenario. Name the user, their goal, their device, their permissions, the starting state and the event that brought them into the flow. A beautiful admin screen tested with people who are not administrators proves very little. Then mark every source of truth. Replica can use approved design-system guidance, which is one of its most interesting qualities. The component library can keep spacing, patterns and interaction language closer to the actual product than a generic generator. But a component is not the same as a working system. A real button may sit in front of a fake endpoint. A production table may contain imaginary rows. A familiar confirmation dialog may promise an operation the service cannot safely reverse. The receipt should separate reused interface truth from simulated product behavior. List which components came from the design system, which were altered, which were invented and which guidance version the generator used. Now label the data. Is it static fixture data, generated data, redacted production data or a live connection? For every field, say whether its shape, range and edge cases match the real source. If a balance never goes negative in the demo, record that. If every customer has a complete profile, record that too. Friendly demo data has a habit of deleting the cases that make software difficult. Missing names, duplicated records, delayed updates, expired permissions, enormous values, empty histories and conflicting statuses are not ugly accidents. They are the product. Build a state inventory before anyone celebrates the main path. Include loading, empty, partial, stale, offline, unauthorized, forbidden, error, timeout, retry, duplicate submission, success with warnings and rollback. Not every prototype needs every state rendered. Every prototype should say which states are absent. That distinction matters. An intentionally omitted timeout is a research boundary. An invisible timeout is a future bug wearing good typography. Do the same for integrations. Replica can make a workflow appear connected because the interaction is visible. The receipt should name which services are actually called, which responses are mocked, which events would be asynchronous, which permissions are needed and which dependency owners have agreed the contract is possible. If a notification arrives instantly in the prototype but the real system uses a batch job, say so. If a search result appears without rate limits, indexing delay or access filtering, say so. If a file upload pretends malware scanning, storage quotas and retention do not exist, say so rather loudly. Security belongs in the receipt before implementation. Record authentication assumptions, authorization roles, data classification, secret handling, audit requirements, abuse cases and destructive actions. Mark any control shown visually but not exercised. A lock icon is not access control. A confirmation dialog is not a permission check. A self-hosted review space is not proof that all product or prototype data stays inside the organization. GitHub’s Replica repository is refreshingly explicit about that last point. The optional Hub is operated by the organization and stores publishing and review activity in its own database. The documentation says those activity events are retained for 90 days. Export to Segment, Mixpanel or a custom HTTPS endpoint requires administrator configuration, and Replica does not automatically send those activity events to GitHub. The same documentation says GitHub services and the selected AI provider have their own data handling and terms. Using a self-hosted Hub does not mean no data leaves the organization. Put that boundary in the receipt. The documented canvas workflow requires GitHub sign-in. GitHub-hosted models require a Copilot plan, or a team can connect its own model provider without a Copilot plan. The bring-your-own-provider option is in public preview, and that provider’s costs and terms apply. Map the path that prompts, repository context, design guidance and generated code take through those systems. Do not use “self-hosted” as a magic privacy adjective. Accessibility needs the same treatment. Design-system components may carry strong keyboard, contrast and semantic behavior. Generated composition can still misuse them. Test keyboard order, focus management, screen-reader names, zoom, reflow, motion preferences, error announcement and touch targets. If the prototype cannot exercise an accessibility behavior, mark it untested rather than inherited. Then expose the fidelity level. Use three simple labels inside the receipt: visual, interactive, and integrated. Visual means the interface communicates appearance and hierarchy. Interactive means the local states and transitions work well enough to test a flow. Integrated means at least one real system boundary is connected under realistic permissions and failure behavior. Do not let a prototype jump from visual to production-ready because it has nice hover states. Add a confidence statement for every finding. Five teammates saying they like the design is feedback. It is not evidence that customers can complete the task. A moderated test with representative users is stronger, but still limited by the prototype’s missing data and integrations. Tie each conclusion to the participants, scenario, prototype version and observed behavior. The assumption receipt should get shorter as the product gets more real. An assumption can be confirmed, rejected, carried forward with an owner or converted into an implementation requirement. Keep the history. Do not silently delete the note after someone builds the missing API. That history explains why the interface exists. Replica’s optional Hub can help with the review loop. Teammates can explore published prototypes and leave comments. Local work can later connect to the same repository and Hub. Use comments to challenge assumptions, not simply vote on polish. Ask reviewers: What appears real but is simulated? Which user or state is missing? What would prevent this from shipping? Which behavior depends on another team? What evidence would change your mind? Those questions turn a prototype review into product work. The infrastructure deserves its own receipt too. Local prototyping requires the Copilot app, Git and Node.js with npm on macOS or Linux. Hosted publishing and comments add a Linux server, dedicated domain with wildcard DNS and HTTPS, network access and GitHub permissions and approvals. That is not a one-click hosted toy. Teams choosing the Hub should plan patching, backups, retention, access review, monitoring and incident response. The repository says Replica is under active development and support is limited to the resources in its support policy. Treat the deployment like software your organization operates. Open source helps because teams can inspect, adapt and contribute to the tooling. MIT licensing does not convert an early project into a finished platform. The better mental model is a workbench. Replica brings the design system, natural-language iteration, a side-by-side canvas and an optional shared review space onto that bench. The team still decides what it is trying to learn. The team still tests the uncomfortable states. The team still owns every promise the prototype makes. A generated prototype can save days of assembly. Spend part of that time making the receipt. List the fake data. Open the missing panels. Name the unbuilt integrations. Mark the untested controls. Then let the demo be impressive for the right reason. It made the next decision clearer without pretending the whole product already exists.