Off the top of my head:

If you're using the product, and you want to question or debug what's going on, you can:

* Jump directly to the single relevant part of the frontend responsible

* Likewise with the backend. The layout and naming of the code should scream its purpose.

* Once you're looking at the code, it should be trivial to run it, right now, instantly, in unit test, or cli. You shouldn't need to stand up a database to see whether your code rounds taxes the expected way.

The system contains its own checkability. You can, for instance, just sum up all the incoming money and outgoing money and see if your balance is correct. (It's not enough to have good tests today, if you're working on data that was incorrectly calculated and stored yesterday)

Ah the age old question: what makes something good? I think you’re already describing it well at a high level; context matters, and there are multiple axes to consider. But that’s extremely vague and doesn’t help you identify or measure quality, so it might be worth listing as many specific axes as you can.

Maybe ask the same question about other things. What makes a good guitar? What makes a good chair? What makes a good airplane? What makes a good book? What makes a good song? What makes good art? Each of these has a long list of very specific goals and concerns. And to help define the boundaries, also ask what makes something bad, and what makes something mediocre.

Code quality starts with functionality. Does it perform the stated requirements? Does it have testing in place to catch breaking changes in functional requirements? That’s the basic stuff that probably isn’t part of “taste”. A lot of code quality goals center around how code changes over time, and beliefs about designing to avoid functional breakage.

For example you can ask things like does the code use minimal dependencies? Is the code organized into clean classes/modules/functions that each have a single clear role? Is the API easy to read, understand, and use? Is the API hard to misuse accidentally? Is all the code easy to read? Is there documentation, and is the documentation useful, and more than a list of contents? Is the code self-documenting? Is the code efficient, both in how it executes, and in its use of code itself? Is the code designed so that it won’t fail when someone runs it with different sized types, or a different compiler or execution environment, or on a different architecture? Is the code surprisingly elegant and fun to use?

Those are just the beginning. There are of course more layers of application-specific and environment-specific and audience-specific qualities. The good news is that quality depends on your own goals, you can decide which aspects of taste matter to you, and ignore the ones that don’t. It’s fine if your taste & goals change over time.

Good question indeed, I think quality matters less these days because it's trivial for an LLM to increase code quality.

Quality is usually observed from a human perspective. But in my experience, codebases that humans would judge as "low quality" are actually fine for LLMs. They don't have as much trouble as we do with spaghetti code. They don't have problems with readability or obscure syntax, it's all perfectly fine for them. They don't care about indentation either.

Also it's really easy to increase the quality of the code base. You can just prompt to add unit test coverage and it will. You can prompt the LLM to handle edge cases better and it will (you don't even have to specify which, it helps, but it's optional). If you want to have better separation of concerns, just ask the LLM to have more separation of concerns and you'll have it. Documentation lacking? Just one prompt away. More robust build pipeline? You get the idea.