Taste Is the New 10x: What Software Architecture and an Ambient Record Taught Me About Choosing What to Build

What does "taste is the new 10x" actually mean?#

It means the scarce skill in 2026 is no longer typing code fast. When an AI agent can generate a working implementation of almost anything on demand, the leverage moves to judgment: choosing what to build, deciding what to leave out, and recognizing the moment the output is technically correct but wrong. Taste is that judgment, and it now separates good engineers from great ones more than raw output ever did.

I want to be precise about where I'm standing. I was a senior engineer for years before any of this tooling existed. I shipped native iOS and Android, Flutter, Rust, and web. I also produce ambient music under the name Ancient Prayers, where the entire product is curation. So I've spent a long time in two fields that look unrelated but share one spine: the hard part was never making the thing. The hard part was knowing which thing was worth making, and knowing when what I made was off.

AI didn't invent that problem. It just stripped away everything that used to hide it.

The argument in five lines#

• Taste here means practiced judgment, not personal preference or visual polish.
• Cheap generation increases the number of plausible options; it does not choose which option belongs.
• In software, taste appears as fit, restraint, and attention to the failure mode outside the test.
• In ambient music, it appears as selection, space, dynamics, and knowing when to stop.
• Taste improves through close study, real consequences, explicit subtraction, and explaining your decisions.

The output has never been cheaper, and delivery hasn't moved#

Here is the tension that makes taste urgent rather than philosophical.

The 2025 DORA report gives the more useful framing. DORA describes AI as an amplifier of an organization's existing strengths and weaknesses and says the largest returns come from the underlying system, not the tool alone. Google's official report summary reports high adoption and self-reported productivity gains while emphasizing that local workflow and organizational conditions shape the result.

Those are survey and research findings about organizations, not proof that every team behaves the same way. My inference is narrower: producing another plausible diff is no longer the whole constraint. The expensive questions remain around it. Is this the right change? Does it fit the system? Will it still make sense in a year? Should it exist at all? AI can increase the supply of options without answering those questions.

The expensive part is taste.

Taste is cultivated judgment, not personal whim#

This is not a new idea, it just landed on a new decade.

Paul Graham argued the point in his 2002 essay "Taste for Makers": good design is not arbitrary preference but judgment that can be improved through close attention to good work. I do not need a newer quote from a technology executive to make the idea current. AI changes the volume and speed of available output; the old requirement to distinguish good work from merely finished work remains.

My own version is blunter: taste is compressed experience you can act on quickly. It's the thousand small judgments you've internalized so deeply that you no longer have to reason them out. And it only feels like intuition because the deliberation happened years ago.

Taste in software architecture: knowing when the code is wrong#

Watch what actually happens when I work with an agent now.

I can ask for a feature and get a complete, compiling, test-passing implementation in minutes. The code runs. And often my reaction is: no. Not because there's a bug. Because it's wrong in ways a test will never catch.

It introduced a new abstraction where the codebase already had a perfectly good pattern for this. It reached for a dependency I don't want to own. It solved the literal request instead of the actual problem, the one behind the request that I didn't phrase well. It made the easy 80% trivial and quietly ignored the 20% that was the entire reason the ticket existed. It's the kind of code that looks right in the diff and rots the system over six months.

Catching that is taste. Specifically it's a set of judgments that no amount of generation replaces:

• Does this belong? The best architectural decision is often to not add the thing. An agent will almost never tell you the feature shouldn't exist. That refusal is yours.
• Does it fit the grain of this system? Every codebase has a direction the wood runs. Code that fights it is a future migration even when it works today.
• Is the simplicity real or cosmetic? AI is very good at code that looks clean and hides its complexity one layer down. Knowing the difference is the job.
• What did it not do? The gap between the request and the real problem is where senior judgment lives, and it's exactly the gap agents fall into.

This is why I describe how I work as agentic engineering, not vibe coding. Vibe coding is accepting output because it runs. Agentic engineering is driving a system you're accountable for, using AI as fast hands while keeping the judgment on yourself. The agent proposes. Taste disposes. When output volume is nearly free, the entire value of an engineer concentrates into that second verb.

The DORA "amplifier" finding is the same point from the organizational side. My interpretation is that AI can help a team with strong judgment move faster and can magnify weak decisions when the underlying system is poor. That is an inference from the report's framing, not a measured law for every team.

For the engineering process behind that claim, see Agentic Engineering, Not Vibe Coding. The short version is that generation can be cheap only if the gate remains expensive.

Taste in ambient music: I literally sell curation#

Now the other field, because it taught me the same lesson without a single line of code.

As Ancient Prayers I make ambient and neoclassical music. And here's the thing nobody outside music production believes until they try it: generating sound has never been the constraint. I can produce more usable material in an afternoon than I could release in a year. A pad drifting under a felt piano, a field recording, a synth line, a reverb tail that hangs for eight seconds. Making more of it is trivial. It was trivial before AI touched audio and it's absurd now.

The product was never the sound. The product is the choosing.

Which four seconds of a ninety-second improvisation actually carry the feeling. Which track earns its place on the record and which one is just competent. When the reverb is one notch too wet and the whole thing tips from intimate into vague. When to stop adding, which in ambient is the entire craft, because the genre lives or dies on restraint. A listener can't articulate why one ambient record feels like a held breath and another feels like wallpaper. The difference is a producer's taste applied thousands of times across choices the listener never sees.

That is note-for-note the same skill as knowing an implementation is wrong when it compiles fine. Both are the ability to feel the gap between technically-fine and actually-right, and to act on it before anyone can explain it in words. In music I've been selling that gap for years. In software, AI just made it the main event.

The practical music boundary is in where AI belongs in my ambient workflow: generate a seed if it helps, then keep arrangement, mixing, mastering, and the final commitment human.

A five-question taste test#

"Use taste" is useless advice unless it changes a decision. Before I keep a feature, architecture, track, or mix choice, I ask:

1. What problem or feeling is this serving? If I cannot name it, the addition is probably decorating my uncertainty.
2. Does it fit the grain? In code, that means the existing boundaries. In music, it means the sonic and emotional language of the piece.
3. What cost appears later? Maintenance, another dependency, a crowded arrangement, a mix with no room left.
4. What can I remove and keep the point? Subtraction reveals whether the idea is carrying weight or hiding behind volume.
5. Would I still choose this if generation were slow? Cheap output can make a merely available option feel necessary.

The questions do not guarantee a good decision. They slow the point where convenience tries to impersonate judgment.

How you actually build taste (because it isn't mystical)#

The uncomfortable part of the "taste is the new 10x" claim is that taste is the one thing you can't prompt your way into. But it's not innate either. I built mine, in both fields, the same slow way.

• Consume the best deliberately. Graham's line is right: until you know what the best work in your field is and why it's the best, you don't know what you're aiming for. Read excellent codebases. Study records that move you and figure out mechanically what they're doing.
• Ship and get told you're wrong. Taste is calibrated by consequences. Code that broke in production, a track that sounded thin on a real system after sounding great in headphones. Each miss tightens the judgment.
• Practice saying no. The muscle that matters most is subtractive: cutting the feature, killing the track, deleting the clever abstraction. Volume is now free, so restraint is the scarce input.
• Slow down on the judgment even as you speed up the making. Let AI make the execution instant, then spend the time you saved deciding whether what it made deserves to exist.

My bet for 2026 and beyond: the engineers and makers who win won't be the ones who generate the most. Everyone can generate now. It'll be the ones who can look at infinite cheap output and reliably point at the small slice that's actually right. That pointing is taste, and it's the closest thing to a durable 10x left.

The machine will write the code. Deciding what's worth writing, and knowing the moment it's wrong, is still the job. It might be the only part that was ever really the job.