One of the notes in the postmortem was that if it were Kotlin, it would've been caught by the nullability checker. It wasn't, though, and much of the core Andr

One of the notes in the postmortem was that if it were Kotlin, it would've been caught by the nullability checker. 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.