Jane Street Blog - I design with Claude more than Figma now

I design with Claude more than Figma now

Feb 05, 2026 |

5 min read

Share on Facebook

Share on Twitter

Share on LinkedIn

By: Edwin Morris

For a long time I was skeptical of LLMs—whenever I reached for them I was disappointed by<br>the results. Last year I tried Copilot and Cursor to tweak a game I’d built, and neither<br>generated working changes. At a previous job I tried Gemini to outline product briefs and<br>generate wireframes, but ended up throwing them all away. Every time I tried LLMs it was<br>for something I was already good at, and they did a worse job than I would have.

Having joined Jane Street this past summer, I’m finding AI support indispensable. There’s<br>just so much that’s new to me, and so much I’m not good at yet, like<br>OCaml and<br>Bonsai. But one big surprise is how much it’s<br>changed the thing I’m best at: my design workflow.

Instead of laboring over spec docs, building Figma mockups, writing proposals, and<br>reviewing the implementation with devs, I find myself building prototype features that<br>just do the exact thing I have in mind. What that looks like in practice is:

Write something describing the problem and my proposal

Open my editor, start a build, the server, and Claude, using that description I wrote as the prompt

Get the basic functionality working to prove to myself that it’s possible

Iterate on that as much as I want

Push changes to a development environment and ask users what they think

Submit a feature (our<br>version of a pull request) that looks and behaves exactly the way I want

A prototype feature in the actual codebase has felt better in almost every way compared to<br>mockups and docs. Take a prototype I made recently that added LLM prompting to a JSQL<br>input (JSQL is an internal SQL dialect that we use for lots of different user-facing<br>tools). This prototype really works, and I spent days living with it and testing<br>it. Claude gave me free, unlimited iteration, unbothered when I changed my mind for the<br>50th time or asked for a small tweak. I refined the Submit button, added keyboard<br>shortcuts, tweaked copy, adjusted the prompt, and added generated confirmation<br>messages. These are workflow improvements that would have taken days or weeks of<br>engineering and design back-and-forth at my previous job, or more likely would just never<br>have happened.

All the effort spent on this feature went into improving the real artifact, and none on<br>ancillary in-between work like creating Figma components or formatting docs.

It took me a while to arrive at this workflow. When I joined last summer, I only<br>approached smaller-sized tasks with AI, like UX papercut fixes. For bigger ideas I was<br>still using Figma and docs, and when I tried making those things with Claude it<br>failed.

But in the past 2 months the situations where I’ve reached for Figma have fallen off a<br>cliff. Through some combination of improved models, my own facility with them, and<br>carefully choosing the right scope, AI is now working for big stuff too—not just the JSQL<br>prompt but a half dozen other prototypes that make user-facing, data model, and library<br>changes, including some that are 2000+ line diffs; I’m using it to implement interactive<br>prototypes for brand new apps after designing them in Figma; and for some new apps I’m<br>even skipping Figma entirely, iterating on the visual design from the beginning with<br>Claude.

As a designer this has been empowering. Engineers have the ability to create working<br>proofs of concept when they have an idea. Designers have to convince other people to do<br>that for us. For an idea like “direct LLM prompting in the JSQL input” I’d be proposing<br>something whose feasibility is not even clear at the outset; getting someone to build a<br>prototype might waste their time. In other cases I might propose something that doesn’t<br>clearly fill a user need. By using Claude to make these ideas real I’m making it a lot<br>easier for others to evaluate them—they can just use it.

But there’s a downside: in this workflow, the reviewer is given a fully baked<br>feature. Does that mean they have zero input on the functionality and are just supposed to<br>review the code? Review is not the most fun work—the equivalent in the design world would<br>be getting a detailed wireframe from a PM and being asked to make it look good. I want to<br>make my proposal as clearly and completely as possible, but I still want my engineering<br>teammates to treat it the same way they’d treat a mockup in Figma, as something they and I<br>can iterate on together in design-space.

Our solution for now is just to think about these features differently. I write a short<br>reminder in the description: prototypes are living proposal docs, the code is disposable,<br>and a reviewer’s job is to give feedback about the design and user experience. Eventually,<br>reviewers still take over the idea and implement it in a separate feature, referencing the<br>prototype but owning the production code. In practice we’re still...