AI coding agents make building cheap. Taste still matters.

AI coding agents can make a feature cheap to implement. They cannot make it worth having.

I keep returning to this when I see conversations about how much faster we can ship with coding agents. Speed is useful. But if it makes every idea feel inexpensive, the queue of things we could build grows faster than our understanding of what people need. More output can become a more polished form of noise.

More things can be built, and faster, but that does not make every one of them worth building.

Code generation moves the cost

Imagine a team considering a new dashboard for an existing product. An agent can scaffold the page, wire the data, and refine the layout quickly. The implementation estimate looks small, so the dashboard gets built.

But every surface asks for attention. Someone has to decide what the numbers mean, keep them trustworthy, explain exceptions, maintain permissions, and notice when the page encourages the wrong decision. Users must learn where it lives and why they should open it. Code review and tests can check whether an implementation meets its acceptance criteria; they cannot decide whether the dashboard deserves to exist. The code may have been cheap; the product obligation is not.

The same is true of an AI agent feature. A new tool call or memory store can be easy to add. It also gives the system another way to surprise a person, repeat stale information, or act with misplaced confidence. The relevant question is not “Can we implement this by Friday?” It is “What improvement would make this complexity worth carrying?”

Taste is a series of decisions

“Taste” can sound like an aesthetic quality you either have or do not. I mean something more practical: the habit of choosing, editing, and stopping.

Before building, I want to know who is helped and what changes for them. During the work, I want to notice when the solution has become more elaborate than the problem. Afterward, I want to be willing to remove a feature that looked clever but did not earn its place.

That requires evidence and judgment together. User behavior can show that a feature is ignored; a conversation can explain why. A metric can reveal a slower workflow; it cannot always tell us what the person was trying to accomplish. The purpose of judgment is to make those signals mean something, not to overrule them whenever a favorite idea is threatened.

Being able to write everything does not mean we should. The same principle applies to code. If the goal is vague, an agent can produce a convincing answer to the wrong question at impressive speed.

A question before the next prompt

Before asking an agent to build another feature, I would ask: If this were free to implement, would I still want to own its consequences?

If the answer is yes, build it and test it. If the answer is unclear, make the problem smaller until the value is visible. Sometimes the best use of a capable agent is not to produce more, but to help us see what to leave out.