[theptip]

I’m not sure why that matters here. Users want code that solves their business need. In general most don’t care about repeatability if someone else tries to solve their problem.

The question that matters is: can businesses solve their problems cheaper for the same quality, or at lower quality while beating the previous Pareto-optimal cost/quality frontier.

[thesz]

Recognizable repetition can be abstracted, reducing code base and its (running) support cost.

The question that matters is: will businesses crumble due to overproduction of same (or lower) quality code sooner or later.

[theptip]

Sure. You seem to think that LLMs will be unable to identify abstraction opportunities if the code is not identical; that’s not obvious to me. Indeed there are some good (but not certain) reasons to think LLMs will be better at broad-not-deep stuff like “load codebase into context window and spot conceptual repetition”. Though I think the creative insight of figuring out what kind of abstraction is needed may be the spark that remains human for a while.

Also, maybe recognizing the repetition remains the human's job, but refactoring is exponentially easier and so again we get better code as a result.

Seems to me to be pretty early to be making confident predictions about how this is all going to pan out.

[chii]

> The question that matters is: will businesses crumble due to overproduction of same (or lower) quality code sooner or later.

but why doesn't that happen today? Cheap code can be had by hiring in cheap locations (outsourced for example).

The reality is that customers are the ultimate arbiters, and if it satisfies them, the business will not collapse. And i have not seen a single customer demonstrate that they care about the quality of the code base behind the product they enjoy paying for.

[thesz]

> And i have not seen a single customer demonstrate that they care about the quality of the code base behind the product they enjoy paying for.

The code quality translates to speed of introduction of changes, fixes of defects and amount of user-facing defects.

While customers may not express any care about code quality directly they can and will express (dis)satisfaction with performance and defects of the product.

[carschno]

It happens today. However, companies fail for multiple problems that come together. Bad software quality (from whatever source) is typically not a very visible one among them because when business people take over, they only see (at most) that software development/maintenance cost more money that it could yield.

[OvbiousError]

It is happening. There is a lot of bad software out there. Terrible to use, but still functional enough that it keeps selling. The question is how much crap you can pile on top of that already bad code before it falls apart.

[sdesol]

> Cheap code can be had by hiring in cheap locations (outsourced for example).

If you outsource and like what you get, you would assume the place you outsourced to can help provide continued support. What assurance do you have with LLMs? A working solution doesn't mean it can be easily maintained and/or evolved.

> And i have not seen a single customer demonstrate that they care about the quality of the code base behind the product they enjoy paying for.

That is true, but they will complain if bugs cannot be fixed and features are added. It is true that customers don't care, and they shouldn't, until it does matter, of course.

The challenge with software development isn't necessarily with the first iteration, but rather it is with continued support. Where I think LLMs can really shine is in providing domain experts (those who understand the problem) with a better way to demonstrate their needs.

[CamperBob2]

Recognizable repetition can be abstracted

... which is the whole idea behind training, isn't it?

The question that matters is: will businesses crumble due to overproduction of same (or lower) quality code sooner or later.

The problem is really the opposite -- most programmers are employed to create very minor variations on work done either by other programmers elsewhere, by other programmers in the same organization, or by their own younger selves. The resulting inefficiency is massive in human terms, not just in managerial metrics. Smart people are wasting their lives on pointlessly repetitive work.

When it comes to the art of computer programming, there are more painters than there are paintings to create. That's why a genuinely-new paradigm is so important, and so overdue... and it's why I get so frustrated when supposed "hackers" stand in the way.

[thesz]

    >> Recognizable repetition can be abstracted
    > ... which is the whole idea behind training, isn't it?

The comment I was answering specifically dismissed LLM's inability to answer same question with same... answer as unimportant. My point is that this ability is crucial to software engineering - answers to similar problems should be as similar as possible.

Also, I bet that LLM's are not trained to abstract. In my experience they lately are trained to engage users in pointless dialogue as long as possible.

[CamperBob2]

No, only the spec is important. How the software implements the spec is not important in the least. (To the extent that's not true, fix the spec!)

Nor is whether the implementation is the same from one build to the next.