One disconcerting thing I encounter when working on projects with LLM users: their models do find some bugs (though also a tonne of stuff in the ‘that’s not a bug, that’s just software” category) but the explanations are often bullshit. As in, they misrepresent how the code works. The bug, though it exists, isn’t as described and the proposed fix would just make things worse
The understanding of anybody relying on these tools, AFAICT, could slowly drift away from factual reality of the code
The other issue is more personal: you can’t have conversations about code with people any more. Ask them for their personal opinion on a piece of code and you’ll just get a chatbot text extrusion back
Makes the job a whole lot less fun and personable.
This kinda bothers me more than the bug misrepresentation
I actually like coding and talking about code. What’s the point of the job if you take away the fun part?
@baldur This is where semantics become tricky. I would phrase my enjoyment of software development as contained in analyzing requirements, producing a solution, and discussing the aspects of the solution. If code (3GL) is your solution presentation mechanism, then your statement rings true. This path is requirements > 3GL > 3GL compiler/interpreter(to include the python users) > machine code. (roughly)
1/
@baldur The LLM approach (which I would say is similar to an outsourcing approach) appears to be requirements > LLM prompts > 3GL of unknown quality > 3GL compiler > machine code.
Can one say the prompts are the code? Right now, one can't, because there are stories of the same prompts producing different code. The code is also of unknown quality, so one couldn't discuss the prompts until the code has been vetted. However this is probably the stand that LLM users would take.
3/3
@baldur My preferred alternative for the past 25+ years has been the Shlaer-Mellor approach, requirements > OOA model > model compiler > machine code. The "models are the code" produces an (arguable) equivalency to your statement.
In both approaches, the code quality is assumed to be good and can be discussed/reviewed at each stage on the path.
2/