The Jane Street engineer argues that a working prototype generated in 30 seconds is more useful than a static mockup that still has to be re-implemented in code. Since the LLM produces working code directly, iterating on the running artifact is faster and more honest than iterating in a vector editor and then translating designs to code.
By submitting the post and driving it to 279 points, the submitter amplified the inversion-of-workflow argument. The HN crowd largely cheered the framing that the design-to-engineering handoff is obsolete when the LLM can skip the mockup step entirely.
Designers pushed back that producing variant #4 of a sortable table with filters is not design — it's plumbing data into a component library that has been written down a million times in the LLM's training set. Real design work involves novel interaction models, brand surface, and onboarding flows that an LLM cannot invent from prior art.
The editorial argues that Jane Street's UIs are information-dense internal dashboards for traders — no brand, no marketing site, no novel interactions, no first-time-user delight. That makes them exactly the domain LLMs excel at, and the workflow cleanly extends to admin panels, observability dashboards, and ops consoles, but does not transfer to consumer products where the design space is open-ended.
A Jane Street engineer published an essay on the firm's engineering blog titled *I design with Claude Code more than Figma now*. It hit the top of Hacker News with 279 points and several hundred comments. The argument, stripped of varnish: a working prototype generated in 30 seconds beats a static mockup that has to be re-implemented anyway. Why iterate in a vector editor and then translate to code, when the LLM produces the code directly and you iterate on the running thing?
The HN comments largely agree. Discussion split between developers cheering the inversion of the design-engineering workflow and designers pointing out — correctly — that what's being described isn't really *design*. It's UI assembly from a known component vocabulary. The post is being amplified as a Figma obituary, but the dataset of one is Jane Street: a quant trading firm whose UIs are internal tools for traders, not consumer products.
That distinction is doing all the work in the argument, and almost none of the discourse is acknowledging it.
Jane Street's UIs are dashboards. Information density and latency dominate aesthetic novelty. There is no brand surface. There is no marketing site. There is no animation library, no novel interaction model to invent, no onboarding flow that has to feel delightful to someone who has never seen the product before. The user is a colleague. The design space is small, and most of the work is plumbing data into a known component library.
Claude Code is excellent at exactly that work — and it should be. The space of "sortable table with filters and a chart on the right" has been written down a million times in its training set. Asking an LLM to produce variant #4 of a known UI archetype is well inside its envelope. The Jane Street workflow generalizes cleanly to anyone building internal tools — admin panels, observability dashboards, ops consoles, internal CRUD. It does not generalize to consumer products where the design IS the product.
This is the same boundary that separates real insight from cargo cult elsewhere in our industry. "Linear is fast because of sync engine" generalizes. "Linear is fast because of React tricks" doesn't. "You can replace Figma with Claude for internal tools" generalizes. "You can replace Figma" doesn't.
The honest reading of Figma's moat is also worth restating. Figma's moat was never 'the easiest way to draw rectangles.' It was the social workflow: design review, component libraries shared with engineering, dev-mode handoff specs, comment threads on specific frames, and the political artifact that a design system *is*. Claude Code replaces the *artifact* part of that workflow for low-novelty UIs. It does not replace the *review* part. And on consumer products, review is where most of the design value gets produced — the decision to remove a control, to add a sixteenth of a second of motion, to use the secondary color, to break a convention deliberately.
None of those decisions get made well by writing a prompt and looking at three React variants.
If you're building internal tools — stop opening Figma. The handoff overhead is not worth it when the implementation is 30 seconds away and the design vocabulary is already fixed. Have an engineer write spec text, let Claude Code generate three variants, review the running app, iterate. The Jane Street workflow is correct for this case and you should adopt it today. Internal-tool design is now an AI workload, and treating it as anything else is paying a tax.
If you're building consumer products, the workflow does not invert. What changes is iteration speed *inside* Figma's existing role: AI generates the first dozen "what if we tried X" components instantly, designers curate, the team produces the canonical mockup and the handoff spec. The handoff still exists because the implementation requires deliberate decisions about accessibility, motion, edge cases, brand consistency, and the dozen tiny choices that compound into whether the product feels coherent.
The teams that will lose are the ones who can't tell which side of this line they're on. A startup building "Linear for X" — i.e., a consumer-grade product where UX is the moat — that decides Claude Code is its design tool will ship something that looks like an internal tool. The components will be correct. The empty states will exist. Tab order will work. And no one will care, because the product will feel like a Bloomberg terminal that someone slapped a logo on. The teams who win adopt the Jane Street workflow exactly where it fits: anywhere the user is a colleague, not a customer.
If you're a designer, the threat is not Claude. It's the org chart. Companies whose entire product surface is internal tools will reduce design headcount. Companies whose product surface is consumer-facing will not — they'll add AI to designers' loops, not subtract designers from the process. Get clear on which kind of company you're at.
Figma's response isn't to compete with Anthropic and Vercel on code generation. That race is over and Figma was never going to win it. The interesting question is whether Figma can become the *review surface* for AI-generated UIs: drop a Claude-built React component in, get critique, design-system drift checks, accessibility audits, component-library compliance, comment threads bound to specific running states rather than static frames. That's a workflow worth defending — and one that's structurally hard for a terminal-based coding agent to provide. Selling vector editors in 2026 is not a strategy. Selling the place where humans and AI agree on what good looks like still might be.
I think Jane Street is an Anthropic investor, so take it fwiw.
Designer here. There is a lot of pressure at the startup I work at to use AI for everything so we can 'move faster'. Often working with vague requirements. Given leaderships inexperience building software, having something to look at and point to is helpful for sussing out requirements and
With a vibecoded multiplayer web IDE for our flutter app, I have two nontechnical team members prototype app features from a browser all day. The outcome is a git branch with functional dart code, and a strictly more powerful design prompt than figma make. Claude built its own claude -p harness that
> There’s also a fear I have that designing with Claude keeps me out of a fluid, creative mindset and stuck in an iterative one, constrained to the outcomes I think Claude can produce. That’s fine for mature tools, where changes are iterative, but might mean I miss ideas when working on something
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
We already have the business side come with requirements in the form of 'solutions' that they have thought up, which more often than not are Rube Golberg-esque contraptions, that you have to conversationally reverse engineer to arrive at the actual requirements.In the future they will come