← Return

A quale is not an aether

Taste isn't essence. ·

In the network of developer-centric media, there seems to be a meme about how the future of software development is taste.

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.

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":

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:

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

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:

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:

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. 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. ↩

That's all • Scroll to the top