A stark difference is that GUIs are designed with the same feature set as the CLI. Unlike an LLM, the GUI is not going to start suddenly making up data, offering nonexistent features, or straight up lying. The GUI is a more easily accessible interface that more or less behaves like the CLI. It’s like an orbital sander versus manual sanding - generally easier but you can also really fuck shut up if you don’t know what you’re doing.
Furthermore, coding is not merely clicking buttons or typing commands. You need to understand your language, your compiler, the intended runtime environment, etc., as well as best practices and then also have the purely human ability to create a new way of doing something. The LLM simply regurgitates what it’s been trained on without regard to the quality of that data - it can’t make value judgements on best approaches or even syntax, it’s just monkey-see, monkey-do. Hell, it can’t even sometimes differentiate between the correct syntaxes for different languages. In the end it gets you nothing but the illusion of convenience and the very real problem of non-functional, unmaintainable, and/or unoptimized code. It’s a fool’s bargain.
I think you are looking at llms in to large a context. Your issues you have with it are the same as search and if used as a further abstraction of search it is going to carry forward weaknesses. LLM’s trained more narrowly for specific purposes are going to do better if their narrow training data is of high quality rather than throwing everything at it.
I believe you are mistaken - I’m speaking about LLMs within the context of FOSS and coding as that’s the subject of OP’s post and the article they linked to. You may have thoughts about LLMs in general, but you don’t seem to be addressing their use (and abuse) when it comes to coding or giving them carte blanche when it comes access to FOSS repos. Because if you, as the article suggests, just bend over, you’re giving access to all LLMs, not just some hypothetical specially trained one.
A stark difference is that GUIs are designed with the same feature set as the CLI. Unlike an LLM, the GUI is not going to start suddenly making up data, offering nonexistent features, or straight up lying. The GUI is a more easily accessible interface that more or less behaves like the CLI. It’s like an orbital sander versus manual sanding - generally easier but you can also really fuck shut up if you don’t know what you’re doing.
Furthermore, coding is not merely clicking buttons or typing commands. You need to understand your language, your compiler, the intended runtime environment, etc., as well as best practices and then also have the purely human ability to create a new way of doing something. The LLM simply regurgitates what it’s been trained on without regard to the quality of that data - it can’t make value judgements on best approaches or even syntax, it’s just monkey-see, monkey-do. Hell, it can’t even sometimes differentiate between the correct syntaxes for different languages. In the end it gets you nothing but the illusion of convenience and the very real problem of non-functional, unmaintainable, and/or unoptimized code. It’s a fool’s bargain.
I think you are looking at llms in to large a context. Your issues you have with it are the same as search and if used as a further abstraction of search it is going to carry forward weaknesses. LLM’s trained more narrowly for specific purposes are going to do better if their narrow training data is of high quality rather than throwing everything at it.
I believe you are mistaken - I’m speaking about LLMs within the context of FOSS and coding as that’s the subject of OP’s post and the article they linked to. You may have thoughts about LLMs in general, but you don’t seem to be addressing their use (and abuse) when it comes to coding or giving them carte blanche when it comes access to FOSS repos. Because if you, as the article suggests, just bend over, you’re giving access to all LLMs, not just some hypothetical specially trained one.