#161 700 Components in One Day: How Design Work Is Quietly Moving Into Code

And before we go back to my client's story, I need to zoom out for a second because the story did not happen in a vacuum.

Do you remember the should designers code debate? Uh, I mean, of course you do, because [laughs] I really like to say that this is the cockroach of design discourse.

It survives everything.

Every, every year, someone writes a blog post, a LinkedIn article, uh, uh, about this topic, then there's a counter post, and we all argue on LinkedIn for a week, and then we go back to work, and nothing really changes.

Well, here's the uncomfortable news.

That debate is over.

It ended in the last 12 months, and here's the twist.

We didn't end it.

There was no community consensus.

No design leader stood up at a conference and said, "Okay, uh, everyone, we decided." But the job market ended it.

Smashing Magazine published a piece this spring that put it perfectly, I would say.

The debate wasn't settled through consensus of our craft.

It was settled through the brute force of job requirements.

Go browse job postings today.

Seriously, do it after this episode.

You will see things that would have been unthinkable in a UX job description three years ago.

For example, AI-augmented development or production-ready prototyping or, um, comfortable working with coding agents, or rec- recruiters are not only looking for someone who understands user research and information architecture anymore.

They want someone who can prompt a React component into existence and then push it to a repo.

And I want to name what's actually happening underneath that because I think, I think it really gets misdiagnosed.

This is not really about skills.

Designers can learn tools.

You know, we always have.

We survived the death of Photoshop for UI.

We survived Sketch.

We survived the great Figma migration.