Colin Matthews shows Claire Vo how he makes AI-generated prototypes look like an existing product. The June 2025 How I AI episode starts with screenshots in v0, moves to extracting browser elements with Magic Patterns, and ends with versioning and debugging. Matthews, a product manager and founder, treats a component library as a shared team asset. Each component is a reusable interface piece, such as a search bar or booking card.

Build the pieces before the screen · 02:48–05:47

  • Vo describes a common adoption problem: a prototype may express the right idea while looking nothing like the company’s product. That mismatch distracts the team before it can judge the feature.
  • Matthews starts with a prompt that defines the technologies, expected behavior, and a component-library output. He supplies screenshots and asks the model to extract components, then continues adding screenshots from other pages.
  • Models sometimes reproduce the whole screen anyway. He corrects the request explicitly: make a page listing components, rather than assembling the application view yet.
  • The Airbnb example yields recognizable building blocks: the logo, search, category navigation, ratings, and property cards. The same collection can serve several prototypes or several people.

Fork the library and compose a prototype · 05:49–10:31

  • Matthews uses v0’s fork action to copy the project while preserving the original library. The copied files become the starting material for a homepage request.
  • He then requests a property-detail screen. The model imports relevant pieces, including amenities and booking components, rather than placing every available component on each page.
  • The goal is recognizable product styling. Matthews points out mismatched icons and imagery; Vo describes the result as more contextual than a generic wireframe, without claiming a pixel-perfect specification.
  • The demo also exposes unfinished routing. Matthews needs to address navigation and try a property URL manually. Familiar visual styling and working interactions remain separate things to check.

Use HTML when screenshots are too indirect · 11:09–14:29

  • Matthews says modular structure produces fewer errors in his experience because the model mainly assembles existing pieces. He then demonstrates Magic Patterns using a prepared ChatPRD component collection.
  • The generated chat screen draws on a sidebar, message component, message input, and options menu. Vo recognizes her product’s layout, though she points out differences in color.
  • A random portrait appears in the prototype. Their attempt to remove it becomes a recurring example of how even a convincing composition can contain stubborn mistakes.
  • Matthews discloses that he advised Magic Patterns for about a month. That relationship matters when weighing his enthusiasm for the product.

Turn a browser element into a reusable component · 15:37–17:49

  • Matthews opens ChatPRD and uses the Magic Patterns Chrome extension to select an interface element. He chooses “convert to component” and adds it to the library.
  • The input includes the element’s HTML, giving the model styling and structure to rebuild. In the table example, the result can accept data and be reused elsewhere.
  • Vo explains why copying a production component directly can be awkward: it often contains application logic that the prototype does not need. The prototype chiefly needs the appearance and interface behavior.
  • Matthews’ sequence is concrete: visit the product, extract an element, convert it, add it to the library, and assemble screens from those assets. Vo encourages original designs inspired by interaction patterns rather than carbon copies.

Improve the library where the work can spread · 17:52–20:10

  • Matthews publishes the component and shows imports in the earlier prototype. An “upgrade to latest” action can bring a revised component into an existing experiment.
  • A team can assign someone to improve visual fidelity at the library level. That effort then remains available to other prototypes, instead of being trapped inside one chat.
  • Vo compares this to improving a reusable prompt rather than fixing every generated document individually. Matthews argues that better underlying pieces also reduce dependence on finding exactly the right words in each request.

Keep a baseline and name the alternatives · 20:13–25:04

  • In Magic Patterns, a project canvas displays prototypes together. Matthews copies an existing version, then asks the copy to implement a functional chat and connect the new-chat button.
  • He labels the starting version “baseline” and names variants with a number and description. Teammates can compare alternatives while keeping a known starting point intact.
  • Vo recommends checkpoints whenever something works, and forks before uncertain exploration. A copy preserves the underlying prototype and chat, not merely a screenshot of the screen.
  • Matthews sees prepared baselines as onboarding help. A teammate starts with familiar components and a working direction rather than confronting a blank prompt and repeated errors.

Bring designers and engineers into the process · 25:05–28:08

  • Matthews advises against handing a finished-looking feature to a designer with a request to “clean it up.” He frames prototypes as a way for anyone, including operations and customer success, to communicate ideas.
  • Engineers can reuse the generated code if it helps. They can also discard it. The prototype is a starting point for discussion, not a requirement to ship that implementation.
  • Structure does not prevent product exploration. Matthews describes building a prototype-analytics idea in Cursor, testing it with a few people, and dropping it when it failed to resonate.

Ask for an explanation before another patch · 28:29–31:37

  • For the unwanted portrait and other errors, Matthews first asks why the problem happens and explicitly says not to write code. He requests implementation only after the explanation.
  • Vo adds her variation: ask for the top three hypotheses in priority order, again without code. Both separate diagnosis from changes so the next generation has a plan.
  • Matthews closes with his courses and team workshops. The lasting assets in his approach are the shared components and baseline prototypes, alongside clearer expectations about who does what.

Caveat: these are prototype demonstrations; recognizable styling does not establish production readiness or permission to reuse another product’s assets.