logoalt Hacker News

nkorenyesterday at 12:35 PM3 repliesview on HN

As someone who does both development and design, I agree. With some caveats.

At this point, Claude now writes > 99% of my code. I wasn't an enthusiastic early adopter; it took me a while to be willing to let go of the reins. But in tandem with LLMs getting better, I also began to realize that what happens inside the code is very rarely important enough for me to care about. Like, I care that it's secure, and performant where it needs to be, etc. -- but mostly I just care about its outputs. If it does what I want it to do, then how it does this doesn't really matter to me or my clients or my users. On the development side, my attention has focused to writing specifications and monitoring the correctness of the test suite, and > 99% of the time that's good enough. It's been a lesson in non-attachment to let go of lovingly crafting every single line of code, but the tradeoff in terms of productivity has absolutely been worth it.

What makes this viable is the fact that there's essentially a "hidden layer" (the code) upon which Claude can operate. My clients don't actually care about the code, and within certain bounds (correctness, security, performance, extensibility, etc.) it turns out that neither do I. This gives Claude a lot of latitude to solve things in its own way, and I think that's a bit part of its effectiveness.

On the other hand, with design there is no hidden layer. Every single aspect of the design is visible to the user and the customer. So the design reflects upon my work in ways that code does not. This means that the conditions which allow me to relax my grip on coding just don't exist for design. It's very difficult for me to imagine delegating design in the same way that I've become comfortable delegating coding.

That said: I suspect that the use-case for Claude Design will be for applications which today receive very little design attention. There are loads of applications where design is less than an afterthought, and the product suffers terribly for it. Delegating to Claude, in those contexts, would likely be a very big win. But for applications which already have designers obsessing over every pixel, I see a very limited role for this. Figma's market is mostly the latter -- the former, by definition, is not part of the market for design tools -- so I don't see them being threatened by this for a long time.


Replies

Eridrusyesterday at 10:13 PM

As a person doing design, yes, you feel like you cannot let go.

But as a person employing designers, I have already accepted that I will let go.

We did a marketing website redesign for our b2b saas product with a 3rd party design firm, we gave a lot of input, but the thing isn't perfect, at some point we had to call it done. It was still a significant improvement over what we previously had, but I am under no illusions that it is a masterpiece.

Now, coding tools do have some clear shortcomings for design atm, but how long they will be like that is not clear.

hedgehogtoday at 5:02 AM

Similar path, I was very skeptical but Claude touches over 90% of my code now. I review almost all of it though. I did not have high expectations for Claude Design but yesterday I tried it for a workflow tool I'm building and in one shot it made something much better suited than standard component libraries. Some more back and forth interspersed with errands etc used up my CD quota, and the result looks better than most of the software I use (it helps that I value information density and clear affordances for interactivity). I haven't tried applying the design to the existing code yet.

petrayesterday at 1:44 PM

Are there goals for an app design? can they be measured? specified? constrained?

For example, in the world of e-commerce, one goal is improving conversion rate, as long as we get that and the design looks nice, that's OK.

show 1 reply