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.
