Over the past year, the most striking thing about AI programming, at least to me, has not been how much code it can generate. It is how far it has lowered the threshold for making software.

Someone with limited development experience can now describe an idea into a microphone, ask AI to write the code, adjust the interface, fix bugs, and even submit a small app to an app store. A few years ago, this still felt like something from the edge of the technical imagination. Now it has become a workflow many people can actually try.

That is why I keep hearing a certain claim: in the AI era, the most important ability for a developer is no longer how many programming languages they know, or how many frameworks they are familiar with, but taste.

I mostly agree with this.

But taste is also a dangerous word. It can easily become a more respectable form of self-satisfaction. Once we stop talking about syntax, frameworks, and APIs, and start talking about aesthetics, judgment, and long-term value, it is tempting to feel as if we have already moved to a higher level.

That is not the kind of taste I want to discuss.

If taste only means aesthetic superiority, it is not very useful in the AI era. The kind of taste that matters is more concrete: it is a sense of standards and trade-offs formed through experience.

Experience means you have seen many problems. Taste means those experiences have taught you what kind of result is acceptable and what is not; when to move fast and when to slow down; when it is fine to take on debt, and when one more shortcut will become a real problem.

So this essay is not about whether AI will replace programmers. That question has already been discussed to exhaustion.

The question I care about more is this: when code becomes cheaper, why does good software remain expensive?

My view is: AI makes code cheaper, but it does not make good software cheaper. Good software is not software that merely runs. It is software that still holds up under real users, real constraints, and long-term change.

Developer taste is the ability to judge how software can continue to hold up under those constraints.

Taste Is Not Experience Rebranded

The fact that many developers are now talking about taste is itself a response to a real shift.

In the past, writing code was an obvious barrier. Whether someone could build software depended first on whether they could understand programming languages, set up an environment, debug problems, and turn requirements into working features. That barrier was high enough that many discussions stayed at the level of whether someone could code at all.

Large models have changed this.

As code generation becomes widely available, the ability to make something run is no longer as scarce as it used to be. The distance between an idea expressed in natural language and a runnable piece of software has been compressed. Tasks that once required a developer several days or even weeks may now require a decent prompt, a few rounds of conversation, and some patience.

But when the cost of execution falls, the problem does not disappear. It moves.

In the past, the expensive part was getting something written. Now the expensive parts are what to choose, how to choose, how to evaluate the result, who is responsible when it fails, and whether the thing can still be maintained three or six months later.

This is why I prefer to understand taste as a sense of standards, not as a vague form of general judgment.

A sense of standards is not just saying, "I think this is better." It contains at least four connected questions:

1. Is this problem worth solving?
2. How far should we take the solution at this stage?
3. Can this implementation be evaluated, maintained, and owned?
4. Will users understand it, trust it, and keep using it?

In other words, taste is not a single point. It is a chain of judgment that runs from what to build, to how to build it, to how it can continue to exist.

AI can participate in that chain. It cannot own the chain for you.

First, Judge Whether the Need Is Real

The first place a product usually goes wrong is not the code.

It is the requirement.

People without much product experience can easily mistake themselves for the user. They can also mistake what users say for what users actually need. A user asks for a feature, so they build that feature. They find an idea interesting, so they immediately open the development environment. They see a competitor with a certain module, so they assume they should have one too.

AI makes this more dangerous.

In the past, there was still a development cost between an idea and a product. Even if someone had many impulses, they could not necessarily turn all of them into software. Now that AI makes building easier, many unvalidated ideas can become products faster.

That sounds like an efficiency gain.

But if the direction is wrong, higher efficiency only means faster waste.

Judging whether a need is real is not just asking whether a user has said something. The more important questions are:

1. Why did the user say this?
2. Is the problem frequent, painful, and specific?
3. How does the user solve it today?
4. What is the real cost of the current workaround?
5. Is your product actually better than the existing option?

This requires observation, questioning, and judgment more than coding ability.

AI can help organize interview notes. It can summarize user feedback. It can even draft requirement documents. But it cannot take final responsibility for deciding whether a need is worth solving.

From this perspective, taste begins with sensitivity to the problem itself.

An experienced developer may not always write code faster than others. But they may notice earlier that the problem should not have been asked in that way at all.

Then, Decide What Debt to Take On

Finding a real need does not mean you should immediately build every possible capability.

AI is very good at producing options. Give it a requirement, and it can suggest many implementation paths: use local storage here, connect a database there; add an account system here, add collaboration features there; make this screen a dashboard, split that flow into multiple steps.

Every option can sound reasonable.

But the hard part of software development is often not whether there is a solution. It is which solution to choose.

A product is not static. It has stages.

An early product needs to validate demand. A middle-stage product needs to improve stability and retention. A mature product needs to deal more seriously with collaboration, permissions, cost, data, and long-term maintenance. Different stages deserve different levels of complexity, and often different technical architectures.

If a product has not yet proven that users truly need it, rushing into a complex permission system, configurable architecture, plugin model, or multi-tenant design may look professional. In reality, it may just be premature complexity.

On the other hand, if a product is already being used regularly by real users but is still held together by temporary scripts and ad hoc state, it will eventually become hard to change.

This is a point that is easy to misunderstand: emphasizing taste does not mean demanding perfect engineering from day one.

Many successful products were rough in the beginning. The code may have been messy, the architecture temporary, the interface not especially refined. But they captured a real need, so they survived.

That does not weaken the importance of taste. It shows that taste is not engineering purism.

Taste is not refusing to take on debt. It is knowing what kind of debt to take on, how much of it is acceptable, and when it must be paid back.

Good developers ask:

1. Does this problem really need a complete solution now?
2. Is there a smaller but still real version?
3. Will this approach be easy to replace later?
4. Is this complexity reducing cost, or creating debt?
5. If more people start using this product, where will it break first?

AI can generate ten possible solutions, but it does not know which one your current situation can actually afford.

That judgment still belongs to people.

Then, Evaluate Whether It Can Survive

Many AI-generated applications look usable at first glance.

That can be exciting.

But software is not a screenshot or a demo video. Users will open it repeatedly. It will receive abnormal input. It will encounter network failures. It will run into permission issues. It will accumulate data. It will be modified again and again. One day, someone else may have to take it over.

Getting a project to run and making a project survive are two different things.

Many of the seemingly tedious practices in traditional software engineering exist for a reason:

• architecture boundaries;
• type constraints;
• error handling;
• tests;
• logs;
• permissions;
• data migrations;
• security boundaries;
• deployment strategy;
• collaboration conventions.

Their value often does not appear on day one. It appears on the tenth requirement change, the first production incident, the first multi-person collaboration, or the first user data anomaly.

The stronger AI code generation becomes, the more important this question becomes.

AI naturally tends to satisfy the explicit goal in the current context. If you ask it to implement a feature, it will try to implement that feature. But it may not know how the project will evolve over the next six months. It may not automatically understand your baseline for security, stability, and maintainability.

So developer taste in the AI era also shows up as evaluation ability.

You do not only ask whether it completed the task. You keep asking:

1. What happens under abnormal conditions?
2. Can this data structure evolve later?
3. What will users see when this interface fails?
4. Can this permission check be bypassed?
5. Will cost grow out of control as usage increases?
6. If something goes wrong, who can locate it, who can fix it, and who owns the consequence?

The last question matters especially.

AI can generate a solution, but it will not be responsible after launch. If user data is lost, permissions leak, costs spiral, or a business workflow is affected by a wrong result, the people who face the consequences are the publisher, the maintainer, and the organization.

This is why I am cautious about describing AI programming only as "now anyone can build apps."

For one-off scripts, personal automations, and small internal tools, that is a good thing. Many things do not need heavy engineering. They only need to solve the problem in front of them.

But if you want to publish a product over the long term, serve real users, handle real data, and keep it working as reality changes, you cannot stop at "it runs now."

The standards become higher.

The responsibility becomes heavier.

Products Also Need to Be Perceived

Even if the need is real, the solution is appropriate, and the engineering is stable enough, the product is still not finished.

It still needs to be understood, trusted, and used.

This is where taste enters another layer: how the product is perceived.

Why does one product feel rough the moment you open it? Why does another product, despite having fewer features, feel reliable, clean, and worth exploring? Why does one settings page feel like a burden while another feels orderly?

This is not just about whether the UI looks good.

It involves visual design, interaction, copy, information hierarchy, feedback speed, brand tone, and overall consistency. The language a product uses with users, where it stays restrained, where it explains itself, and where it avoids interrupting people all shape how users judge it.

AI can generate interfaces and copy.

But whether a product feels cheap, overloaded, exhausting, or noisy just because it wants to look powerful is still something people have to judge.

Often, good taste is not about doing more. It is about doing less.

Not exposing every feature.

Not adding animation everywhere.

Not turning every button into marketing copy.

Not making the product louder just to show that it has AI.

The character of a product is formed by countless small choices like these.

These choices may sound soft, but they directly affect whether users are willing to put a tool into their workflow. A product that does not feel trustworthy will struggle to be used for long, no matter how many features it has.

AI Writing Is a Useful Reminder

AI writing is a useful analogy here, although I do not want to stretch it too far.

Today, anyone can ask AI to generate an article. It is fast, structured, fluent, and can even imitate a style.

But we can also easily recognize the flavor of many AI-generated articles.

They appear to say everything, but have no real judgment. Every paragraph is smooth, but there is no sense of being on the scene. The structure is complete, but after reading it you can barely remember a sentence.

With the same AI tools, one person can produce an article worth publishing, while another produces a correct but uninteresting explainer.

Software is similar.

The spread of generation ability does not automatically flatten differences in quality. It may make those differences more visible.

Because when production becomes easier, what becomes scarce is:

• what problem you choose;
• what standards you set;
• what result you accept;
• where you refuse to compromise;
• whether you can keep improving.

This is why I do not think talking about developer taste in the AI era is an empty idea.

It points to a more specific question: when tools become stronger, what are humans still responsible for?

Closing

If you are a software developer, I do not think stronger AI programming tools only mean anxiety.

They will certainly change how developers work. They will make some abilities based purely on repetitive coding experience less scarce than before. But they will also amplify the creative ability of developers with real experience.

Because what you have accumulated is not only syntax, frameworks, and APIs.

You have also accumulated judgment about needs, control over complexity, intuition for engineering quality, sensitivity to user experience, and an understanding of how products evolve over time.

These things do not suddenly stop mattering because AI can write code.

They become more important.

If you are not a developer and have become interested in software because AI programming has become more accessible, that is also a good thing. AI really has lowered the entry barrier and can help you get feedback much faster.

But I would suggest treating "I built an app" as the beginning, not the end.

The better questions come next:

1. Does this problem really exist?
2. Who will use this tool repeatedly?
3. Is the current roughness a reasonable stage choice, or a debt that will eventually explode?
4. If it starts serving real users, can I evaluate quality and own the consequences?
5. Does this product express itself in a way that makes people willing to trust it?

This is what developer taste means to me now.

It is not aesthetic superiority. It is not a prettier word for experience.

It is a sense of standards: knowing what is good and what merely runs; knowing when speed is appropriate and when something cannot be skipped; knowing what tools can do for you, and what responsibility still returns to people in the end.

Let me emphasize the main point again:

AI makes code cheaper, but it does not make good software cheaper.

The stronger the tools become, the more they amplify differences in direction, trade-offs, and standards.