Vkus v programovaní: Prečo je to najdôležitejšia zručnosť éry AIProgramming Taste: Why It Is the Most Important Skill of the AI Era

When AI writes code for you, the most important skill is no longer how fast you can type syntactically correct lines. The decisive skill is whether you can recognize what is worth building, what will survive contact with reality, and what is merely a quick prototype dressed up as a product.

“In the end, it comes down to taste. It comes down to trying to expose yourself to the best things humans have done and then trying to bring those things into what you are doing.” — Steve Jobs

When AI writes code for you

In 2026, AI writes a significant share of new code. Developers use tools such as Cursor, Claude Code, and GitHub Copilot every day, and programming is shifting from a process of creation to a process of direction. That is not cosmetic. It changes what it means to be a good developer.

When code generation becomes a commodity, the decisive question is no longer how fast you can write. It is what you want to write and why. In other words, your taste becomes critical.

The question is no longer simply “can you code?” It is: can you recognize a good solution from one that merely looks finished?

What is programming taste?

Taste is not an aesthetic whim. It is trained judgment: the ability to recognize what will work over time, what will be maintainable, what solves the right problem, and what is only a cheap solution wrapped in attractive code.

Sean Goedecke puts it clearly: technical taste is different from technical skill. You can be technically strong and have poor taste. You can also be technically weaker and have excellent judgment about which engineering values fit a specific project.

In practice, taste shows up like this:

• Problem selection knowing what is worth building at all
• Tool selection knowing which language, framework, or architecture fits the context
• Solution logic building code that is efficient, extensible, and scalable
• End-user experience — wrapping logic in an interface that is intuitive and enjoyable to use
• Courage to simplify removing a feature, abstraction, or layer that does not make the product better

Linus Torvalds: good code as a change of perspective

If you want to see taste in action, look at Linus Torvalds’ well-known example from his 2016 TED interview.

Torvalds showed two implementations of deleting an item from a linked list. Both were technically correct. Both worked. But one solution tested an extra condition, had higher cyclomatic complexity, and required special handling for the first item in the list. The other removed that special case by changing the angle from which the problem was viewed.

This is the essence of taste: not merely finding a solution, but finding the perspective from which the problem stops being complicated.

Good code is not good because it is short. It is good because it removes unnecessary decision-making. When the design is right, exceptions disappear, system boundaries become readable, and the next developer does not have to guess what you meant.

Paul Graham: hackers are artists

Paul Graham argued in Hackers and Painters that programmers resemble painters and architects. They all face the same problem: it is not enough for something to function. It must have a shape that feels right.

In Taste for Makers, he described principles of good design that travel across disciplines:

• Good design is simple in mathematics, a shorter proof; in code, a cleaner expression
• Good design solves the right problem not only the one that was assigned
• Good design is revised experts plan for the first version not to be the last
• Good design copies the best not mindlessly, but in pursuit of the right answer

If taste were only personal preference, everyone would be perfect at it. Real software development proves otherwise immediately. Some decisions age well. Others create technical debt that teams repay for months.

Steve Jobs and Microsoft: taste as strategic advantage

Steve Jobs framed taste as strategic differentiation. When he spoke about Microsoft in the 1990s, he said their problem was not incompetence but a lack of taste.

It was not merely an insult. It was a diagnosis. At Apple, taste was built into the product as a discipline: nothing should ship unless it felt as good inside as it looked outside. Jobs’ line that design is not just how something looks but how it works is more useful to programmers than most architecture manuals.

For developers, the implication is simple: taste is not decoration. It is the inner architecture of decisions that determines whether a product feels inevitable or merely functional.

Rick Rubin and the punk rock of software

Rick Rubin is interesting precisely because his superpower was never technical virtuosity. He did not need to play every instrument. He did not need to read every note. He could recognize what was good before he could fully explain why.

In collaboration with Anthropic, Rubin created The Way of Code, an interactive book connecting the philosophy of the Tao Te Ching with the aesthetics of AI development. His idea about vibe coding matters for software: just as punk allowed people with three chords and an opinion to make music, AI allows people with vision and taste to build software.

You no longer need technical virtuosity in every layer of the stack. You need a clear point of view about what should exist, how it should be used, and what must not pass your judgment.

The AI era: when code is cheap, taste is rare

Vibe coding, a term popularized by Andrej Karpathy, means that a developer describes in plain language what they want and AI generates much of the code. The practical workflow is simple: intent, prompt, generate, review, iterate, ship.

Adoption is massive. Developers use AI tools daily, companies compress prototyping into hours, and startups increasingly build on code where a large share is AI-generated.

Here is the paradox: most teams use AI to ship faster. Teams with taste use it to ship better.

AI replicates your previous decisions, both good and bad. If you begin with a vague brief, AI will produce a vague solution. If you know exactly what you want and why, AI can materialize it at ten times the speed.

Taste vs. skill: the decision map

Skill — knowing how to do something

Taste — knowing what to do and why

Skill — applied in implementation

Taste — applied in decision-making

Skill — developed through study and repetition

Taste — developed through exposure, reflection, and experience

Skill — increasingly automatable by AI

Taste — amplified by AI, but not replaced by it

Skill — its standalone advantage declines in 2026

Taste — its value rises as a strategic multiplier

Engineers with taste become orchestrators. They define the problem, shape the solution, review the output, decide what goes into the pull request, and decide what must be thrown away. Their leverage grows every time the tools improve because the tools multiply their judgment.

The inverse is also true. Engineers without taste use AI as a sophisticated autocomplete without critical thinking. The result is AI slop: code that passes the demo today and returns as an expensive problem six months later.

Taste-Driven Development: a new paradigm

In 2026, the idea of Taste-Driven Development is emerging. Not test-driven, but taste-driven. It does not mean ignoring tests. It means that before tests, there must be quality judgment about what is worth testing in the first place.

Taste-Driven Development in practice:

The developer behaves like an architect and chef, not like a kitchen assistant

• AI generates options, the developer tastes and decides
• The focus is on decisions that age well, not only on demo impact
• Optimization is for future readers of the code, not only for presentation
• Every pull request answers the questiondoes this design make future change simpler?

Taste is not magic or folklore. It is a learnable decision-making skill. It is the cumulative result of years of asking: why did this work, why did this feel wrong, what would I change today, and what would I never let into production again?

How to build taste: a practical guide

1. Read the code of the best

Just as musicians train their ear by listening to masters, programmers train taste by reading great code. Studying high-quality open-source projects exposes you to solutions you might never have designed yourself.

Projects worth studying:

• Linux Kernel low-level elegance and discipline
• React UI component architecture
• FastAPI clean and expressive Python API design
• SQLite exceptional code and documentation quality

2. Treat code review as judgment training

Code review is the fastest way to calibrate your taste against the taste of others. It reveals blind spots, challenges assumptions, and forces you to articulate why one solution is better than another.

3. Expose yourself to non-technical disciplines

Taste does not copy directly from one domain into another, but patterns travel. Mathematics, architecture, music, typography, product design, and writing share principles of simplicity, rhythm, hierarchy, and timelessness.

4. Build a public portfolio

In the AI era, your portfolio matters more than your CV. Anyone can claim to have taste. The proof is in artifacts: a well-designed open-source project, a technical blog, a product people actually use, or a series of decisions you can defend in retrospect.

5. Reflect on your own decisions

The word good is easy to say and hard to defend. The challenge of taste is not only to have an opinion, but to justify it and change it when better arguments arrive.

The language you program in shapes your taste

Every programming language carries values. Time spent in a language shapes what you consider elegant.

Python developer — often values readability and expressiveness

Rust developer — often values discipline and memory safety

Lisp developer — sees code as data and thinks in transformations

TypeScript developer — seeks a balance between product speed and type confidence

The languages you build in signal who you want to be as an engineer. That is why engineering managers discussing culture fit are often really asking: does this person’s taste match how we build things here?

Taste as the last real moat

If AI multiplies resources, the only limiting factor is the quality of judgment behind it. That is why taste becomes the last real moat.

Nielsen Norman Group expressed the design version of this clearly: creating a good design requires more than technical skill. Just because a design can technically be created does not mean it will be good. The same is now true for software.

AI reduces the cost of execution. It does not reduce the cost of the right decision.

Conclusion: two questions separate mediocrity from excellence

In an era where AI writes code, the question “can you program it?” becomes less decisive. It is replaced by two more interesting questions:

• Can you recognize what is good?
• Can you justify it and build something on it that lasts?

Taste cannot be downloaded. It cannot be prompted into existence. It is built slowly: by reading code you admire, debating decisions, and exposing yourself to the best work inside and outside your field.

Once you have it, it becomes your most valuable skill. AI amplifies everything you put into it. If you put average judgment in, you get faster mediocrity. If you put great judgment in, you get the ability to build things that feel inevitable.