I want to add, a wise man once said "coherence is greater than consistency" and his initials were LW.. so what's the point of a design system then?

Ha, guilty. I did say you need coherent software design more than consistent software design. I've repeated some version of it enough times that I should probably get it on a t-shirt.

So what's a design system for? It gives a team a shared foundation (the typography, colors, spacing, and grid that underpin every layout) so people aren't reinventing a button every Tuesday. The consistency it provides is useful when it serves a purpose. As I put it years ago, consistency for consistency's sake is a no, consistency for predictability's sake is a yes. When the same control behaves the same way everywhere, people learn it once and move on.

Problems start when the system becomes the job. There are plenty of beautiful design systems attached to pretty terrible websites. Why? Shipping a good product takes a lot more: arguing with marketing over pop-up banners, fighting feature bloat, working with engineering on performance. Simply applying a style guide or components doesn't ensure your product works well, and done without much thought it can have the opposite effect.

Dan Mall made a good point here: most teams start with "let's make some components!" and skip the "for ____" part. What's the system for, and who is it for? That's also how I'd judge one. Design systems should be evaluated on how successful they make apps and their users, not how consistent they are.

What's got me excited lately is where this is heading. When you build with agents, you can encode the ethos of what you're making together, what good looks like, so coherence happens by default. The designer encodes the grids and typography, the developer encodes how code gets written and tested, and you can say "add this blog post to the site" and get something that works within the whole system. At that point the system is doing its real job, which is keeping everything coherent while you spend your time on the product.

So keep the design system, just treat it as infrastructure. The product people use every day is what you're actually shipping.