@plexus In the end, software engineering is about creating solutions to problems other people have. The solutions are not a byproduct, but the primary purpose. To the majority of users, the inner workings and the creation process of software is opaque. The qualities that software exposes on the outside are largely independent of its inner workings.

This means that for most people in the software industry, adapting to the new tooling that makes the creation process more efficient is 1/

@hanshuebner @flooper @plexus And if your view of the world begins and ends with making money, as I admit is capitalist dogma, fair enough.

But producing code with LLMs - or using them for anything which needs to be correct - is deception (whether you're deceiving yourself or others) on a massive scale, on a par with crypto, Ponzi schemes, climate denial, etc.

(1/2)

@hanshuebner @flooper

Anthropomorphizing them (as many do, but I don't think you are) is a flawed view, but does provide one useful insight.

If one treats an LLM as a person, then the fundamental issue is:

They are a bullshit artist with a huge library. They do not have competence at anything except bullshitting, at which they are superb.

I agree that it's amazing that we can build a mechanical bullshit generator that's good enough to bypass most people's defenses.

@hanshuebner @jmax We can agree that the primary purpose of a software system is the functionality it provides, but "Code is primarily consumed by machines" is not fully true.

Code is RUN by machines but it is still, and it will be for a long time, primarily consumed, as in written and read and changed by humans (https://www.goodreads.com/quotes/6341736-any-fool-can-write-code-that-a-computer-can-understand)

And code that cannot be changed will eventually stop being useful (Lehman's 1st law of software evolution: https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution)

@flooper I don't see how Fowler's quote asserts that code "will still be consumed [...] by humans". Nothing in that quote says that it would, and from my experience, there is no need to actually read LLM written code in order to ensure that they work.

You seem to want to imply that LLM written code can only function if a human has read and approved it, which is not true. But maybe I misunderstood.

You also seem to want to imply that LLM code is not maintainable. What makes you think so?

@hanshuebner It doesn't matter what I think, really, but what we know so far, with some degree of well-founded evidence:

"Speed at the Cost of Quality" ->
https://www.linkedin.com/posts/hao-he-91760b140_speed-at-the-cost-of-quality-how-cursor-activity-7422355920891928578-wyKG?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAEI4vEBzlSIOGsnBtiXZ-jICI-U7Tp9frw

@flooper Now that you could not explain why what you wrote before (Fowler says writing code well for humans to read is hard) is proof for your claim that only code read by humans can be good, you come up with one study that claims LLM coding agents are because Copilot did not work in a sample set.

I'm not going to be able to challenge your beliefs, but gladly I don't need to.

@hanshuebner What I meant is that, for now and with the evidence we have, our ability to maintain and evolve a software system still depends on humans being able to do it.

You are right, a single paper means nothing, but evidence is build up by the accumulated findings of many studies like this.

I can pull others but the paper I referenced is relevant, because, a) it's quite recent, b) it's published in the current top conference on empirical software engineering

@flooper I'm going off my own experience, which is some 40 years as a programmer and 1.5 years of working with LLMs. From that, I can only conclude that code writing is over. I don't do it unless I want to, but it is not economical and there is no tangible benefit to doing so.

This does not mean that studies which find LLM projects to have quality issues are invalid. The reason, though, is not that LLMs cannot write code, but that software engineering with LLMs requires different processes.