For a long time I was skeptical of LLMs—whenever I reached for them I was disappointed by the results. Last year I tried Copilot and Cursor to tweak a game I’d built, and neither generated working changes. At a previous job I tried Gemini to outline product briefs and generate wireframes, but ended up throwing them all away. Every time I tried LLMs it was 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 just so much that’s new to me, and so much I’m not good at yet, like OCaml and Bonsai. But one big surprise is how much it’s changed the thing I’m best at: my design workflow.
Instead of laboring over spec docs, building Figma mockups, writing proposals, and reviewing the implementation with devs, I find myself building prototype features that 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 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 mockups and docs. Take a prototype I made recently that added LLM prompting to a JSQL input (JSQL is an internal SQL dialect that we use for lots of different user-facing tools). This prototype really works, and I spent days living with it and testing it. Claude gave me free, unlimited iteration, unbothered when I changed my mind for the 50th time or asked for a small tweak. I refined the Submit button, added keyboard shortcuts, tweaked copy, adjusted the prompt, and added generated confirmation messages. These are workflow improvements that would have taken days or weeks of engineering and design back-and-forth at my previous job, or more likely would just never have happened.

All the effort spent on this feature went into improving the real artifact, and none on 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 approached smaller-sized tasks with AI, like UX papercut fixes. For bigger ideas I was still using Figma and docs, and when I tried making those things with Claude it failed.
But in the past 2 months the situations where I’ve reached for Figma have fallen off a cliff. Through some combination of improved models, my own facility with them, and carefully choosing the right scope, AI is now working for big stuff too—not just the JSQL prompt but a half dozen other prototypes that make user-facing, data model, and library changes, including some that are 2000+ line diffs; I’m using it to implement interactive prototypes for brand new apps after designing them in Figma; and for some new apps I’m even skipping Figma entirely, iterating on the visual design from the beginning with Claude.
As a designer this has been empowering. Engineers have the ability to create working proofs of concept when they have an idea. Designers have to convince other people to do that for us. For an idea like “direct LLM prompting in the JSQL input” I’d be proposing something whose feasibility is not even clear at the outset; getting someone to build a prototype might waste their time. In other cases I might propose something that doesn’t clearly fill a user need. By using Claude to make these ideas real I’m making it a lot 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 feature. Does that mean they have zero input on the functionality and are just supposed to review the code? Review is not the most fun work—the equivalent in the design world would be getting a detailed wireframe from a PM and being asked to make it look good. I want to make my proposal as clearly and completely as possible, but I still want my engineering teammates to treat it the same way they’d treat a mockup in Figma, as something they and I can iterate on together in design-space.
Our solution for now is just to think about these features differently. I write a short reminder in the description: prototypes are living proposal docs, the code is disposable, and a reviewer’s job is to give feedback about the design and user experience. Eventually, reviewers still take over the idea and implement it in a separate feature, referencing the prototype but owning the production code. In practice we’re still figuring out what makes sense and feels good with this new workflow.
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 new.
This is a familiar tension. When I was getting started professionally in 2011 there was a lot of discourse about whether designers should code. Critics argued that once you’ve started programming you’re less likely to make big changes to an idea. But I liked making websites, and I liked programming, so I kept writing code. Then, when frontend frameworks like React became common and frontend development got more complicated, like others I decided to specialize. I still made personal projects in React—that certainly helped me interact with devs—but I spent almost all my time at work in Figma and docs.
Had I joined Jane Street before LLMs, I think I would have become even more entrenched in Figma. With JavaScript I at least have some experience; OCaml and Bonsai are entirely new, and contributing on a technical level would have felt out of reach. Instead I’m back to making the real thing, and it feels amazing to be working in the medium again. I feel more free than ever to just try things.