Late last year, I built my entire personal website from scratch using Cursor plus Claude. The Hugo framework, multilingual support, automatic translation, GitHub Actions CI/CD, real-time Fitbit data integration—the whole architecture, from concept to launch, in under two weeks.

▶ Listen to summary
AI-synthesized voice, cloned from the author's own voice

Three years ago, the same thing would have taken me roughly three months, and I’d have had to outsource part of it.

But one thing didn’t get faster: deciding what this website “should look like.”

Not the question of visual design. A more fundamental one—who is this website for? What should it convey? Which features are core and which are distractions? How many thematic pillars should the articles be divided into? What is the relationship between each pillar? After a reader finishes an article, where should they be guided next?

AI can’t answer a single one of these. Not because it isn’t smart enough, but because the answers depend on “who I am” and “what I believe matters.” That is taste.

Taste Isn’t What You Think It Is

The word “taste” carries a sense of elitism, as if it’s saying “I understand wine, you don’t.” But the taste I want to discuss has nothing to do with elitism.

Steve Jobs said something that’s been quoted to death: “Design is not just what it looks like and feels like. Design is how it works.” But his deeper meaning was this: most people think designers make things pretty, but real designers know their job is to make things right.

“Making things right”—that’s the essence of taste.

More concretely, taste is the intersection of three abilities: discernment (seeing which option among many is the right one), the power of negation (the courage to say “we won’t do this”), and a sense of context (understanding why, in this particular situation, this choice is the right one).

Discernment can be accumulated through experience. The power of negation requires courage and judgment. But the sense of context is the hardest—it requires you to simultaneously understand technical constraints, user needs, business logic, and cultural background, and then find the optimal solution at the intersection of these dimensions.

AI is already strong on discernment. Give it ten design options and it can score and rank them according to design principles. But the power of negation and the sense of context? It can’t even see the problem. Because it doesn’t know what the “right” choice is for you, at this point in time, facing this group of people, carrying these resource constraints.

How My Taste Was Trained

Honestly, I’m not someone with innate taste. My taste was forged by falling into pits.

In my years as a consultant, I saw too many products that were “technically perfect but commercially meaningless.” A team would spend half a year polishing a feature, only to find after launch that users didn’t care at all. The problem wasn’t technical execution; it was that the right question was never asked at the start: “Whose pain point, exactly, does this feature solve?”

Later, working in the circular economy, I learned another layer of taste: a sense of fit. The same metal-recycling technology could be a revolutionary improvement on Factory A’s production line and a superfluous complication at Factory B. The difference wasn’t in the technology itself, but in whether you could judge “whether this solution suits this scenario.”

This connects unexpectedly with my experience of theological training. Fifteen years of theological background taught me one thing: the same passage of scripture can carry entirely different meanings in different contexts, and the quality of interpretation depends on the depth of your understanding of context. This “context sensitivity” later became the underlying ability behind all my judgments—whether choosing a technical architecture, setting content strategy, or deciding the angle of an article.

Now, building systems with AI, I find the value of taste has become more evident, not less important.

Here’s a concrete example. When building the debate engine, there were infinite ways to design it technically: How many models? How many rounds of dialogue? Add fact-checking or not? At which stage does checking go? Which model does the checking? Every choice is viable, and AI can implement any of them. But the architectural decision—“four models, dual debate-and-collaboration modes, Perplexity for the final fact-check”—was a comprehensive judgment I arrived at based on dozens of past experiments, my understanding of different models’ personalities, and the kind of output quality I wanted.

AI wrote every line of code in the engine. But what the engine “should look like” was decided by taste.

What Vibe Coding Really Means

Many people understand Vibe Coding as “you don’t need to seriously write code anymore, just chat with AI.” This understanding is wildly off.

The real meaning of Vibe Coding is this: when the cost of execution is driven to near zero, the quality of decisions becomes the only differentiating factor.

In “Code is Cheap: From Vibe Coding to CLAWS” I analyzed this phase transition in cost structure in detail. But that piece discussed the macro trend—from Karpathy’s evolving terminology to Willison’s manifesto. Here I want to discuss the micro, personal level: when you’re actually sitting in front of Cursor, building something alongside AI, what exactly determines whether the result is good or bad?

The answer is the quality of your instructions. And the quality of instructions depends on the depth of your understanding of the problem.

When I describe requirements to AI in natural language, I’ve noticed an interesting phenomenon: the more precisely I describe, the better AI’s output; but true precision isn’t precision of technical specifications, it’s precision of intent. “Write me an API endpoint that receives scheduling data in JSON format, validates the fields, and stores it in the database”—this is precision of technical specification, and AI can execute it perfectly. But “the goal of this scheduling system is to let one person manage posting across eight social platforms; the most important thing is not making mistakes, and flexibility is only secondary”—this is precision of intent, and it determines the direction of the entire system architecture.

The former is engineering ability. The latter is taste.

Why the Humanities Suddenly Became Important

Here’s something I’ve observed: the people who perform best in collaboration with AI are often not the most technically skilled, but those who can “articulate their ideas clearly.”

This sounds simple, but “articulating clearly” is actually an extremely complex ability. It requires you to first think clearly about what you want (self-awareness), then express it in a way the other party can understand (communication ability), while anticipating where they might misunderstand and clarifying in advance (empathy), and finally identifying within their response which parts are right and which need correction (critical thinking).

These four abilities—self-awareness, communication, empathy, critical thinking—are all at the core of humanities training. Rhetoric teaches you how to express precisely. Philosophy teaches you how to deconstruct problems. Literature teaches you how to understand context. History teaches you how to distill judgment from cases.

In my own experience, theological training has helped my collaboration with AI far more than any programming language. Because the core training of theology is precisely this: facing a complex text, finding the most reasonable, most responsible interpretation among multiple possibilities. This is, in essence, the same thing you need to do when facing AI’s output.

This is also why I believe the “post-code era” is not the end of engineers but a renaissance of the humanities.

Can Taste Be Cultivated?

Yes. But not by “taking a course in taste.”

Taste comes from three sources: abundant input (seeing enough good and bad things), cross-domain connections (finding a common framework of judgment across experiences in different fields), and repeated practice and feedback (making choices, bearing the consequences, correcting your judgment).

Dieter Rams’s ten commandments of design are classic not because he innately knew what good design was, but because he spent decades doing product design at Braun, distilling those principles from countless attempts and failures.

For me, cultivating taste has a very concrete method: deliberately practicing “why not to do it.” Every time you make a decision, record not only what you chose but also what you gave up and why. Over time, you’ll find your framework of judgment becoming increasingly clear.

That’s exactly what I did running my personal website. Before writing each article, I’d first list three to five possible angles, then eliminate them one by one until only the most valuable one remained. The eliminated angles weren’t bad; they just weren’t the most “right” choice at this point in time, for this group of readers, within the context of existing articles.

This process is the muscle memory of taste.

The Last Irreplaceability

In “AI Agents vs. Agentic AI” I discussed how, in the era of agentic AI, the core ability isn’t operating AI but designing the architecture of human-machine collaboration. In “When Language Is Abandoned” I discussed how, if AI’s thinking process departs from human language, the mechanisms of oversight fundamentally fail.

The intersection of these two issues is taste.

Taste determines what you have AI do (architectural design). Taste also determines how you judge whether AI’s output is up to standard (the ability to supervise). As AI grows more powerful and more autonomous, taste is humanity’s last line of defense for retaining a stake in participation.

Not because AI has no taste—but because the essence of taste is “judging what is right within a specific context,” and context is always defined by humans. Who your users are, how many resources you have, what your cultural background is, what you believe matters—these constitute the coordinate system of taste’s judgment. AI can optimize within the coordinate system you define, but it cannot define the coordinate system itself for you.

Code can be copied. Models can be trained. But what you choose to build, what you give up, and why—that, only you can answer.