One of my teammates introduced a NPE into prod the other day through LLM-suggested code. The LLM suggested a construct that is safe to use everywhere other than initialization, but did so in a method called during initialization, when one of its dependent variables would be null. Was syntactically valid and looked correct, so both the author and reviewer figured it was fine, but crashed real devices. The fact that a "corp-blessed" LLM suggested it also gave a false sense of security, while really the LLM's level of actual understanding is worse than a college student's.
Pretty sure any null-safety linter in Java could pick this up.
It wasn't, though, and much of the core Android code won't compile with nullability checks because it was written before @Nullable/@NotNull annotations were a thing. Pre-2010 Java code basically has to assume everything is nullable. My point is that LLM-generated code often doesn't, because it's trained on StackOverflow code where the author either doesn't care or had implicit knowledge about which variables could be null and which couldn't. Hence it generates code that is valid in most situations but can lead to a crash when used in situations where its data dependencies may be null or uninitialized. Exactly the stuff of security nightmares.
The idea being that being called something "cool" like "hacker" or "threat actor" actually incentivizes script kiddies to put down their Xbox controllers and do bad things.