[win311fwg]

> Try asking it to do an DOM event adapter to filter and map events

Why? While you can technically build a DOM event system in any language, you wouldn't, so this sounds like you are talking about Javascript (or Typescript, but same thing)... Which we already know LLMs cannot handle because the training data was full of poor quality code and thus LLMs also produce poor quality code. So, yes, you have to watch Javascript like a hawk here because the LLMs will go to crazy town if you don't pay attention. But that was already acknowledged.

Perhaps you accidentally chose the wrong example?

[bluegatty]

First - it's an examples, it's not about 'why do that?' - that's another question entirely.

Second - it is very wrong to imply 'the AI has bad training data for JS / TS' - that's generally not how it works.

Third - the main point is not the code, it's information distillation as I suggested. It has nothing to do with the programming language. Yes - it might plausibly work better in some than others, but that's not the crux of the issue.

As to to your question the 'DOM event filtering' is just a good example because there are ambiguities in the problem space.

The spec is odd, browsers have different stated behaviours, different actual behaviours - this creates difficult problem space surface. It doesn't matter what 'la

[win311fwg]

> it's an examples

It is an example, but an example that doesn't seem to fit the discussion.

> it is very wrong to imply 'the AI has bad training data for JS / TS' - that's generally not how it works.

Where would it have found good training data? The popularity of JS/TS means that the vast majority of the code that was written for it prior to LLMs is pretty lousy. Worse, even among the codebases that could be considered good, there is very little consistency between them so there is real good way for an AI to converge on what a good codebase even looks like in that ecosystem.

Regardless, no matter what explanation you want to choose, it remains abundantly clear that LLMs show time and time again that they struggle with JS/TS where there is no such struggle in certain other ecosystems. If you want to leverage LLMs to their full potential you are simply not going to be able to choose JS/TS (among others).

> As to to your question the 'DOM event filtering' is just a good example because there are ambiguities in the problem space.

Perhaps the disconnect here is that you have forgotten, but the discussion was about code quality. What about DOM event filtering in particular would lead an LLM that otherwise produces quality code to suddenly not? I have seen nothing to suggest that, in ecosystems that LLMs are suited for, that code quality declines when the problem space becomes more difficult. Code quality and problem space difficulty are orthogonal.

Or perhaps I am misunderstanding you, but my read here is that you point out that when a problem isn't well constrained an LLM may provide a solution that doesn't meet your expectations. That is true, but code quality and meeting user expectations are not one and the same. In fact, in the startup realm you often hear things like "users don't care about your code quality, just release something!" to really drive home that they are in entirely different dimensions.