[bluegatty]

" but the software will be fine if you don't."

" You already know that the quality will be on par with what you would have written yourself."

No - I totally don't agree.

I've almost never seen a situation where one does not have to read, other than for bug fixes.

In almost every case where I have 'gone under the good' to AI created system - it was bad.

The AI is terrible at grasping and coding concepts. It names things poorly, and over iterations, it will turn 'state' into a hairball.

Try asking it to do an DOM event adapter to filter and map events, like doing 'ime end even guaranted' - it will do write something and write tests that all pass, but there will be holes.

The logic will be inconsistent and won't follow an hard spec, and even getting it to write a hard, clean spec won't work.

Let me put it differently: it's not the 'code' that's the problem - it's the concepts that it is trying to represent, which it screws up.

Only where those 'concepts' are already clean, such as in a really good code-base that you only need to tweak - does it work well. And amazingly well.

But for doing anything from scratch - you have to read the code.

I don't think it's going to get better any time soon because I think there is a 'noisy channel' problem here, in that it can only get so good without proper specification, and specification is 'the developers job' that cannot be replaced, at best we can get tools to support us there.

[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.