Rick Rubin told Anderson Cooper he has no technical ability. Doesn't play instruments. Can't work a mixing board. What he has is taste — the confidence to know what's right, what's off, and the ability to express the difference clearly enough that artists can act on it.

"I know what I like and what I don't like. And I'm decisive about what I like and what I don't like. The confidence that I have in my taste and my ability to express what I feel has proven helpful for artists."

That's the most accurate job description I've seen for what building software feels like right now.

The Gap That Used to Exist

For most of software's history, there was an expensive gap between vision and execution. You could see exactly what needed to exist — the architecture, the data model, the user experience — but building it required weeks of mechanical translation. Typing. Debugging. Fixing typos in boilerplate. Wrestling with frameworks.

The people with the best taste were often bottlenecked by implementation speed. And the fastest implementers didn't always have the best taste. The industry optimized for typing speed when it should have been optimizing for judgment.

Paul Graham wrote about this in Taste for Makers: the idea that good work requires aesthetic judgment, not just technical skill. The ability to look at something and know it's right. He was writing about design, but the same principle applies to software architecture, API design, data modeling — anywhere the shape of the solution matters as much as whether it compiles.

The gap between having taste and expressing it as working software — that gap is collapsing.

Specs as Expressed Taste

Last weekend I built an iOS accounting app. Twenty-nine data models, six engines, a full interface, over 900 tests. It took an afternoon. Not because I typed fast, but because I knew exactly what I wanted.

Every phase started with a task file. Not a vague prompt — a detailed spec. Which patterns to follow. Which conventions to enforce. What the tests should cover. What mistakes the previous phase revealed. What the commit message should say.

The spec is where taste lives. It's the decision that a tool-calling agent should stage mutations for user approval instead of writing directly to the database. It's the choice to model the context builder as thread-safe snapshots instead of passing live objects across actor boundaries. It's knowing that sequential phases with clean handoffs beat parallel execution on a shared codebase.

None of that is mechanical. All of it determines whether the software is good.

The agent handles the rest — the syntax, the boilerplate, the test assertions, the imports. The part that used to consume 90% of the time and 10% of the creative energy.

Vibe Speccing > Vibe Coding

There's a popular idea right now called "vibe coding" — prompting your way through an implementation, letting AI figure it out as you go. It's fun for demos. It doesn't produce software you can maintain.

What works is the opposite: vibe speccing. You spend 5x longer on the plan — the architecture, the test targets, the constraints, the failure modes — and then the build itself is almost mechanical. The code works when it's done because the spec already narrowed the solution space.

Think of TDD as a neural net for code. Each test is a constraint. Each constraint eliminates wrong paths. By the time you've written enough failing tests, the implementation is the path of least resistance. There's only one way the code can go, and it's the right way.

The discipline isn't in the typing. It's in the thinking that happens before anyone — or anything — writes a line of code.

The IDE Is Wherever You Are

I directed the entire agent UX build from my phone. Telegram messages. On the couch. Not at a desk, not in an IDE, not staring at a terminal.

The messages were short. "Go." "Looks good, go." "While that's building, let's write a blog post." AI agents spawned sub-agents, ran builds, committed code, reported back with test counts. Four phases of production-quality Swift — models, views, tests, integration — built and shipped while I typed with my thumbs.

This isn't a party trick. It's what happens when the work is the thinking. The spec doesn't care where it was written. A detailed task file composed on a phone carries the same information as one written in a code editor. The judgment is identical either way.

The laptop isn't the tool anymore. Your judgment is.

What You Do While the Agents Work

This is the part nobody talks about yet: what happens to your time when execution is delegated?

You get it back. Not as idle time — as creative time. While one build runs, you're thinking about the next architectural decision. Or you're writing. Or you're having a strategic conversation. Or you're developing taste in an adjacent domain.

The people who will build the best software aren't going to be the ones watching build logs. They're going to be the ones who use the space between builds to get better at the thing AI can't do — developing judgment about what should exist and why.

Read more. Talk to users. Study other industries. Understand the domain deeply enough that your specs carry the weight of real experience. The mechanical work is handled. The question is what you do with the time that frees up.

Rick Rubin spends his days listening, meditating, surfing. Not because he's lazy — because that's where taste comes from. The creative work isn't the studio session. It's everything that informs what happens in the studio.

The spec is the work. Everything else is execution. And the best specs come from people who spend their freed-up time getting better at seeing what others don't.