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.

That framing mattered because most of the useful reaction settled on a narrower point than the headline. People who already prototyped in React, Storybook, or rough frontend code said AI mostly accelerates an existing pattern. It gets you to a working demo faster, especially for UI where defects are visible and the code is largely declarative. It does not remove the expensive parts of software work. Several comments pinned that cost on product thinking, edge cases, domain validation, operations, and review overhead. Teams described a familiar failure mode where product or business staff arrive with a vibe-coded feature that looks “95% done,” then expect engineers to push it live, even though the missing 5% is where correctness, security, responsiveness, data handling, and maintainability live. A second theme was that working prototypes can improve communication while also degrading it if they replace specs. Some people strongly preferred a demo plus conversation over vague written requirements because it exposes assumptions and lets users react to something concrete. Others said generated prototypes create a new tax. Engineers have to reverse engineer intent from slop, separate intended behavior from accidental changes, and decide whether to salvage the generated code or start over. More than one person said this has not actually sped up shipping, because the model fills in missing thought with plausible guesses and pushes real design decisions later into the process. The strongest consensus was pragmatic. LLMs are already useful for disposable frontends, internal tools, and quick iteration. They are much less convincing as a replacement for design systems, polished cross-product collaboration, or production engineering discipline. Several people also pushed back on the article’s use of “design,” arguing the post is really about rapid prototyping. The practical line readers drew was simple: use AI to make ideas concrete faster, but do not confuse a convincing prototype with a finished system or let it erase the human work of deciding what should be built and who will carry the risk once it is live.

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.

June 7, 2026
blog.janestreet.com
Discuss on HN

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

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

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

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

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

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

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

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

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

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

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 design and prototyping tool often used to define user interface layouts and design systems.

LLM ↩

Large language model, a type of AI system trained on huge amounts of text to generate and analyze language.

React ↩

A popular JavaScript library for building web user interfaces.

Storybook ↩

A tool for developing and testing user interface components in isolation.

Tailwind ↩

A utility-first CSS framework that styles pages by composing many small predefined class names.

UI ↩

User Interface, the screens and interactions people use to operate a product.

Reference links

Jane Street and AI context

SEBI vs Jane Street index manipulation scandal and a regtech wake-up call
Shared as background on Jane Street after commenters questioned whether the company should be taken at face value.
Jane Street’s Indian options trade was too good
Offered as a stronger analysis of the India regulatory controversy than the earlier link.
Archive copy of Bloomberg piece on Jane Street’s Indian options trade
Alternate access link to the Bloomberg analysis mentioned in the same subthread.
Jane Street plans new data center as compute power runs scarce
Used to argue that Jane Street has a strong institutional incentive to promote AI adoption.

AI training and methods references

Direct Preference Optimization paper
Cited in a speculative comment about how Claude Design might be improving through human-guided feedback loops.
Proximal Policy Optimization
Linked as background for the same reinforcement learning speculation.
Soft Actor-Critic documentation
Another technical reference included in the comment about actor-critic style training ideas.

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

Earlier Hacker News thread about whether HN is anti-AI
Referenced during meta discussion about whether AI stories dominate the site.

Market references

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