2026-06-08

Designing in the Codebase Instead of the Mockup Tool

This Jane Street post is interesting because it shows Claude being used not just to write code, but to collapse the distance between design intent and a shippable prototype. For Claude Code users, that’s the real shift: the model isn’t only speeding up implementation, it’s changing what it even means to “design” software. I think that’s a much bigger deal than yet another demo of code generation.

Key Points

The author, a designer at Jane Street, says they were long skeptical of LLMs because earlier attempts with Copilot, Cursor, and Gemini didn’t produce useful results.
The turning point came after joining Jane Street, where they faced unfamiliar tooling and concepts like OCaml and Bonsai, making AI support genuinely helpful.
Their workflow has shifted from:
- writing spec docs,
- creating Figma mockups,
- asking engineers to implement,
- and reviewing the result,
  to instead building prototype features directly in the actual codebase with Claude.
They describe a loop of:
- writing a short description of the problem and proposal,
- using that as a prompt,
- getting basic functionality working,
- iterating repeatedly,
- pushing to a development environment,
- and asking users for feedback.
A concrete example is an internal prototype that added LLM prompting to a JSQL input, complete with submit button changes, keyboard shortcuts, copy tweaks, prompt adjustments, and generated confirmation messages.
The author says Claude made this kind of iteration feel effectively unlimited, allowing rapid tweaks that would previously have taken days or weeks of design-engineering back-and-forth.
They report that Figma use has dropped sharply; for some new apps, they now skip Figma entirely and iterate on visual design directly with Claude.
They argue this is empowering for designers because it lets them turn ideas into something people can actually use, rather than asking engineers to prove feasibility for them.
There is also a tension: once a prototype is fully baked, reviewers may feel they’re only being asked to review code instead of shaping the idea.
Their current workaround is to treat prototypes as living proposal docs, keep the code disposable, and have reviewers comment on design and UX rather than production implementation.
They also worry that designing with Claude might encourage incrementalism and limit more fluid, exploratory thinking.
The piece ends on a positive note: compared with being stuck in Figma/docs, they feel more free than ever to try things in the real medium again.

My Take

What strikes me is how practical this is. This isn’t the usual “AI will revolutionize design” slogan; it’s a specific workflow change where Claude helps a designer do the thing they were already trying to do, but closer to the final artifact. I think that’s where Claude Code feels most credible: not replacing taste or judgment, but removing the tax of turning ideas into something testable.

I’m especially interested in the “prototype in the actual codebase” part. That’s exciting because it tightens the feedback loop dramatically. A mockup can lie to you; a working prototype has edge cases, constraints, and interaction details that force honesty. If you’re building with Claude, I’d actually try this myself for product ideas that are hard to explain in Figma but easy to understand once they exist.

At the same time, I share the author’s concern about overfitting to what the model can easily produce. I think that’s a real trap. If Claude makes it effortless to iterate on what’s already in your head, you may end up polishing the first plausible idea instead of discovering a better one. Perhaps the right discipline is to use Claude for rapid embodiment, but still reserve some time for rough, dumb, non-code exploration.

The other subtle point is review culture. A fully realized prototype can be a gift, but it can also be socially awkward: people may hesitate to critique it because it feels “done.” I’d be curious whether teams can develop a stronger norm around disposable prototypes so they stay conversation starters, not shadow production systems.

Overall, this is one of the more convincing descriptions I’ve seen of Claude changing a creative workflow in a nontrivial way. The big takeaway is simple: when the model is good enough, the boundary between design and implementation starts to blur, and that can be genuinely liberating.