back
266 comments
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 with their 'ready' solution, already 'working' and be even less receptive to look at design and architecture holistically. Just make it like that. And why do you need to spend X man hours? The thing is basically already done!

I have seen this already. Vibecoded top to bottom.

The downside is that the business people don't understand why you can't just put their app in production as is. And then there's a lot of pressure to make it happen quickly "because we can use AI to move fast". This is going to come down to healthy organization dynamics, and hopefully represents a learning opportunity for leadership.

The upside is that the idea has already been proven out much more thoroughly than a sketch on a napkin. Claude has already prompted them about edge cases and design decisions. It's very likely that at some point they had to explicitly tell Claude "don't worry about that and just make an assumption", or "I actually don't like that interaction after trying it a few times, can you do a differently". They had to write out much of their idea in clear and direct language in order to prompt the AI. They've probably been playing with their own toy because it's fun to play with toys you summoned from thin air, so they've had a chance to discover the experience and refine their own preferences.

It's probably a net negative right now because the "ship it what's the problem team" pressure is intense and stupid and demoralizing and miserable to work under. But I think it will stabilize and it might be a net positive in future projects.

> The thing is basically already done!

I'm seeing so many of these come in with "this is 95% done, just need a couple of minor tweaks for production release"

"Minor tweaks" being fix the layout so it's not messed up if the browser isn't exactly 1920px wide, sometimes these filters and sorting don't seem to work right and the app doesn't seem to refresh new values properly after an action.

No matter the issue it's pre-estimated by the business as "should be a quick fix, for an experienced dev" because they (allegedly) did 95% of the work already.

> In the future they will come with their 'ready' solution, already 'working' and be even less receptive

This has already been common in the audio engineering world for some time, as home demos of music approach professional quality. As you forsee here, people get used to what they have and become even less inclined to accept changes in a new professional mix.

> We already have the business side come with requirements in the form of 'solutions' that they have thought up

We have that too and more often than not, it’s not what a customer wants. Yes there are some very talented customer facing people (PMs, CSMs, TAMs etc.) that also have a natural knack for translating customer problems into product features with great usability. However, for the rest, skipping the part of defining the problem and letting other functions to come up with a solution, usually leads to catastrophic messes that waste a lot of engineering and other resources. When someone shows up with a solution, you risk wasting months of resources in making production ready software, only to find, customers hate it and the solution either doesn’t fix the problem or introduces new ones.

I honestly much prefer this to the old way where the only mode of communication was speech or text. I now often understand a lot more holistically what the person coming with their product wants with just a demo + a conversation.

Of course you need the person making that vibe product to understand it's just a mockup of their idea and that it'll change. But I would argue this has always been a necessary quality for a product person.

I can say that its happening right now (not where I work, at a place I used to). Even being shipped to production as-is, with data loss and security issues in tow. We're cooked haha
I’ve seen that play out already as well

Then your job as SE just becomes reviewing and untangling vibe-coded stuff

I think Jane Street is an Anthropic investor, so take it fwiw.
With a huge pile of salt

> In July 2025, the Securities and Exchange Board of India (SEBI) alleged that Jane Street used multiple entities for market manipulation and barred it from accessing the market.

As I understand Jane Street they have done great things for OCaml and they also do their own web framework (I guess that big money bin needs a lot of dashboards).

I think the designer here takes a wrong approach and sort of falls into engineer envy where he wants to make prototypes as deep and realistic as possible. And that is not really the most important part of the design job.

The most important thing is that the right thing gets build (why do we need a JSQL input box? what do we actually want? what are other ways to do this?). And this is often better done with pen and paper sketches, meetings, observation, discussions ... rather than too quickly narrowing on a particular design and spinning into discussions on whether buttons should be on the left or on the right, LLM intricacies etc.

I’ve been using Claude Design for my front ends. The output looks and feels good enough, but the designs often look very similar and generally adhere to contemporary web tropes.

Keen to hear if anyone has had unconventional creative adventures with it.

> Claude gave me free, unlimited iteration, unbothered when I changed my mind for the 50th time or asked for a small tweak

Do you not pay for Claude?

The benefit here is designers learning to code. It was always weird to me that designers were shaping software without knowing how it was built. I'm a designer btw.

However, designing in code is technology-first. One could argue that the purpose of design - to shape the artifacts for human purpose - is better done NOT starting with the strict rules of code. Pen and paper is still hard to beat, not for anything that looks nice, but for helping your mind forward.

> 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

I some times notice this. the LLM cant see past the interation so I have to think outside the box and say, what if we look at it from this perspective, and suddenly a new way of designing it comes into existance. Somes times I have to create a flow chart to get the LLM to see past its own progression steps.

>>> 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

That’s solves an issue I have with all POC - a really good approach

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 edge cases.

Figma is still my preferred canvas. Figjam is still great for rough wireframes, flows, and agreeing on data models with my eng counterparts.

But Claude accelerates the divergent early stage 'exploration' work. Unfortunately we don't take the time to properly validate the concepts with customers. Again in the name of 'moving fast'. They will learn eventually I guess.

I'm getting off-topic. Claude is super helpful. As time passes I'm doing more and more work with it. But sometimes taking my design system and pushing pixels is genuinely faster when there is an obvious solution, opposed to ensuring Claude has all the right context to solve a relatively simple problem.

All depends on what I'm working on really.

Claude Design is great because I always knew what I needed UX designers to do. A software engineer can pick up frontend UX concepts really easily, but it's just still a full time job to keep up, iterate, do states.

I've worked with graphic designers, whether its 1 person on a team, or a group, or a division, and had the back and forth for years. I've also contracted with many graphic designers to polish my own applications as well as promotional materials. I've contracted with agencies, I know what a style guide looks like, a press kit, a design library shared between applications and departments needs to have.

Now it's not a full time job. Its 3 tabs for different user flows in the application.

And on the flip side, designers can also deploy software now that's good enough - (I feel like I can deploy more efficient software than an AI will initially suggest, and do things that stay on free tiers for far longer than anyone just going along with AI's suggestions.)

We are doing this on my team (I am the frontend engineer) and honestly I really miss the old way of doing things.

Written specifications are being reduced in favor of these working prototypes, and now there’s this extra cognitive burden of reading the code and trying to determine what were the intended changes, and what’s the slop that needs to be tossed aside.

We also have to figure out, should we take over this generated PR and make any needed changes? Or do we start over from scratch? There’s often a sense of friction either way.

There have been times where a bunch of unintended changes were generated and I took time to port them over on my reimplementation, and then later on it’s “oops! Sorry! We didn’t mean to change that.”

I get it’s empowering but it does take away from some of the joy I used to find in my work and replaced it with some headaches.

I use the same approach a lot. Before AI I also did this manually. First sit down with a user and just paper and pencil, then hack together a frontend POC / demo, have them play with it and adjust until it works as they wanted.

For me building a quick (not production quality) frontend demo in code was already often faster than getting the right interaction working in Figma. And it allowed to make it fully interactive so you can catch much more edge cases on the UX side.

Now with Claude Code it's even faster to build the throw away prototype. But not a huge difference since discussing with the users and thinking about how it should work is 80% of the time. Claude maybe halves the other 20% compared to quickly doing it yourself. Faster to first version, slower to iterate if it didn't fully get it.

Even for the large products, figma is not the starting point for new concepts anymore. I start with a quick prototype on dev environment and then share it with designer for further improvements in figma or in the app itself. With every new model or agent improvement, going back to figma for polishing the ui is decllinig. If we can find a way to keep the frontend code static templates without complex logic, need for this polishing in figma will go away completey as llms can understand it one context window. With the modern frameworks designed for client side rendering, keeping everything in one context is still tricky.
You should note that Claude Design is most likely a DPO->PPO->Actor-Critic bootstrap play: https://arxiv.org/abs/2305.18290 / https://en.wikipedia.org/wiki/Proximal_policy_optimization / https://spinningup.openai.com/en/latest/algorithms/sac.html

It's much harder to RL out design taste because it's not self-grounding, and human labelers have no real skin in the game, so this (having a human with a vested outcome in the process directing a model's work) is the best way to get LLMs better at design/"taste"/aesthetic judgment themselves. We were working on the same thing 7 months ago and then I realized that winning over designers to do this would be a huge uphill battle setting up an inevitable fall from grace later on.

What makes me most suspicious of Claude Design is that when you disconnect and reconnect later, it loses context and nags you that the product doesn't work like that. Bullshit. It's at best an anti-abuse/implementation detail (to keep you from launching 10 at once and coming back to them later) or product shortcoming that just so happens to be optimized for keeping you from continuing your design in better tools than theirs for the inevitable followups.

It's great for one shots and it makes sense when you're trying to build a vertical product development stack like Anthropic but I'm disappointed it feels more like a tool optimized for keeping you in their product than for what you're working on. If a company other than Anthropic had shipped this - it's not that hard to build a visual self-eval loop, just use Chrome Devtools Protocol to run headless chrome and take screenshots -> feed into a judge LLM for feedback -> continue - I don't think it would really have seen much adoption.

That said, AI trained on Actor-Critic with a tight human feedback loop definitely seems like the right approach to solving the problem, just not something I want to spend my time training for someone else unless I can do so with higher "entropy" ie high parallelism/optionality

Hey Edwin. Glad to see your post pop up. I remember doing a hackathon with you back in like 2012/2013.

I think the ability to get to a working prototype faster is very empowering, even if some will be tempted to ship these incomplete ideas. Design and UX needs benefits greatly from being able to play with it, and experience the actual flows beyond just a storyboard and wireframes.

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 communicates with the browser via websocket flawlessly. To use our max subscription after [1] takes effect, we are considering adapting that setup to an approach like [2] instead.

[1] https://x.com/ClaudeDevs/status/2054610152817619388

[2] https://lanes.sh/blog/claude-billing-split

At work we are now in the process of migrating away from Figma. We had spend years perfecting our Figma based design workflow. Currently we are moving all the designs into the code itself using Storybook. The gap currently is reviews and feedback which is addressed by Chromatic now.
Sounds like desk strat RAD work is moving to LLM gen code at JS. My recentish experience of that kind of work has been Athena at JPMC and Quartz at BoA; both Python with functional style via DAG or pixie with py ui framework to match. Which enables quick dev of the parts of trading workflow that don't need to be quick, like booking tools or EOD risk. I know first hand Athena and Qz are crufty when you get into the weeds. The bonsai framework with Elm inspired ocaml impl sounds v cool. So I can see how this approach can accelerate a lot of trading tech dev. But does it have any traction over the hard problems where we turn to C++ or Rust: near real pricing and risk across multiple instruments and markets?
Figma make and gpt designer have a bunch of catching up to do. I couldn’t even import our brand guidelines into make which is already a .fig like what are we even doing here, guys? CD crunches through ungodly amount of tokens and is really slow on iteration but at least you can get some really nice prototypes extremely quickly there. GPT beats any Anthropic models on illustrations so they really should get a grip on multimodal. Overall, it seems like we’re still super early but you can already see glimpses of what may come
amyone know how to use claude design more effectively I always alhave a feeling I use a slot machine

from 6 sessions and 5 projects only one template that I choose anything else is really really bad

I worry about Figma stock, I know some who bought during the IPO who are now underwater. Figma launched their own design agent but not sure how well that's doing.
Same here. I mostly use Figma for logos and random assets now.
Claude is pretty great at designing certain images. For favicons, logos, og cards, it does extremely well. For full image generation, I go elsewhere.
i gave claude code my design system that i built in figma and haven't opened it again. it's much faster designing with your voice.
> workflow improvements that would have taken days or weeks of engineering

It's a nice article and good point but I feel "design" in the title is misleading - the example given has an extremely reduced visual or spatial scope (something models are still not good at). The post is more about rapid prototyping.

Honestly, I'm not really pro or anti llm and I think there are a ton of limitations for using it to generate code, but UI has been probably the only thing I've been able to vibe code. It helps that I've done a lot of UI work over the years, but I think the combination of defects being easily visible through normal usage, the UI being a non-critical component of a system (bugs don't cause vulns or data corruption (usually), combined with the amount of churn that UI's see, make it a somewhat uniquely good candidate for vibe coding. Also a lot of UI toolkits are declarative, and I think language models do much better with declarative code.

In a way it's not much different from copy-pasting components from templates or whatever, just with more customisability. And for stuff that isn't HTML-based like React it does worse. It's also not great at building component libraries, I still write those myself with little LLM involvement, but that makes sense because the architecture is actually relevant with that, unlike generating CSS and xml-derived components, which is mostly just declarative templating anyways.

I've had decent success writing the core logic myself and then delegating the UI to AI. I think if I didn't write the core logic it would not work very well, but since it's designed well by myself the AI has a much smaller scope to work in which constrains it enough where vibe coding works. Pretty cool.

Even if this is ad only - are we really ready for a rug pull from Anthropic? Maybe I’m completely unaware in this tools space, but I feel like it’s last tool that’s worth (and not pricey)…
Is it just me or the bar to publish janestreet blogposts has been lowered recently?
For design tools and website builders tough times ahead. Wix for example lay down 20% of staff in some countries. All due to “optimization” with LLM.

Klankers will fix everything. Right?

I'm my work as an FDE this week, Copilot did the initial UI. Feedback was given and tells were adjusted all through prompting.
I don't see how a coding model competes with figma TBH, an image model maybe but that's a stretch too.
I still prefer Figma for collaboration
And how much of these designs are used in the end compared to when they where done with Figma?
I use Claude code a lot for design too but it just does a lot of regurgitation in design too
> 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.

Using AI for things you aren't good at, or not experienced with, is literally the worst way to use AI. You WANT to struggle when learning a new language, and use reliable documentation to solve your problems, not circumvent them entirely by using AI.

This is extreme incompetence, I'm shocked that Jane Street would advertise it.

Yea I mean okay JaneStreet. World wide renowned to be a tech design powerhouse...
You aren't designing.
> Submit a feature (our version of a pull request) that looks and behaves exactly the way I want

What happens after the submission? Who reviews the feature? How long? Are there any limits to the size of the diff? Do reviewers push back? How often are features submitted?

"i design with claude" no, you don't
" At present, there are no other major purchasers of AI compute outside of NVIDIA, hyperscalers (who are selling it to Anthropic and OpenAI, or they’re Meta, which has no AI strategy), OpenAI, and Anthropic. None. I can’t find a single one outside of Jane Street spending more than a few hundred million. We need a few hundred billion. " https://www.wheresyoured.at/ai-is-slowing-down/

The one non-circular-financing entity that is heavily spending on AI, is interested in you knowing how wisely they think they are spending their money.

Jane Street isn't one to telegraph their moves (seems like they prefer to Telegram them privately https://protos.com/what-weve-learned-from-terraform-labs-unr... , so not only Jump Crypto felt fine letting everyone believe the ponzi, per these allegations it seems Jane Street did too). If Jane Street is spending the most, and their staff is supposedly high value pay/profit but low headcount, for all the end user knows, their "AI agent" is half chat bot / half software engineer with 20 years experience who checks each result before sending it. Literally the Mechanical Turk scam of hundreds of years ago, where a midget hides in the stand and moves the chess pieces--with shades of Amazon Fresh self checkout. Maybe the higher ups at Jane Street know this, maybe not. But unless they have a closed system that Anthropic can't get into, I would be suspicious. And, of course, they aren't /that/ free from the circular financing because they are a major investor of Anthropic. To me the fact that the blog post doesn't start with a disclosure doesn't seem like a misstep/accident. And if they find out they are being Mechanical-Turked, I think it far more likely they'll find some way of shorting before telling anyone, or they won't tell anyone.