I’d love to see this experiment executed with Claude design.
Particularly with something static, I don’t think they’d fail to get a result.
But without domain knowledge I think they’d misunderstand prototype with finished product.
Without knowing what it’s doing, it’s hard to know what it’s not doing.
As decades-exp SWE I love using Claude Design for any kind of app and web development, because it gives much faster visual feedback loop than changing views within deep framework stack. It much easier to "tell" coding agent what I need instead of writing wall of prose to define visual stuff.
I reminds me old WYSIWYG and unlike Figma it has full HTML/CSS capabilities available.
How I work with it:
- I ask agent to extract part of app into Design, let it even use playwright-cli to get full rendering of the particular view.
- perform design session in Design.
- once design system is perfected I go down to Claude Code dungeons, do /design-sync.
- perform on the stack implementation session.
Actually you don't need Claude Design UI for any of that too. Just ask any coding agent to prepare local mock HTMLs and iterate over them.
I’ve been curious on how to close this loop between engineering and design/product.
We don’t use react, which Claude design seems to trend towards. We use Phoenix / liveview.
We have a shared design system, which keeps the visual elements in line. And then just prototype on design, collab, discuss and arrive at what we want to ship. And then engineering take over and rebuild via hand / claude code.
But the tools aren’t directly connected.
The value has been in the separation. In iterating on the prototype without impacting the codebase, dev cycle, etc. And solving problems/unknowns earlier.
There were always tools for this, but Claude design just feels more accessible and therefore gets used more immediately.
And the fidelity of the outcome (and the assumptions it’s forced the make) are more valuable and faster to achieve than Figma.
I think the way humans divide up design and programming are broadly correct. Working that way with LLMs seems to work well.
I vibe coded an iOS conference schedule app recently, built on top of my own rust UI framework. I started with claude design. I gave it the requirements, and showed it screenshots of other conference schedule apps I like which have features I want to use. I also gave it some visual references for how I want the app styled. It came up with some workable designs. They were a bit 'webby'. But, fine. The high level breakdown of UI screens and navigation between them was excellent.
Then I gave all the HTML files it produced to claude code, along with the documentation for my UI framework and told it to port the code to my UI framework. The first working version was rough. It copied a lot of the unintentional webby look and feel. It worked around missing features in my UI framework by rolling its own janky reimplementations of platform features. For example, instead of using UINavigationController, it rolled its own. It made its own (kinda bad) tab based navigation bar. The app didn't work properly in dark mode, because it was hard-coding a lot of colours. It took a bit of back and forth to fix all of this stuff. But I'm really happy with it now. It looks and feels great.
It's just a pity I couldn't share the app at the conference. Apple took a few days to approve the app in Testflight, and by the time they approved it, the conference was over.
I assume everyone else is playing with the same AI tools that I am, and getting similar results. But a lot of people I talk to seem to have no idea that this is possible right now. They're amazed when I show them my schedule app.
My non-technical cofounder managed to vibe code a holding page with Claude Design and it walked him through deploying it to Netlify.
However for some reason it had him deploy a single HTML file with all the assets encoded as a huge base64 blob in the code that required a massive amount of JavaScript to extract and render.
It's been doing this for our non-technical folk. Giving users a gigantic single file for deployment. We saw one user deploy a JS file with around 3K-5K elements in an array, storing unique IDs of items they wanted to list.
Welcome to Software Development, Lindsey from HR - here's your first database!
People just don't really understand how these things work yet, and they don't know what to ask for, I'm hopeful that they eventually do become more tech-literate, but not sure yet.
Interesting.
I often ask it export a single html file, for an external collaborator or simpler sharing. But I wouldn’t deploy that to production.
I wonder if they asked it to deploy a html file.
But this is exactly the kind of hidden domain knowledge / expertise that changes how you use the tool.
> Particularly with something static
Apps ain’t static.
They probably mean static site, in the sense of static front end, no backend.
Yes. That's not an app.
It could be an app.
Minesweeper is an app right? Unit conversion? Color palette designer? Metronome?
The person you responded too didn't mention app though. They just said static. OP was talking about an app but the responded was hypothesizing about something static.
Anyway I'm not so sure "static" is a viable boundary between app and not app. A static page that does any sort of API request doesn't suddenly become an app imo.
Not really, is a offline chess page not an app? It seems like it would be closer to an app.
What does this hypothetical chess page do? And how’s does it do it if it is static?
You misunderstand the meaning of static web pages. Here's a short explanation of the terms: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
It uses javascript. Still a static file. Lets you play chess
Don’t you update the DOM to render the pieces as they’re moved?
A static website is one that doesn’t have an associated backend API server, just serves as one or more self contained file assets.
The files you serve to the browser are static, not the contents of the page itself
Updating the dom can happen with only individual assets, so it’s a static site
when someone describes a static site/app they generally mean there is no backend. not that the frontend is a static image
for example you can service static sites from S3 that have HTML/CSS/JS but no API or DB