>You’re only able to gauge the quality of what you do know.

That's not true. You can follow the logic step by step, search for similar domains, and form a comparison group.

Realistically, if we take this logic to its conclusion, it's like asking: 'You're just a spectator, so can you really judge whether a football player is good at football?

Realistically, LLMs write code well. I'm a C# programmer, and as you know, the current trend in modern programming is to refine error handling—using try/catch at higher layers, working with monads, preserving computable contexts, and branching accordingly. That kind of code typically takes 1 to 2 hours of modeling before you even start writing.

But an LLM can do it in just 5 minutes.

So I think the opposite way: if LLMs can do this well in a domain I'm familiar with, they're probably just as capable in other domains too. And that makes them feel trustworthy.

And more importantly, no matter how great a human programmer is, once you step outside your domain, you're in unknown territory. In those areas, LLMs are surprisingly helpful.

Epistemologically, it might be true that you can't evaluate code in a domain you don't know. But people keep forgetting the fact that you can learn through that code. This very post is itself an example of learning through LLM-typed code.

And programming actually provides clearer results than many other domains. It's not based on subjective UX like UI design. You have:

1.Executable specifications

2.Performance measurements

3.Comparisons with official documentation

These are clear engineering outcomes that allow for objective comparison. For example, you can verify whether a program produces results within 5ms when executed.

Many epistemological arguments tend to overlook this.

A lot of code is open source. You can find mature implementations anywhere. Finding a repo from someone claiming 10 or 20 years of experience and running a differential comparison is not difficult at all."