Earlier quoted context omitted.
I find myself often trying to understand the madness of some of the code an LLM produces. Does that count? You're absolutely right! I made a mistake, and I'm sorry. . Then I end up questioning myself if it wouldn't have been easier to just do it myself. To be fair though, it's not limited to LLMs, I've felt that way other people's code too. Jokes aside, there's a difference to understanding the code and understanding…
I noticed something about LLM code generation and this is as good as place to post the finding as any. It's fairly obvious, but as we know LLMs choose the highest probability next token, so when generating code, it does so from left to right, without ever reorganizing, which unless it uses a harness, that's not how WE write code, that's property 1. Property 2 is that it will write out as many boilerplate that occurs…
The linear L->R generation is definitely a thing, it's much more costly for an LLM to iterate edits, where a skilled vim coder will be jumping all over the place, trying to make all the LEGO pieces fit.
The skill therefore relies on just being able to one-shot entire chunks of code correctly, and it's amazingly good at this... But even the SOTA models still have a lot of unused imports and unused variable declarations. They just have to "guess" what they'll need and hope for the best. If they include a mass of numpy/scipi/react/icon imports that they might need, it opens the landscape for them later on when predicting relevant tokens, reaching a more ideal solution.
It doesn't hurt to add imports that might be helpful, rather than penalize the solution because you haven't got them. Although the last few SOTA models are more "harness/tool aware", they're starting to have the instinct to write the code anyway, and to be allowed to go and fix the imports later via tool calls.
For anyone who's seen the film Arrival (2016), their entire language is formed of complete concepts, not sequences of words and time. I keep thinking back to this.