When code is cheap, taste is the edge

A few years ago, getting a working app built took real money and real time. You needed a developer, a few months, and a budget that made you think hard about whether the idea was worth it.

That’s mostly gone. Describe what you want to an AI tool, and you can have something that works by the weekend. I’ve watched friends do it. I do it myself every day.

When anyone can make software that works, working isn’t enough to stand out anymore. It’s the minimum. What’s left is how it feels to use: whether it’s clear, whether it respects your time, and whether it was obviously built by someone who understood you.

The big names are saying it too

I’m not the first person to notice this, and it’s been one of the loudest conversations in tech this year.

In February, Paul Graham posted that taste will matter more in the age of AI, and pointed back to Taste for Makers, an essay he wrote in 2002. OpenAI’s Greg Brockman called taste a new core skill the same week, and the debate took over tech Twitter for a few days.

Figma’s CEO Dylan Field has been making the same case for a while. On Lenny’s Podcast he argued that as AI makes software faster and easier to build, design, craft, and quality become the new moat. His point is simple: “good enough” software stops winning once everyone can make good enough software.

Not everyone’s convinced. Kyle Chayka at The New Yorker poked at the sudden enthusiasm for a word nobody in tech could quite define. Others pointed out that if AI can build an app in a weekend, it can copy your nice-looking app in a weekend too.

I think the skeptics have a point, and it’s worth taking seriously.

Taste without a user is just preference

“Taste” is a slippery word. It can sound like having opinions about fonts, or knowing which shade of gray is in this year. If that’s all it means, the skeptics are right. A polished look is easy to copy, and AI is getting good at producing one.

When I talk about taste in software, I mean something more specific: understanding the person on the other side of the screen well enough to make good decisions for them. That’s user experience, or UX. The visual polish is the smallest part of it.

A recent example: a friend built a life assessment app with AI over a weekend, and I spent an afternoon polishing it. The biggest improvement had nothing to do with fonts or colors. It came from picturing how the app was actually used: ten people in a living room, one TV, one person driving and everyone else trying to find their own score. The app had no screen for that moment, so I built one.

No AI tool suggested that screen. It couldn’t have, because it had never been in that room.

AI aims for the average

This is why I think UX matters more now. AI tools are trained on an enormous amount of existing software, and they’re very good at producing the most typical version of whatever you ask for. Ask for a dashboard and you get the average dashboard. It works, and it looks like every other dashboard.

That’s often fine. But your customers aren’t average. They’re a property manager checking numbers between showings, or a bakery owner updating the menu at 5 a.m., or a retreat leader trying to keep a room’s attention. The average dashboard doesn’t know any of that.

The tool can write the code. It can’t tell you who you’re writing it for. That still takes a person who has watched people use software, noticed where they get stuck, and cares enough to fix it.

What actually can’t be copied

Here’s where I land on the “taste isn’t a moat” argument.

A competitor can copy your screens. What they can’t copy is the hundred small decisions behind them, and the reasons for each one. Why this button and not three. Why the error message says exactly which field is wrong. Why there’s no settings page at all. Those decisions come from time spent with real users, and they keep stacking up. By the time someone copies what you shipped, you already know what to change next.

In my experience, a lot of good UX is deciding what to leave out. In that same afternoon project, I almost added more stats next to the group’s median. I left them off because the chart already said enough, and more numbers would have competed with it. A screenshot shows what’s there. It doesn’t show what was cut, or why.

What this looks like in practice

You don’t need a design degree to start. A few habits get you most of the way:

• Watch someone use it. Five minutes of watching a real person use your tool will teach you more than a week of guessing. Don’t help them. Just notice where they pause.
• Ask what each screen is for. Every screen should have one obvious next step. If you can’t name it, neither can your users.
• Fix the boring stuff. Low-contrast text, inconsistent spacing, vague error messages. None of these are bugs, so AI rarely flags them, but together they make an app feel slightly off.
• Test with real data on real devices. A design that looks great with tidy sample data on a big monitor can fall apart with messy real answers on a phone.
• Let AI do the typing, and keep the judgment yourself. Use the tools to build fast, and spend the time you save on understanding the people who will use what you build.

Why I’m betting on this

I’ve spent about 15 years in design and development, and for most of that time, the hard part of a project was getting it built. Now the code is the fast part. The slow, valuable part is the same as it ever was: understanding people.

That’s the work we care about most at Medeski Solutions. We use AI every day to build quickly, and we put the time it saves into making sure what we build fits the people using it.

If you have software that works but doesn’t feel right, or an idea you want to get right the first time, let’s talk.