> I don't think there's perfect code

Note I used "perfect" in my text. In this context, meaning it passes human PR reviews following our standard guidelines with minimal feedback/correction required.

    > So as long as code meets or exceeds the human output, it's "good enough" and meets expectations. That's what a typical customer cares about.

Why settle for this when "perfect" is "free"? I understand this dichotomy when writing "perfect" code requires more expensive, more experienced human resources or more time so you settle for "good enough"; but this is no longer the case, is it? The cost of "perfect" is only perhaps a few fractions of a cent higher than shitty.

You only need to accurately describe what "perfect" is to the LLM instead of allowing it to regress to the mean of its training set. There really is no cost difference between writing shitty code and "perfect" code now; its just a matter of how good you are at describing "perfect" to the LLM.

For example, we very specifically want our agents to write code using C# tuple return types for private methods that return more than 1 value instead of creating a class. The tuple return type is a stack allocated value type and has a default deconstructor. We also always want to use named tuple fields every time because it removes ambiguity for humans and increases efficiency for agents when re-reading the code.

We want the code to make use of pattern matching and switch expressions (not `switch-case`) because they help enforce exhaustive checks at compile time and make the code more terse.

If we simply tell the agent these rules ahead of time, we get "perfect", consistent code each time. Being able to do so requires "taste" and understanding why writing code one way or using a specific language construct or a specific design pattern is the "right" way.