In the network of developer-centric media, there seems to be a meme about how
the future of software development is [_taste_](https://hn.algolia.com/?dateEnd=1792517120&dateRange=custom&dateStart=1757721600&page=0&prefix=false&query=taste&sort=byPopularity&type=story).

> I didn't know code is edible.

## What is taste

I started out my career as a designer. I studied industrial design at
university, after rejecting graphic design scholarships, and finished my studies
around the time apps and app stores were becoming the new thing. Design as I had
learned it is a process of technique and iteration. It means researching possible
ways to make something appeal to a large enough market to assist in the
profitability of it. Research could be looking at competitors, looking at trends,
iterating the form of something and getting feedback, and justifying the cost of
continuing this process, putting it into the market, or giving up altogether.

From the outside, it would look like the designer can, with some kind of talent,
produce a beautiful form that is totally coherent with what the market desires.
People often struggle to separate artist from designer, and believe similarly
about artists, that they have some kind of supreme ability that allows them to
produce artifacts of perfect experiential beauty. The reality is that artworks
are produced through a lot of technical skill and iteration with feedback
accumulated over many years of practice.[^1]

## Good taste

If we call that taste, then what is "good" taste? Maybe someone can do all of
that but be said to have bad or no taste. In this sense, taste is something
structural. Some group of people outside the taste-maker can validate that the
taste fits into their set of values. That's a kind of social subjectivity and
isn't measurable.

The problem here is populism. If the structure exploits human psychology and
its ability to reason, then something that lacks soundness could be deemed as
good taste. If you aren't allowed to question the structure, as we see in
ideological and authoritarian social systems, good taste can be manufactured and
used to serve the system even if it's detrimental to human or non-human
experience or existence. We don't even need to force good taste, as popular
opinion through para-social relationships with celebrities can shape beliefs.
The result is a kind of social validation where poorly informed opinions can
become taste because the celebrity held them and expressed them (even if they
later reject them).

## Why are we deferring to taste?

It feels like a kind of cope. An engineer fears that their years of experience
and education are meaningless because a tool can now automate a lot of what they
were paid to do. They develop the idea, or are told, that in that time they
developed "taste" and this is what will justify their labour. They will be the
ones to decide what should be built, what should be improved, and the best way
to do it.[^2]

The problem is that many, most, or all people will take this idea and believe
that they have good taste. There's no way to measure it other than the fact that
they think it to be so.[^3] Like many artists without patrons, the belief is that
they do have what it takes, but they just haven't been acknowledged / discovered
yet. This is the structural taste: you don't lack taste, the structure itself
has to change to fit your taste in.


::: card

If you doubt your taste, you can purchase the course to develop it and get
this certification to validate it. Good taste in just 3 easy payments.

:::

Producing good code, just like design, isn't a singular action that is directed
by a taste filter. It's an applied skill that works through continual iteration.
The skill mostly makes iteration faster, not necessarily more refined or
superior.

## What are we trying to achieve?

My personal belief is that letting AI write code is totally acceptable and we
should be doing so. There are many reasons beyond just "speed":

- Coding is bad for the body.
- Spending a lot of time on code is less time spent with loved ones.
- We can produce many variations that we may have not considered.
- It's an extra set of "eyes" on the same problem and same code.

But like playing sport, even if a robot can do it faster and more safely, no one
is stopping you from doing it for fun. The problem that developers are facing is
survival: can they still feed their families if no one will pay them to write
code? If not, can their _taste_ be a way to earn a salary?

Many jobs are taken by people who use social validation to prove they are
capable of something. This might be having a high-level degree from a reputable
university. It might be about having worked at a reputable company that's known
for their very complex problems, solved by the teams you've worked on. Sometimes
it's belonging to a social network of the right people who will get you in the
role.

What a business wants is the most cost-effective way to get income, and that
translates to profit. The more you can automate that process, the more
deterministic the cost, and therefore profit. Hiring an engineer adds the
potential for a large expense going to a fairly unpredictable, complex system to
produce the desired result. The belief that somehow a company will look at
their automation and then decide that taste is what is missing and should become
a new expense is a pretty big leap of faith.

The problem that we are facing with automation is verification. The taste idea
is to say, what can help us to know:

- How to make the AI produce what we actually want.[^4]
- How to make sure that if it does what we want, it does it correctly, whatever
  that means.
- And while doing all of this, it doesn't work against our interests, somehow.

If I download some third-party library, these are the same problems I face.

- The library does what I actually need it to do.
- It implements this functionality in the best possible way.
- It doesn't contain exploits.

## Automated taste

I don't write machine code for my computer. Instead, I write in a higher-level
language. That language might get transpiled, interpreted, turned into bytecode,
and translated into assembly. When I write crappy code, I might have a linter
show me the code formatting is off, or that what I write breaks some kind of
memory safety. I run tests against the code and see errors stream out describing
that something broke somewhere. I have a compiler that doesn't know what I'm
trying to do and gives up. I have a tool that can time how long a block of
compiled code runs and how many instructions are required to do it.

None of these tools have an AI, or human, in them. They help me verify whether
the code is doing what I expect it to do. Humans, and AI, use these tools.
Another tool we use is other humans, which we use to validate that the code we
wrote is doing what we claim it should do and doing it in some version of the
best possible way. The reality of this tool is that so many people never really
do this step at all, do it very well, or really know the correct way to do it.
If you use an AI to do it, you are facing a similar issue of: how do you now
trust and verify that AI?

These higher-level programming languages are designed to be general-purpose.
This means that they're not necessarily optimized for doing any one thing
particularly well. What they're designed for is allowing the writer of the code
to express their solution, and readers of it to understand what was written.
Trying to write something that runs safely and fast in these languages often
results in verbose, complicated, atypical, and often unreadable programs. The
idea is that the code written should follow patterns that can be identified by
the "interpretation" program and this program will convert the code into the
most safe and performant version. If the interpreter can't, it should be able to
warn the author that what they've written is not good and how they could possibly
improve it.

If we are generating code, our problems are still very similar to the problems
we had before we started doing this. We need a way to know that the code we have:

- Follows rules that prevent it from doing the wrong thing.
- Follows the best pattern for expressing something.
- Makes everyone aware of the dangers of running the code.

If an AI can write code that is mostly meant to resemble typically reasonable
code for a given language and goal, and an AI can read that code and critique
it, then we still have a system that isn't AI that the code runs through to
become operational. The result of the creation of this code is to produce
something faster, less costly, and more deterministic than just giving the task
to an AI. We aren't dependent on the AI so much as we're expecting the
verification system to turn what the AI produces into something we can trust and
scale, and that a human or AI can use it to improve the code it's reading and
writing.

This isn't taste. It's a good compiler, a good set of tools.[^5] Finding ways to
build languages that are easier to write, read, generate, parse, and when doing
so, be able to automatically produce instructions that are fast and trustworthy
or output advice that guides us or stops us from running it altogether. The very
fact that we continue to improve our tools and languages is evidence that the
room for improvement here is vast, and more interesting than pumping out
iterations of the same ideas.

## No taste at all

With AI we have a few problems that use the same skills as before but shift our
focus:

- Deterministic compilers that we can trust and guide us to make good code while
  producing the best possible machine code.
- Understanding why an AI system might be producing code that doesn't conform to
  what we or the compiler want it to.
- How to make both of these things work with less cost, energy, hardware,
  infrastructure, so we can scale them.

The term taste is problematic. From within, we point to experience and decision
making, and say these three problems are solved by those with these skills. But
taste has a long history of being exploited, because the outside doesn't
perceive what it is, only how it feels. Your prompt engineer's _taste_ looks like
some kind of magical AI divination. Your compiler engineer's _taste_ looks like a
[mystical knight slaying the dragon of complexity](https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools).
In reality, both are doing science, and science can be learned by anyone willing
to do the work, whether or not they worked at Google.

[^1]: Someone might read this as conceding that taste is real, since experience
    accumulated through iteration is roughly what its advocates claim. The
    distinction is between inside and outside. A developer calls taste
    experience, and so does a designer. The person paying for the software or
    the wall art sees taste as a magic function of money plus reputation. That
    gap is what makes the term dangerous: it has a long history of being
    exploited by structural populism.

[^2]: I'm not making a claim about whose job it is to decide what gets built,
    and I can't know that for any given reader. My objection is to the
    abstraction. "Taste" packages the future as a person at a desk clicking
    "good" or "bad" on what a machine produces, and that framing hides what the
    work actually is.

[^3]: None of this denies that some judgments produce better outcomes than
    others. That much we can observe. The taste argument takes that
    observation, attributes it to an unprovable quality some people have and
    others lack, then places that quality underneath everything else that
    matters. But taste can appear one moment and vanish the next. It can be
    manufactured. Anyone can claim it at any moment. And if an AI can produce
    good work, it either has taste, in which case taste is no moat, or it
    doesn't need it, in which case taste is absent. Like the aether, you can
    remove it from the explanation and the software still gets built.

[^4]: The tooling I describe later addresses correctness and safety more
    directly than this first point, and a reader might say this leftover part is
    exactly what people mean by taste. Today, getting an AI to produce what we
    want is mostly a matter of context and alignment. But how we direct models
    is likely to change as we better understand what's going on inside them,
    since knowing how to get an AI to do X will come down to knowing how an AI
    does X. As that understanding grows, these decisions may move away from an
    engineer's skills entirely, and "taste" here would look more like an
    entrepreneur knowing which problems to solve. For engineers, the focus moves
    to understanding the compilers and the underlying system of the network.

[^5]: An obvious reply is that designing good compilers and languages requires
    taste too. If so, the advice is the same: drop the word and learn how to do
    it. That's the work of a researcher or scientist.