HN Debrief

I design with Claude more than Figma now

  • AI
  • Design
  • Programming
  • Developer Tools
  • Product Management

The post is a Jane Street designer’s account of shifting from Figma to Claude Code for interface work. The claim is not that Figma is dead or that designers should ship raw AI code. It is that, for a certain class of internal product work, interactive prototypes in code are now the fastest way to make an idea legible, test it with users, and iterate on behavior instead of arguing over static mockups. In the post’s workflow, those prototypes are treated as disposable proposal documents. Reviewers respond to the experience and interaction model, then engineers build the production version separately and own the real code.

Treat LLM-built UI as a faster prototyping layer, not as proof that design or engineering work disappeared. If your team adopts this workflow, set explicit rules for ownership, specs, review, and what must be rewritten before production, or you will trade design speed for delivery and maintenance chaos.

Discussion mood

Cautiously positive about AI for rapid UI prototyping, but skeptical of the hype and strongly negative about treating generated prototypes as production-ready. The mood turned sour whenever comments moved from demo value to organizational pressure, missing specs, maintenance burden, security risk, and the expectation that engineers should bless or clean up AI-generated code on short notice.

Key insights

  1. 01

    Prompt history is latent requirements data

    What business people hand to engineering is no longer just a sketch. A vibe-coded prototype usually embeds dozens of micro-decisions, rejected interactions, and explicit assumptions made during prompting. If teams keep the chat logs, they can mine them for requirement decisions that were never written down anywhere else. That makes the prototype more informative than a napkin mockup, even when the code itself is junk.

    If your org is using AI prototyping, preserve prompts, diffs, and iteration history as product artifacts. They may be the clearest record of why the prototype behaves the way it does.

      Attribution:
    • gwerbin #1
    • iamjs #1
    • 8note #1
  2. 02

    Generated prototypes can slow shipping

    The pain is not writing code. It is auditing what the model invented. Engineers described spending time reconstructing intended behavior, spotting unintended changes, and rethinking decisions the model papered over with plausible defaults. That turns a fast prototype into slower delivery because the hard thinking got deferred, not removed.

    Measure cycle time from idea to production, not from idea to clickable demo. If shipping does not get faster, your new workflow is just moving ambiguity downstream.

      Attribution:
    • kcrwfrd_ #1
    • drpotato #1
    • MikeNotThePope #1
  3. 03

    LLMs are not a compiler abstraction

    Calling AI-generated code a higher abstraction layer misses the key difference. A compiler translates an unambiguous program deterministically. An LLM resolves ambiguity by guessing. That means engineers still need to inspect outcomes because the model is not preserving intent with compiler-like reliability. Treating it like generated assembly hides the actual risk.

    Build AI coding policy around uncertainty, not around the compiler analogy. Require review and tests anywhere ambiguous prompts could have created silent mistakes.

      Attribution:
    • movedx01 #1
    • lelanthran #1
  4. 04

    Interactive prototypes help users but can exhaust reviewers

    Code prototypes make ideas easier to test with users because people react better to concrete behavior than to static frames. But that same concreteness can overload internal reviewers. Instead of comparing flows on one canvas, they have to click through states one at a time and evaluate too many half-baked options. The tool improves one feedback loop while making another worse.

    Use coded prototypes for user testing and behavior validation. For design review, still produce a compact view of flows and rationale so people are not forced to discover the design by clicking around.

      Attribution:
    • vasco #1
    • ehmorris #1
    • risyachka #1
  5. 05

    Storybook can replace parts of Figma

    Some teams are already moving the source of truth for UI into code with Storybook and using tools like Chromatic for review. That works best when the job is documenting real components and states. It does not replace Figma’s role in maintaining broad design systems across products and platforms, where non-code collaboration and shared visual language still matter.

    Separate design-system work from feature prototyping in your tool choices. Storybook is compelling when your system already lives in components, but it is not a full substitute for cross-platform design governance.

      Attribution:
    • bobkb #1
    • ale #1
  6. 06

    Default AI design converges on safe sameness

    Multiple people said Claude produces competent but generic modern web UI unless you push it hard with examples, typography choices, and explicit aesthetic direction. Out of the box it tends toward Tailwind-like defaults and repeated visual patterns. That makes it strong for baseline usability and weak for distinctive taste.

    If brand or originality matters, treat prompting for aesthetics as a real design task. Bring references, constraints, and style language or accept a polished but interchangeable result.

      Attribution:
    • JasonSage #1
    • monkeydust #1
    • epolanski #1
    • techpression #1
  7. 07

    AI speeds the cheap 20 percent

    For people who already worked by sketching, then hacking together a rough frontend demo, Claude mostly compresses the implementation slice rather than the whole process. User conversations and product thinking still dominate the schedule. The gain is real, but narrower than the headline implies.

    Do not forecast team productivity as if AI shrinks the entire design cycle. It mostly reduces prototype assembly time, so bottlenecks move to decision-making and review.

      Attribution:
    • t0mas88 #1

Against the grain

  1. 01

    Some vibe-coded apps are closer than engineers admit

    There was a credible pushback against reflexively dismissing business-built prototypes. In some cases the gap to production is cleanup, testing, and selective rewrites rather than a total restart. AI lowers the cost of refactoring enough that “throw it away and rebuild” is not always the rational answer anymore.

    Evaluate prototypes on concrete defects and operational risk, not on who made them. You may be able to ship faster by hardening a useful prototype than by restarting from zero.

      Attribution:
    • chatmasta #1
    • gwerbin #1
    • 8note #1
  2. 02

    Demos can improve product communication

    A working mockup can reveal what someone means better than text ever did. Instead of narrowing thought, it can expand what non-technical people are able to express. The failure is not the demo itself. It is the culture that mistakes a demo for final architecture or denies engineers equal freedom to answer with their own prototypes and alternatives.

    Use prototypes as a shared language, not as a mandate. Pair them with explicit permission to challenge assumptions and redesign the implementation.

      Attribution:
    • frde_me #1 #2
  3. 03

    Cheap AI shifts work users should never have paid for

    A few comments argued that AI is correctly eating a layer of low-value digital labor. Small websites, internal tools, and routine frontend chores were often expensive only because skilled people had to do mechanically tedious work. For those cases, lower quality may still be a net win if the old alternative was stale sites, gatekept logins, or work that never got done.

    Look for categories of work where “good enough now” beats “professionally done never.” AI will likely expand access there before it proves itself on higher-stakes systems.

      Attribution:
    • JumpCrisscross #1 #2
    • camillomiller #1
    • josephg #1 #2

In plain english

Chromatic
A service for reviewing UI changes, often used with Storybook to compare visual differences between versions.
Figma
A widely used design and prototyping tool for creating interface mockups, design systems, and collaborative visual work.
LLM
Large language model, a machine learning system trained on large amounts of text that can generate and analyze language and code.
React
A popular JavaScript library for building user interfaces out of reusable components.
Storybook
A tool for developing and reviewing UI components in isolation outside the full application.
Tailwind
A CSS framework built around small utility classes that often gives web apps a recognizable modern default style.
UI
User Interface, the screens and controls people use to interact with a software product.

Reference links

Jane Street and AI context

AI training and methods references

AI skepticism and history

  • ELIZA
    Shared to argue that people are still over-attributing intelligence to conversational systems.
  • ELIZA effect
    Used to explain why humans project understanding onto chatbots and LLMs.

Related Hacker News discussion

Market references

  • Figma stock quote
    Linked during discussion of whether AI competition is hurting Figma’s prospects.