[dingnuts]

reading production code that is known to work can be done with faith and skimming. You don't have to understand every function call because they've each been tested and battle hardened, so it's easy to get an overview of what is happening.

LLM code is NOT like this at all, but it's like a skilled liar writing something that LOOKS plausible, that's what they're trained to do.

People like you do not have the ability to evaluate the LLM output; it's not the same as reading code that was carefully written at ALL. If you think it's the same, that is only evidence that you can't tell the difference between working code and misleading buggy code.

What you've learned to do is read the intent of code. That's fine when it's been written and tested by a person. It's useless when it comes to evaluating LLM slop.

You're being gaslit.

[_feus]

Code is code, it's not a piece of art where we all can have different perspective about what it means or does, so from appsec perspective it doesn't matter who wrote it, just what it does. Also you seem to be interpreting "reading" as one would read a novel, but here "reading" is about finding and exploiting security flaws. So yeah, dunno what you are on about.

[danielmarkbruce]

You are being gaslit if you think "production code that is known to work" covers any reasonable proportion of code in production.

[dingnuts]

well played, but of course inevitably whatever it's doing in production (whether to spec or not) is "working" for somebody.

Obligatory XKCD https://xkcd.com/1172/ "Workflow" reference