Taste Is the Next Frontier of Agentic Engineering

Programming is becoming less important. Code review is becoming less important too. Coding agents can write code, find bugs, run tests, and change large codebases. Work that took days can now take minutes.

But something strange is happening.

Agents can write most of the code, yet people still spend much of their time deciding what the agents should do. A person gives an agent a task, examines the result, and decides what to do next. The agent can complete many steps without help. But when a decision can change the direction of a project, the person often takes control again.

Why?

One explanation is that agents do not understand the product well enough. But this is only part of the problem. Even when the goal is clear, an agent can produce a poor design.

It can add a new abstraction when a function is sufficient. It can add configuration that nobody needs. It can create five files where one would do. Every test can pass. The code can still be bad.

The agent knows how to make the program work. It does not always know what makes a program good.

This difference matters more as code becomes cheaper to produce.

The Cost of Code

For most of the history of software engineering, writing code was expensive. Engineers spent much of their time turning ideas into working programs. They also spent time reviewing code because a mistake could be difficult to find and expensive to correct.

Coding agents have reduced the cost of this work.

This changes what limits a software project.

Suppose a team can build ten features in the time it once took to build one. This sounds like a large improvement. But the team must still decide which features to build. It must also decide how these features should fit together.

Building ten wrong features is not better than building one wrong feature.

The same problem applies to architecture. An agent can implement an abstraction in a few minutes. This does not make the abstraction necessary. In fact, cheap implementation can make unnecessary abstractions more common. There is less reason to stop and question a design when the agent can build it immediately.

The cost of writing code goes down. The cost of a bad decision does not go down at the same rate.

It can even go up. When agents produce more code, a bad decision can affect more of the system before anybody notices.

This is why faster code generation does not always produce better software.

Correct Is Not Good

Software engineers have many ways to check correctness. They can run tests, compare outputs, check types, and measure performance.

These methods work well when the expected result is known.

Design is different.

Two implementations can pass the same tests. One can be simple and easy to change. The other can have many layers, special cases, and dependencies. Both are correct today. But they can have very different costs tomorrow.

A test can show that an API returns the correct value. It cannot easily show that the API should exist.

A benchmark can show that a new system is faster. It cannot show whether the speed is worth the added complexity.

An agent can check whether its code meets a specification. But it must also ask whether the specification leads to a good design.

This is a harder problem because the evidence is incomplete.

We can usually find out whether code works now. We may need months to find out whether the design was good. A good design makes future changes easier, but we do not know exactly what those changes will be.

This makes design quality difficult to measure. It also makes it difficult to teach.

Taste

In 2002, Paul Graham wrote an essay called Taste for Makers. He examined what makes a design good in fields such as mathematics, engineering, architecture, and art.

His central idea was that good design is not only a matter of personal preference. Different fields often value the same properties.

Good design is simple. It solves the right problem. It can survive changes in fashion. It often comes from repeated attempts to improve an earlier design.

These ideas apply to software.

Consider two libraries that solve the same problem. One has a small interface and few concepts. The other has a large interface and many options. The second library may support more cases, but this does not necessarily make it better.

A good engineer asks whether those extra cases matter.

This is taste.

Taste is not the ability to make code look clean. It is the ability to recognize which decisions improve a design and which decisions make it worse.

Sometimes taste means adding an abstraction. Sometimes it means refusing to add one.

Sometimes the best solution is a new system. Sometimes it is a small change to an old system. Sometimes it is to do nothing.

This last case is particularly important for coding agents. An agent is usually asked to produce something. Producing more code is an easy way to demonstrate progress. But good engineering sometimes requires less code.

An agent with good taste must be able to decide not to build.

Can Taste Be Learned?

If taste were only a personal preference, there would be little reason to expect an agent to learn it.

But engineers often agree about bad designs.

They recognize unnecessary complexity, inconsistent interfaces, and abstractions that make a system harder to understand. They can also explain why one solution is better than another.

This suggests that at least part of taste can be learned.

Coding agents already learn from large amounts of code. But observing code is not the same as understanding why its design is good.

A codebase shows the decisions that engineers made. It does not always show the alternatives they rejected.

An agent can learn how a large framework works. It may then use the same patterns in a small project, even when those patterns add unnecessary complexity.

To learn taste, an agent needs more than examples of successful implementations. It needs examples of design decisions and their consequences.

Why was one interface selected instead of another? Why was an abstraction removed? Why did a team replace a system that worked correctly? What became difficult to change after six months?

These questions contain information that source code alone often does not provide.

There is also a difference between recognizing good design and producing it.

An agent may explain why a piece of code is too complex. It may even suggest a simpler solution. But this does not mean it will consistently choose the simpler solution while working on a large project.

To do that, it must apply the same judgment across many decisions.

Taste must become part of the process, not only part of the final review.

A Different Agent Loop

Most coding agents follow a simple process. They receive a task, inspect the code, make changes, and run tests. If a test fails, they try again.

This process is effective because the test provides feedback.

But tests mainly tell the agent whether its implementation works. They provide much less information about whether the design is good.

A better process would also examine design decisions.

Before making a large change, an agent could consider several solutions. It could compare their complexity, dependencies, and effects on the existing system. It could explain why the selected solution is necessary.

After implementation, it could check more than correctness.

Did the change introduce a concept that the project did not need? Did it make an existing interface harder to understand? Could the same result be achieved with fewer components? Will a likely future change require modifications in many places?

Some of these questions can be checked with tools. Others require judgment.

Simply asking another language model to review the design is not enough. The reviewer can make the same mistakes as the author. Two agents can agree on a bad design.

The system needs better feedback.

One possible source is the history of a project. Changes that were easy to make, abstractions that survived, and components that were repeatedly rewritten can provide evidence about design quality.

Another source is human judgment. An engineer can compare two solutions and explain why one is better. These decisions can become examples for later evaluations.

Over time, an agent might learn not only how to implement a change, but also which designs tend to remain useful.

This is a different objective from passing tests.

It is an attempt to make good decisions repeatable.

The Role of Humans

It is tempting to say that humans provide taste while agents provide code.

This may describe many projects today. But it is not a permanent division of work.

People do not always have good taste. Experienced engineers disagree about architecture. Some of the worst systems were designed entirely by humans.

There is no reason to assume that agents cannot become better at design than many human engineers.

The more important difference is between making a decision and being responsible for its consequences.

An agent can suggest a product direction. It can analyze user feedback and compare possible roadmaps. But the decision about which goals matter still belongs to the people responsible for the product.

Taste can help an agent select a good design for a given goal. It cannot determine, by itself, which human goals should matter most.

This separates two problems that are often confused.

Direction is about choosing what is worth doing.

Taste is about choosing a good way to do it.

Both require judgment, but they are not the same kind of judgment.

As agents improve, people may spend less time writing code and more time defining goals, comparing alternatives, and evaluating results.

They may become operators rather than programmers.

But the most useful operator will not be the person who writes the most detailed prompt. It will be the person who knows which decisions matter and can recognize when a project is moving in the wrong direction.

The same will eventually be true of agents.

The Next Frontier

The first major improvement in coding agents was their ability to produce working code.

The next improvement may be their ability to produce working systems without unnecessary complexity.

These are different achievements.

A system that passes every test can still be difficult to maintain. A feature that works perfectly can still be a feature nobody needs. An architecture that looks impressive can still be worse than a few simple functions.

Better models will help. Better tools and longer-running agents will help too. But none of these improvements automatically solves the problem of design quality.

We need ways to evaluate it, learn from it, and use it during implementation.

The aim is not to give every agent the same design style. Different projects need different solutions. A small command-line tool and a distributed database should not follow the same architectural rules.

The aim is to make agents understand the reasons behind those differences.

Good engineers do not apply every design pattern they know. They select what the problem needs and leave out the rest.

Coding agents need to learn the same discipline.

For a long time, software engineering was limited by how much code people could write. That limit is becoming less important.

Now we can produce more code than we can carefully judge.

The next frontier of agentic engineering is judgment. Taste is what allows that judgment to produce good software.